Hangi aracı pull request geçitleri birleştirmeyi engellemeli?

Bir araç temiz bir fark, ikna edici bir açıklama ve hızlı incelemeden geçen kod üretebilir, ama uygulamayı açıkta bırakabilir veya kurtarılamaz hâle getirebilir. Bu yüzden birleştirme kararı, aracın ne kadar kendinden emin göründüğüne ya da yamanın ne kadar küçük olduğuna değil, deponun ölçebildiği kanıta dayanmalıdır.

Yedi engelleyici geçit kullanıyorum: testler, CodeQL, bağımlılık incelemesi, gizli taraması, yetkilendirme kontrolleri, geçiş provası ve geri alma doğrulaması. Her biri farklı bir hata sorusunu yanıtlar. Yeşil bir test paketi yeni bir paketin güvenli olduğunu kanıtlayamaz; temiz bir statik analiz sonucu da veritabanı geçişinin en yoğun tabloyu kilitleyip kilitlemediğini söylemez.

Bu geçitler insan ve araç değişikliklerine eşit biçimde uygulanır. Araçların yazarlığı, hataların hacmini, hızını ve biçimini değiştirir, ancak daha zayıf ayrı bir hat için gerekçe oluşturmaz. Önerilen bir değişiklik başka herhangi bir pull request ile aynı kanıtı sunamıyorsa, birleştirilmeye hazır değildir.

Bir geçit tavsiye değil, kanıt üretmelidir

Bir birleştirme geçidi, korumalı dala girecek tam commit için yeniden üretilebilir bir başarılı ya da başarısız sonucu vermelidir. «Lütfen bu bağımlılığı inceleyin» diyen bir yorum tavsiyedir. Paketi, sürümü, uyarıyı ve önem eşiğini belirleyen zorunlu kontrol ise kanıttır.

Bu ayrım önemlidir; çünkü pek çok güvenlik özelliği varsayılan olarak yararlı karar anından sonra rapor verir. Bir tarayıcı uyarı oluşturabilir, e-posta gönderebilir veya iş açabilirken birleştirme düğmesi kullanılabilir kalır. Ekipler, değişikliği durduramadığı hâlde taramanın «etkin» olduğunu söyler. Her geçit için şu dört özelliği doğrulayın:

• Pull request'in güncel head commit'inde çalışır.
• Dal koruması, adı belirtilmiş sonucunu zorunlu tutar.
• Atlanan, zaman aşımına uğrayan veya çöken iş başarılı sayılmaz.
• Sonuç, kararı yeniden üretmek için yeterli ayrıntıyı kaydeder.

Politikayı depoda tutun. Küçük bir bildirim dosyası, yalnızca yöneticilerin bildiği ayar yığınından daha kolay incelenir:

merge_gates:
  tests: required
  codeql: required
  dependency_review: required
  secret_scan: required
  authorization: required
  migration_rehearsal: required_when_changed
  rollback_verification: required

required_when_changed değeri bir açık kapı değildir. Geçidin önce ilgili dosyaları algılayıp ardından provayı yapması veya temiz bir «uygulanamaz» sonucu kaydetmesi demektir. Yol filtrelerinin zorunlu bir kontrolü sürekli beklemede bırakmasına izin vermeyin; aracın kendi riskli değişikliğinin muaf olduğuna karar vermesine de izin vermeyin.

İş akışı izinlerini, her işin ihtiyaç duyduğu en düşük düzeyde sabitleyin. Pull request kodu, dal kuruluşunuza ait olsa bile güvenilmeyen girdidir. İncelediği koda yazma belirteci veya üretim gizlisi açığa çıkaran bir geçit, yakalamak üzere tasarlandığı sorundan daha kötü bir sorun yaratabilir.

Kontrolün kimliğini, mantığı kadar dikkatle koruyun. Dal kuralları genellikle bir durum adı ister; bu nedenle aynı adı bildirebilen iki iş akışı, daha zayıf bir işin kuralı karşılamasına yol açabilir. Politika işine benzersiz bir ad verin, iş akışını kimlerin değiştirebileceğini sınırlayın ve o dosyanın sahiplerinden inceleme isteyin. Birleştirme kuyruğu yeni bir birleştirme commit'i oluşturduğunda geçitleri bu commit'te yeniden çalıştırın veya sonuçları kuyruktaki revizyona bağlayan platform özelliğini kullanın. Dünkü head için olan kanıt, bugünkü birleştirme için kanıt değildir.

