Docs

Yıkıcı operasyonlar

TL;DR

  • Pipelogic'te yıkıcı bir operasyon, platform durumunu kaldıran herhangi bir fiildir — bir component, bir backend, bir dosya ya da bir node silme. Her biri bir getir-ve-onayla sözleşmesi üzerinde çalışır: çağıran önce etkilenen satırı okur, sonra kaldırmayı açıkça onaylar ve ancak o zaman kaynak kaybolur.
  • Sözleşme tüm yüzeylerde aynıdır: App, REST API, ppl CLI. Hiçbir yüzey onayı atlayan bir yol sunmaz; kontrol platform sözleşmesinde yaşar, belirli bir istemcide değil.
  • Onay biçimi kaynağa bağlıdır. Agent modunda component delete için iki adımlı (ilk çağrı tam satırı bir onay zarfında döner; ikinci çağrı kesinleştirmek için --yes ekler). Agent modunda backend delete için tek adımlı (çağıran kimlik rızadır). file ve node delete için önceden --yes (satır fetch sırasında zaten incelendi).
  • Update'ler yıkıcı değildir. update fiilleri kısmi alanlar uygular, --yes almaz ve onay gerektirmez — en kötü durum, başka bir update'in düzelttiği yanlış değiştirilmiş alandır, kaybolan kaynak değil.
  • Bir prerelease'i released kataloğuna promote etmek önerilen insan inceleyiciye devirdir: agent akışları aday prerelease'i açığa çıkarır ve bir kişi promote'u çalıştırır. Devir önemlidir çünkü promote genel sözleşmeyi hareket ettirir — başka backend'lerin neyi pinlediği, latest ve default'un neye çözümlendiği.

Neden bir getir-ve-onayla sözleşmesi vardır

Getir-ve-onayla sözleşmesi okumayı kaldırmanın önüne koyar: çağıran, kaldırılacak şeyi sonradan keşfetmek yerine o hâlâ varken görür. Kontrol, sonradan gelen bir mesaj değil, sözleşmenin kendisinin parçasıdır.

Her yıkıcı fiilin, çağıranın etkilenen kaynağa baktığı bir adımı vardır — ya önce ayrı bir get çalıştırarak ya da ilk çağrıdan dönen bir onay zarfında taşınan satırı okuyarak. Bu adım, bir sunum ayrıntısı değil, kapıdır. Onu okumadan geçmek, okumaktan daha fazla çaba ister, böylece ihtiyatlı yol varsayılan olandır.

Aynı kapı her çağıran için geçerlidir. App'in sil düğmesine basan bir insan satırı bir onay diyaloğunda görür. Agent modunda ppl component delete çalıştıran bir çağıran onay zarfını okur, karar verir ve çağrıyı --yes ile yeniden verir. Önceden --yes alan silmeler için okuma, önceki fetch sırasında gerçekleşti. Hiçbir yüzey bir çağıranın okumayı atlamasına izin vermez.

Zihinsel model

┌──────────────────────────────────────────────────────────┐
│ 1. SATIRI GETIR                                            │
│    list / get / versions                                   │
│    (veya ilk çağrı onay zarfı)                             │
└──────────────────────────────────────────────────────────┘
                             │
                             ▼
┌──────────────────────────────────────────────────────────┐
│ 2. SATIRI OKU                                              │
│    çağıran inceler: id, workspace, scope,                  │
│    version, tags, bağımlılar                               │
└──────────────────────────────────────────────────────────┘
                             │
                             ▼
┌──────────────────────────────────────────────────────────┐
│ 3. ONAYLA                                                  │
│    kaynağın gerektirdiği sözleşmeyle                       │
│    yıkıcı komut                                            │
└──────────────────────────────────────────────────────────┘
                             │
                             ▼
                       kaynak gitti

Her yıkıcı çağrı bu üç adımdan geçer. Fetch açıkça (ayrı bir list / get çağrısı) ya da örtük olarak (agent modundaki ilk component delete çağrısı satırı bir onay zarfında döner) gerçekleşebilir; her iki şekilde de çağıran kesinleştirme öncesinde satırı görmüştür.

Onay biçimleri

Bir fiile uzanmadan önce hangi onayın geçerli olduğunu bilmek için bu bölümü kullan.

İki adımlı (agent modunda component delete). İlk çağrı, data'sı action: "component.delete.confirmation_required" ve tam component satırını (ya da tek sürüm silme için version satırını) taşıyan bir başarı zarfı döner. Satır zarftadır. İncele, karar ver, sonra kesinleştirmek için aynı çağrıyı --yes ile yeniden çalıştır. Bu biçim geçerlidir çünkü component silme kaskat eder — sürümler, release'ler, bağımlılar — böylece sözleşme, çağıran kabul etmeden önce kaskatın neyi etkilediğini açığa çıkarır. Agent modunda component silme ayrıca component'in boş olmasını gerektirir: önce geçici release'leri sil, sonra artık boş olan component'i.