Geçit yapılandırmasını da hassas kod olarak ele alın. Eşiği değiştiren, yolu kaldıran, sorgu paketini düşüren veya istisna ekleyen bir pull request, sonraki her yeşil sonucun anlamını değiştirir. Politika farklarını görünür biçimde gösterin ve etkilenen denetimi anlayan bir bakımcının onayını isteyin. Bir araç böyle bir değişiklik önerebilir, ancak kendisini değerlendiren mekanizmayı düzenlediği için daha kolay geçmemelidir.

Testler gözlemlenebilir gerilemeleri engeller

Test geçidi, desteklenen çalışma zamanı ve veritabanı sürümlerinde belirtilen davranışı bozan her değişikliği engellemelidir. Kilitli bağımlılıklar, üretilen dosyalar, özellik bayrakları ve şema durumu dahil, birleştirme commit'inin kullanacağı aynı derleme girdilerini çalıştırmalıdır.

Araçlar özellikle en yakın doğrulamayı karşılamada iyidir. Bir testi yeşile çeviren geri dönüş eklerken hata işleme, sayfalama, eşzamanlılık ya da bitişik bir API sözleşmesini bozabilirler. Davranışı değiştiren pull request'in test eklemesini ya da değiştirmesini isteyin, ancak kaliteyi yeni test satırı sayısıyla ölçmeyin. Uygulama kaldırılır veya geri alınırsa testin başarısız olup olmayacağını inceleyin.

Yararlı bir test geçidinin ayrı adları olan katmanları vardır:

• Yerel mantık ve sınır durumları için birim testleri.
• Veritabanı, kuyruk, önbellek ve dış hizmet sözleşmeleri için entegrasyon testleri.
• Genel istek ve yanıt biçimleri için sözleşme testleri.
• Derlenmiş yapıt üzerinde küçük bir duman testi.

Titreşimli testleri, yeşil olana dek otomatik yeniden deneme tanımak yerine kök nedene kadar çalıştırın. Bir yeniden deneme tanı kanıtı toplayabilir, ancak nihai durum ilk hatayı göstermelidir. Aksi takdirde bir araç, kanıtlanmış tek özelliği bazen çalışması olan kodu birleştirebilir.

Duman testi yapıtı başlatmalı, bir sağlık uç noktasını ve anlamlı bir yazma yolunu çalıştırmalı, ardından temiz biçimde durdurmalıdır. Paketlenmiş uygulamayı başlatmadan kaynak kodunu test etmek; eksik dosyaları, kötü ortam varsayılanlarını, bozuk geçişleri ve başlangıç paniklerini kaçırır. Bir web hizmeti için sonuç şu kısa biçimde kaydedilebilir:

{"commit":"abc123","build":"pass","startup_ms":842,"health":200,"write_read_cycle":"pass"}

Evrensel bir kapsam yüzdesini ana geçit olarak belirlemeyin. Kapsam, test edilmemiş değişikliği ortaya çıkarabilir; ancak bir depo zayıf doğrulamalarla yüksek yüzdeye ulaşabilir. Zorunlu paketlere ve değişen davranışa göre geçit koyun, ardından kapsam hareketini inceleme kanıtı olarak kullanın.

Testleri, değerlendirdikleri uygulamadan koruyun. Bir pull request hem bir kuralı değiştirip hem de doğrulamaları yeni sonucu kabul edecek biçimde yazarsa, paket geçerken sözleşme sessizce kayabilir. İnceleyenden değişen testleri genel API, iş veya kabul kuralıyla karşılaştırmasını isteyin. Ayrıştırıcılar, doğrulayıcılar, faturalama mantığı ve erişim kontrolleri için mutasyon testi veya kasıtlı olarak hatalı girdilerden oluşan küçük bir küme ekleyin. Yararlı soru, paketin makul ama yanlış bir uygulamayı reddedip reddetmediğidir; aracın kendi yazdığı doğrulamaları kendi uygulamasına uydurup uyduramadığı değil.

Geçit başarısız olduğunda test yapıtlarını saklayın. Rastgeleleştirilmiş testler için başarısız tohumu, tam veritabanı imajını, gizliler çıkarılmış hizmet günlüklerini ve çalıştırmayı yeniden üreten komutu depolayın. Yeniden üretim verisi olmayan bir durum, sonraki aracı veya mühendisi tahmin yürütmeye geri gönderir. Yapıt saklama süresini deponun veri kurallarına göre sınırlayın ve bir hatayı yeniden üretmeyi kolaylaştırıyor diye üretim anlık görüntüsü yüklemeyin.

CodeQL, güvenlik açıklarına giden bilinen kod yollarını engeller

CodeQL geçidi, CodeQL'in gerçekten analiz ettiği dillerde ve üretilmiş yapıtlarda yüksek güven düzeyindeki yeni bulguları engellemelidir. Temiz bir sonucun tüm uygulamanın güvenli olduğunu kanıtladığını ima etmemelidir.

GitHub, CodeQL'i kodu sorgulanabilir bir veritabanına derleyip üzerinde sorgular çalıştırmak olarak tanımlar. Bu model, yalnızca şüpheli metinleri eşlemek yerine verinin kod içindeki akışını izlediği için yararlıdır. Dil desteği, derleme başarısı, sorgu seçimi ve analiz sırasındaki kodla sınırlıdır. Veritabanı derlemesi bir hizmeti sessizce dışarıda bırakırsa, yeşil sonuç inceleyenlerin düşündüğünden daha azını kapsar.

Açık dilleri ve sabit bir sorgu politikasını içeren iş akışı kullanın:

name: codeql
on: [pull_request]
permissions:
  contents: read
  security-events: write
jobs:
  analyze:
    strategy:
      matrix:
        language: [javascript-typescript, go]
    steps:
      - uses: actions/checkout@v4
      - uses: github/codeql-action/init@v3
        with:
          languages: ${{ matrix.language }}
          queries: security-extended
      - uses: github/codeql-action/autobuild@v3
      - uses: github/codeql-action/analyze@v3

Gerçek bir depoda üçüncü taraf eylemlerini incelenmiş commit özetlerine sabitleyin. Etiketler örneği okunur kılar, ancak değiştirilebilir etiket zorunlu güvenlik işinin güven sınırını genişletir.

İlk uyarı ortaya çıkmadan önce neyin engelleneceğine karar verin. Genellikle mevcut borç temel çizgide görünür kalırken, deponun üzerinde anlaştığı önem ve kesinlik eşiğinde yeni bulguları engellerim. İlk günden tüm geçmiş sonuçları engellemek toplu reddetmeyi teşvik eder. Mevcut sonuçların tümünü sonsuza dek yok saymak kalıcı kör nokta yaratır. Bunun yerine temel çizgiye sahipler ve son tarihler atayın.

Hizmetler, diller veya derleme komutları değiştiğinde analiz edilen dosya kümesini inceleyin. Yeni bir mobil istemci, üretilmiş çözücü veya ayrı bir arka uç getiren pull request, başka analiz aracı veya derleme adımı gerektirebilir. «CodeQL geçti» ifadesi ancak inceleyenler CodeQL'in neyi incelediğini söyleyebildiğinde anlamlıdır.

Analiz hatalarını temiz analizlerden ayrı tutun. Otomatik derleme paketi derleyemezse iş, sıfır bulgu değil altyapı veya yapılandırma hatası bildirmelidir. Veritabanı oluşturma günlüğünü ve dil başına analiz edilen kaynak dosyası sayısını kaydedin. Bu sayıları temel dalla karşılaştırın ve açıklanmayan büyük düşüşü işaretleyin. Bu, sıradan bir hatayı yakalar: bir derleme düzenlemesi güvenlik açığı olan modülü dışarıda bırakır, analiz hızlanır ve güvenlik kontrolü daha az kod gördüğü için yeşile döner.

Reddetmeleri temizlik değil politika değişikliği olarak inceleyin. Yanlış pozitif için kod yolu ve sorguyla bağlantılı somut açıklama gerekir. Bastırma yorumları dar kapsamlı, sahipli ve pull request farkında görünür olmalıdır. Üretilen dosyalar için depo genelinde dışlama uygun olabilir, ancak önce o dizinde elle bakımı yapılan şablonların veya üretici girdilerinin bulunmadığını saptayın.

Bağımlılık incelemesi, kurulmadan önce riski durdurur