Tek adımlı (agent modunda backend delete). Çağıran kimlik açık rıza olarak ele alınır: backend'i get ile zaten incelemiş agent'lar ayrı bir --yes'e ihtiyaç duymaz. backend silmeleri geçici test çalışması sırasında sıktır, böylece iki adımlı bir sözleşme güvenlik katmadan gidiş-dönüş eklerdi; kimlik kapısı, tek adımlı biçimi sağlam yapan şeydir.

Önceden --yes (file delete, node delete). Satır, önceki fetch sırasında incelendi (file list --query=… veya node list --query=…). Sözleşme o fetch'i okuma olarak ele alır ve --yes, doğru hedefi doğruladığının açık onayıdır. Bu biçim, silme davranışı yerel ve kendine kapalı olan kaynaklar için geçerlidir; flag, ayrı bir zarf gidiş-dönüşü gerektirmeden eski bir id'den silmeyi önler.

Biçimler farklıdır çünkü sözleşme her operasyonun ne yaptığıyla eşleşir. Platform, operasyonun üretebileceği hata modunu yine de önleyen en hafif sözleşmeyi uygular.

Yıkıcı olmayan ne var

Update'ler kapılı değildir. ppl component update, ppl file update ve ppl backend update, geçirdiğin alanları uygular ve diğer her şeyi olduğu gibi bırakır. En kötü durum, başka bir update'in düzelttiği yanlış değiştirilmiş alandır; silme için en kötü durum, gerçekleşmeyen kaybolan kaynaktır. Platform onları farklı operasyonlar olarak ele alır ve onlara farklı sözleşmeler verir.

Listeleme, inceleme, getirme, deploy etme, redeploy etme, undeploy etme ve her salt okunur fiil de kapılı değildir. Bir deployment'ı sökmek geri alınabilirdir — aynı backend'den redeploy et. İlke tutarlıdır: geri alınamaz kaldırmaları kapı arkasına al, geri alınabilir operasyonları onaysız bırak.

Promote'u bir insana devret

Bir prerelease'i released kataloğuna promote etmek (ppl component promote) genel sözleşmeyi hareket ettirir — başka backend'lerin neyi pinleyeceği, latest ve default'un neye çözümlendiği. Önerilen akış bunu bir insan kararı olarak ele alır: otomatik bir akış prerelease'i kurar ve doğrular, ve bir kişi released kanalına kesinleştirmeyi yapar.

Promote'a kadar giden agent akışları güvenli adımda durur ve adayı açığa çıkarır — prerelease id'si ve release dalı. Bir kişi o adayı alır, onu üreten kanıt döngüsünü inceler ve promote'u çalıştırır. O devir, genel sözleşmeye yapılan bir değişikliği bilinçli bir insan kararı olarak tutan şeydir.

Tam tartışma için bkz. Release semantiği.

Sözleşme nasıl birleşir

Getir-ve-onayla deseni, platformun diğer korumalarıyla birleşir. Geçici test backend'lerini temizleyen bir takım lease'leri kullanır — lease'in commit'i ya da rollback'i onayın kendisidir, tam olarak lease'in sahip olduğu kaynaklara sınırlandırılmıştır. backend graph mutasyonlarıyla deneyen bir takım operasyon log'una güvenir — yıkıcı graph operasyonları, backend'in kendisi silinmediği sürece geri alınabilirdir. Otomasyon yazan bir takım, agent modunda açığa çıkan yıkıcı operasyon sözleşmelerine güvenir — zarf biçimleri, bir operasyonun yıkıcı olup olmadığını ve onay gerektirip gerektirmediğini makinece kararlaştırılabilir kılar.

Sözleşme, bir silmenin tek bir çağrıda bir okuma olmadan gerçekleşemeyeceğini garanti eder, her yüzeyde ve her çağıran için. Bu özellik, otomasyonun platformu sürmesini, her çağıranın kendi silme-onayı desenini yeniden icat etmesine gerek kalmadan sağlar.

Bu nereye oturur

Yıkıcı operasyonlar, platformun kaldırma sözleşmelerinin en doğrudan geçerli olduğu yerdir. Getir-ve-onayla sözleşmesi, kaynak başına onay biçimleri ve promote'taki insan devri birlikte bir kaldırmayı iki parçalı bir eylem yapar: satırı oku, sonra onayla. Her yıkıcı operasyon ek bir okuma ya da flag'e mal olur, ve karşılığında yanlış kaynağı yanlışlıkla silmek zorlaşır.

İlgili

Bu sayfa yardımcı oldu mu?