Bağımlılık incelemesi, bağımlılık farkı açık bir politikayı ihlal eden paket veya sürüm getirdiğinde pull request'i engellemelidir. Politika bilinen uyarı önemini, yasaklı lisansları, beklenmeyen paket kaynaklarını ve sahibi olmadan eklenen doğrudan bağımlılıkları kapsayabilir.

Bu geçit, depo güvenlik açığı uyarısından farklıdır. Uyarı, dalda güvenlik açığı olan bağımlılık bulunduğunu söyler. Bağımlılık incelemesi ise pull request'in bağımlılık grafiğini kötüleştirip kötüleştirmediğini sorar. GitHub'ın bağımlılık incelemesi, bildirim dosyalarını ve kilit dosyalarını pull request boyunca karşılaştırır; bu da kararı zamanında ve atfedilebilir kılar.

Kilit dosyası tutarlılığını zorunlu tutun. Araç package.json dosyasını değiştirip kilit dosyasını değiştirmezse veya eşleşen bildirim değişikliği olmadan kilit dosyasını düzenlerse iş başarısız olmalıdır. CI sırasında yeni sürümleri çözen kurulum komutları sonucu belirlenimsiz kılar ve inceleyenlerin gördüğünden farklı grafiği test edebilir.

Kısa bir politika şöyle olabilir:

dependency_policy:
  fail_on_severity: high
  deny_licenses:
    - AGPL-3.0
  allow_sources:
    - registry.npmjs.org
    - proxy.golang.org
  require_owner_for_direct_additions: true

Tam lisans listesi körü körüne kopyalanacak bir değer değil, hukuk ve ürün kararıdır. Yararlı olan, deponun bunu bildirmesi ve kontrolün tetikleyen paketi yazdırmasıdır.

Bir paketi, adı önerilen kitaplığa benziyor diye otomatik onaylamayın. Araçlar paket adlarını uydurabilir, terk edilmiş çatalları seçebilir veya küçük bir yardımcı iş için büyük istemci ekleyebilir. İnceleme çıktısı yeni doğrudan ve geçişli paketleri, kaynak kayıt defterini, çözümlenen sürümü, lisansı ve uyarı durumunu göstermelidir. İnceleyen ardından mevcut kodun ya da daha küçük bir bağımlılığın sorunu zaten çözüp çözmediğini sorabilir.

Bağımlılık hizmeti fark üretemezse güvenli tarafta kalın. Kullanılamayan bir uyarı akışı, belirsizliği yeşil kontrole dönüştürmek yerine birleştirmeyi bekletmek için gerekçe olabilir. Acil durum yordamları, gerekçesi commit'e eklenmiş olarak adı belirtilen bakımcının belgelenmiş geçersiz kılmasına izin verebilir.

Kurulum davranışını, ağ erişimi onaylı kayıt defterleriyle sınırlı yalıtılmış bir işte denetleyin. Yaşam döngüsü betikleri ve derleme eklentileri kurulum sırasında kod çalıştırır; bu yüzden uygulama paketi hiç içe aktarmasa bile tehlikeli olabilir. Yeni bağımlılığın kurulum betikleri, yerel ikili dosyalar veya alışılmadık bir kayıt defteri ekleyip eklemediğini kaydedin. Bu işi yayımlama kimlik bilgileri, bulut belirteçleri veya güvenilir derlemelerle paylaşılan yazılabilir paket önbelleğiyle çalıştırmayın.

Satıcıdan gelen kod ve konteyner imajları, sıradan bildirim incelemesi onları kaçırsa da aynı kararın parçasıdır. İmaj özetlerini, temel imaj adlarını, Git alt modüllerini ve depoya eklenmiş arşivleri karşılaştırın. Sürüm girdileri için değişmez özetler isteyin. latest gibi dostça bir etiket, baytlar başka fark olmadan değişebildiği için pull request'i sonradan yeniden üretilemez yapar.

Gizli taraması farkı ve geçmişi incelemelidir

Gizli taraması, pull request bir kimlik bilgisi örüntüsü veya doğrulanmış canlı gizli getirdiğinde engellemelidir. Bu dize test sabitinde, silinmiş dosyada, üretilmiş pakette veya pull request içindeki önceki commit'te bulunsa bile geçerlidir.

Gönderim koruması ve pull request taraması bağlantılı ancak farklı sorunları çözer. Gönderim koruması, tanınan gizliyi uzak depoya ulaşmadan durdurabilir. Pull request geçidi, çoktan gelenleri inceler ve gönderim korumasının kaçırdığı katkıcıları veya belirteç türlerini kapsayabilir. Dal koruması olmayan uyarı, birleştirmeyi engellemez.

Yalnızca son dosya sistemini değil, temel dala karşı tüm commit aralığını tarayın. Araç bir commit'te belirteç ekleyip sonraki commit'te kaldırabilir; belirteç Git geçmişinde kalır ve günlükler veya önbelleklere çoktan ulaşmış olabilir. Sonucu açığa çıkmış sayın. Kimlik bilgisini iptal edin veya döndürün, önerilen geçmişten çıkarın ve kontrolü yeniden çalıştırın.

Kimlik doğrulaması yapamayan sentetik sabitler kullanın. Sabit kendini açıkça tanımlamalı ve gerçek bulut anahtarının biçimini kopyalamak yerine yerel olarak tanımlanmış test örüntüsüyle eşleşmelidir. Geniş izin listeleri tehlikelidir; çünkü hem saldırganlar hem kazalar eninde sonunda yok sayılan dizini bulur. İstisnaları kesin, incelenmiş ve algılayıcı yapılandırmasına yakın tutun.

Örüntü algılayıcılarını entropi kontrolleriyle ve sağlayıcının güvenle desteklediği yerlerde kimlik bilgisi doğrulamasıyla birleştirin. Örüntü eşleme daha az ağ ve ifşa riski taşır, ancak özel belirteçleri kaçırır. Doğrulama belirsizliği azaltabilir, fakat aday gizlinin bir bölümünü başka hizmete gönderir ve pull request'in sağladığı güvenilmeyen uç noktaya karşı asla çalışmamalıdır. Hangi algılayıcıların doğrulama yaptığını, hangilerinin yerelde kaldığını ve hangi verinin CI'dan çıktığını belgeleyin.

Her rastgele dizenin kimlik bilgisi olduğunu varsaymadan yaygın kodlanmış biçimleri ve üretilmiş çıktıları tarayın. Base64, URL kodlama ve küçültülmüş paketler, bir kaynak adımında açıkça görünen gizliyi saklayabilir. Engelleme eşiğini test edilmiş sabitlere göre ayarlayın, ardından algılayıcı güncellemelerini diğer politika değişiklikleri gibi inceleyin. Gürültülü tarayıcı bakımcıları sonuçları reddetmeye alıştırır; sessiz tarayıcı ise sahte güven yaratır.

Geçit çıktısı, gizliyi açıklamadan konumu göstermelidir:

{"result":"fail","detector":"generic-api-token","commit":"abc123","path":"config/dev.env","line":7,"fingerprint":"sha256:8f2c..."}

Tam eşleşmeyi asla CI günlüklerine veya pull request yorumuna yazdırmayın. Tarayıcı çıktı ürettikten sonra maskeleme çok geç olabilir; günlük sistemleri, bildirimler ve iş yapıtları bunu kopyalayabilir.

Gizli taraması, depo izin incelemesinin yerini tutmaz. İş akışı, üretim kimlik bilgisini farka koymadan okuyabilir ve araç dağıtım işini değiştirerek onu dışarı aktarabilir. Gizlileri pull request işlerinden uzak tutun, iş akışı izinlerini sınırlayın ve CI tanımı değişiklikleri için insan incelemesi isteyin.

Yetkilendirme kontrolleri, yasak eylemlerin yasak kaldığını kanıtlar

Yetkilendirme geçidi, korunan her işlemin yanlış aktörü reddettiğini ve amaçlanan aktöre hizmet sınırında izin verdiğini kanıtlamalıdır. Yalnızca giriş testleri yetkilendirmeyi test etmez.

Ekipler kimlik doğrulama, yetkilendirme ve kullanıcı arayüzü görünürlüğünü sürekli birbirine karıştırır. Kimlik doğrulama, isteği kimin gönderdiğini belirler. Yetkilendirme, bu kimliğin bu nesne üzerinde bu eylemi yapıp yapamayacağına karar verir. React'te yönetici düğmesini gizlemek, Go API'deki iki kararı da değiştirmez. Arka uç isteği kabul ederse uygulama açıkta kalır.

Değişen uç noktalar ve iş eylemleri için izin matrisi oluşturun. İncelenebilir kalacak kadar küçük olsun, ancak sahiplik ve kiracı sınırlarını içersin:

read_private_project:
  anonymous: deny
  member: deny
  other_tenant: deny
  owner: allow
  admin: allow
update_project:
  anonymous: deny
  other_tenant: deny
  owner: allow

Bu matristen testler üretin veya hizmet dilinde eşdeğer tablo odaklı durumlar yazın. Her ret durumu, gerçekçi tanımlayıcılarla gerçek işleyiciyi çağırmalıdır. Yetkilendirme ara yazılımını değiştiren sahteler, denetimi atlayarak rotanın çalıştığını kanıtlayabilir.

Yalnızca rolleri değil, nesne düzeyindeki erişimi test edin. İki kullanıcı da member rolünde olabilir, ama farklı kuruluşlara ait olabilir. Güvensiz doğrudan nesne başvurularını yakalamak için kaynak tanımlayıcısını ve kiracı tanımlayıcısını bağımsız değiştirin. Sıradan REST işleyicileri için yazılmış kontrolleri sıkça atlayan toplu uç noktaları, dışa aktarımları, arka plan işlerini ve GraphQL çözücülerini de test edin.

Yeni korunan rotanın politika eşlemesi yoksa geçidi başarısız yapın. Bu, eksik yetkilendirmeyi inceleyenin sezgisi olmaktan çıkarıp ölçülebilir kusura dönüştürür. Sunucudaki varsayılan ret olsun. Açık izin kuralını denetlemek, birkaç bilinen kötü durumu reddeden dağınık koddan daha kolaydır.

Araçlar sıkça yakındaki işleyiciyi yeniden kullanır ve sahiplik kontrolünü düşürürken onun başarılı yolunu korur. İzin matrisi bu eksikliği görünür kılar. Roller veya kiracı kuralları sonradan değiştiğinde inceleyenlere sabit sözleşme de verir.

Yetkilendirmeyi girdi normalleştirmesinden sonra çalıştırın. Büyük küçük harf katlama, alternatif tanımlayıcı biçimleri, yinelenen sorgu parametreleri ve iç içe nesne başvuruları eşdeğer istekleri farklı kod yollarına gönderebilir. Doğrudan uç noktayı ve aynı işleme ulaşan toplu ya da içe aktarma rotalarını test edin. Son yazmayı arka plan çalışanı yapıyorsa, çalışanı sınırsız güçlü güvenilir kullanıcı saymak yerine aktör ve kiracı bağlamını işe aktarın.

Beklenen kararı ve onu üreten politika kuralını kaydedin, ancak günlüklerde özel nesne verisini açığa çıkarmayın. Yararlı hata, aktör sınıfını, eylemi, nesne sınıfını ve beklenen durumu adlandırır. Erişim belirtecini veya tam kaydı dökmez. Bu kanıt, inceleyenin bozuk test sabitiyle gerçek yetki değişikliğini ayırt etmesini sağlar.

Geçiş provası, kilitleri ve geri döndürülebilirliği ölçer

Geçiş geçidi, önerilen her şema değişikliğini üretime benzer kopyaya uygulamalı, uyumluluk yoklamaları çalıştırmalı ve birleştirmeden önce süreyi, kilitleri ve geri alma davranışını kaydetmelidir. Boş test veritabanında başarılı olan geçiş çok az şey kanıtlar.

Benzer tablo boyutları, dizinler, kısıtlar ve dağılımlarla temizlenmiş anlık görüntü veya üretilmiş veri kümesi kullanın. Tam üretim verisi pull request altyapısına ait değildir. Amaç kişisel veya gizli kayıtları kopyalamadan operasyonel baskıyı yeniden oluşturmaktır.

Gerçek dağıtım sırasını prova edin. Geçiş çalışırken eski uygulama örnekleri etkin kalıyorsa eski kodu yeni şemaya, yeni kodu geçiş şemasına karşı test edin. Boş değer kabul eden sütun eklemek genellikle uyumludur. Sütunu tek adımda yeniden adlandırmak, hâlâ trafik sunan tüm eski örnekleri bozabilir.

Kanıtı makine tarafından okunabilir sonuçta kaydedin:

{"migration":"20260727_add_project_state","apply_ms":18420,"max_lock_ms":310,"old_app_probe":"pass","new_app_probe":"pass","down":"pass"}

Eşikleri veritabanı ve tablo sınıfına göre belirleyin. 300 milisaniyelik kilit bir tablo için zararsız, diğeri için bozucu olabilir. İnceleyenler seçilen sınırı ölçülen sonucun yanında ve provada kullanılan veritabanı sürümüyle birlikte görmelidir.

PostgreSQL için tabloyu yeniden yazan, kısıtı doğrulayan veya yazmaları engellerken dizin oluşturan işlemleri inceleyin. Genişlet ve daralt değişikliklerini tercih edin: yeni biçimi ekleyin, iki biçimi de kullanabilen kodu dağıtın, kontrollü toplu işlemlerle geri doldurun, okumaları değiştirin, sonra eski biçimi sonraki değişiklikte kaldırın. Fazladan pull request, kesinti sırasında doğaçlama yapmaktan daha ucuzdur.

Her geçişin güvenli down işlemi olamaz. Sütun bırakmak veri kaybettirir, dönüşümü tersine çevirmek belirsiz olabilir. Bu durumlarda geçit, ileri kurtarma yordamı ve test edilmiş yedek geri yükleme noktası istemelidir. Bir down dosyası var diye geri döndürülemez geçişi «geri alma güvenli» diye adlandırmak dürüst değildir.

Yeniden denemeleri ve kısmi hatayı test edin. Dağıtım, dizin oluşturduktan ama geçişi tamamlandı diye kaydetmeden durabilir; sonraki deneme durumu bozmamalı veya sonsuza kadar başarısız olmamalıdır. Prova kontrollü sınırda kesintiye uğratın, yeniden çalıştırın ve şema ile geçiş defterinin uyuştuğunu doğrulayın. Uzun geri doldurma için toplu işlemlerin kaydedilmiş imleçten sürdüğünü, aynı toplu işlem iki kez çalıştığında veriyi çoğaltmadığını veya silmediğini kanıtlayın.

Geçen süre kadar disk ve çoğaltma etkilerini de kontrol edin. Tabloyu yeniden yazmak geçici alan tüketebilir, yazma öncesi günlükleri büyütebilir ve ana işlem tamamlanmış görünürken kopyaları geciktirebilir. Geçidin kusursuz üretim tahminine ihtiyacı yoktur, ancak bu nicelikleri prova veri kümesinde kaydetmeli ve veritabanı sahibinin seçtiği sınırlarla karşılaştırmalıdır. Bu kanıt olmadan hızlı yerel geçiş bile üretim birimini tüketebilir.

Geri alma doğrulaması kurtarma yolunu çalıştırmalıdır

Geri alma geçidi, adayı yalıtılmış ortama dağıtmalı, temsili durum oluşturmalı, desteklenen geri alma yöntemini tetiklemeli ve önceki sürümün hâlâ doğru okumalar ve yazmalar sunduğunu kanıtlamalıdır. Yazılı geri alma planı doğrulama değildir.

Uygulama geri almasını veri geri almasından ayırın. Trafiği önceki ikili dosyaya yeniden yönlendirmek saniyeler sürebilir, oysa yıkıcı şema veya veri dönüşümünü geri almak imkânsız olabilir. Geçit ikisini de raporlamalıdır. Eski uygulama yeni şemayla çalışamıyorsa adayı geri döndürülemez olarak işaretleyin ve aşamalı dağıtım planı isteyin.

Uygulanabilir bir sıra şöyledir:

1. Geçerli main commit'ini dağıtın ve temsili kayıtları hazırlayın.
2. Pull request yapıtına yükseltin ve değişen yolları çalıştırın.
3. Yükseltilmiş durumda yeni kayıtlar oluşturun.
4. Belgelenmiş denetimi kullanarak önceki yapıtı veya anlık görüntüyü geri yükleyin.
5. Okuma, yazma, kuyruk ve arka plan işi yoklamalarını çalıştırın.

Kontrol; yapıt tanımlayıcılarını, anlık görüntü tanımlayıcılarını, zaman damgalarını ve yoklama sonuçlarını saklamalıdır. Kimlik bilgilerini veya kopyalanmış müşteri verilerini tutmamalıdır. Kurtarma süresini evrensel vaat olarak değil, kendi işletim hedefiniz için kanıt olarak ölçün.

Anlık görüntüler ancak uygulamanın ihtiyaç duyduğu her şeyi içerdikleri kanıtlanırsa yardımcı olur. Dosyalar, nesne depolama, kuyruk durumu, şema değişiklikleri ve dış yan etkiler sunucu anlık görüntüsünün dışında yaşayabilir. Bu sınırları sonuçta listeleyin. Gönderilmiş ödeme, e-posta veya web kancası veritabanını geri yükleyerek geri alınamaz.

Geri alma yoklamasını sağlık kontrolünden daha güçlü kılın. Yükseltmeden önce oluşturulan kaydı okuyun, sonrasında oluşturulanı okuyun, uyumluluk izin verdiğinde ikisini de güncelleyin ve her uygulama sürümünün oluşturduğu kuyruk işini işleyin. Yalnızca durum kodlarını değil kullanıcıya görünen çıktıyı karşılaştırın. Yeni alanı düşürürken veya enum'u yanlış okurken 200 döndüren sunucu kurtulmuş değildir.

Nöbetteki kişinin kullandığı denetimi test edin. Üretimde geri alma yapıt seçmeyi, anlık görüntü geri yüklemeyi veya trafiği değiştirmeyi gerektiriyorsa yalıtılmış prova aynı arayüzü ve izin yolunu kullanmalıdır. Bir mühendisin dizüstü bilgisayarındaki özel betik operasyonel denetim değildir. Kanıt, belirlenmiş operatör rolünün kalıcı yönetici erişimi almadan kurtarmayı tamamlayabildiğini göstermelidir.

Koder.ai kaynak dışa aktarma, dağıtım ve barındırma, anlık görüntüler ve geri alma özelliklerini destekler. Bu nedenle orada oluşturulan uygulamalar, kurtarmayı pull request'te bir paragraf gibi ele almak yerine geçitte bu somut yapıtları kullanabilir. Aynı kural her platformda geçerlidir: kurtarma denetimini çalıştırın ve geri yüklenen uygulamayı yoklayın.

Tek zorunlu kontrol yedinin tümünü özetlemelidir

Nihai birleştirme kararı, tam head commit için yedi temel sonucu doğrulayan tek, sabit politika kontrolünü zorunlu tutmalıdır. Tekil iş adları değişir, matris işleri çoğalır ve isteğe bağlı yollar işi atlar. Küçük bir birleştirici, dal korumasının politikadan uzaklaşmasını önler.

Her geçidin commit'i, politika sürümünü, sonucu ve kanıt konumunu içeren imzalı veya platform tarafından doğrulanmış bir sonuç üretmesini sağlayın. Birleştirici eksik, bayat, nötr veya iptal edilmiş sonuçları reddeder. Rapor vermeyen işten asla başarı çıkarımı yapmamalıdır.

{
  "commit": "abc123",
  "policy": "merge-gates-v3",
  "results": {
    "tests": "pass",
    "codeql": "pass",
    "dependency_review": "pass",
    "secret_scan": "pass",
    "authorization": "pass",
    "migration_rehearsal": "not_applicable",
    "rollback_verification": "pass"
  },
  "decision": "allow"
}

Acil durumlar yaşandığı için dar bir geçersiz kılma yolu tanımlayın. Adı belirtilen bakımcı, ikinci onaylayan, yazılı gerekçe, son kullanma tarihi ve takip işi isteyin. Aracın kendi istisnasını istemesine veya onaylamasına izin vermeyin. Olay geçtikten sonra da görünür kalmaları için geçersiz kılmaları normal geçit sonuçlarıyla aynı yerde bildirin.

Bu kontroller bazı pull request'lere dakikalar, geçiş değişikliklerine ise çok daha uzun süre ekleyecektir. Süre belirli kanıt sağlıyorsa bu kabul edilebilir. Ucuz geçitleri erken çalıştırın, geçersiz kalmış commit'leri iptal edin, güvenilir derleme girdilerini önbelleğe alın ve tam ortam provasını ilgili yollar için ayırın. Gösterge panelini daha hızlı yeşile çevirmek için geçidi zayıflatmayın.

Önce mevcut davranışı gözlemlenebilir kılın. Yedi adın tümünü tek politika dosyasına koyun, her birini zorunlu sonuca bağlayın ve atlanan işin kendini açıklamasını zorunlu tutun. Bu kaydı üretemeyen ilk aracı pull request, üretimdeki açığı bulmadan önce teslim sistemindeki deliği bulmuş olur.