Testler yeşilken hatalı sürüm nasıl canlıya çıkar?

Yeşil test sonucu tam olarak neyi söyler?

Yeşil bir test, belirli girdiler ve koşullar altında çalıştırılmış belirli kontrollerin geçtiğini söyler. Üretimde kullanılacak dosyaların aynı olduğunu, yapılandırmanın uygunluğunu veya gerçek kullanıcı trafiğinin kapsandığını kendiliğinden göstermez. Sorun bazen test eksikliği, bazen kanıt ile dağıtım arasındaki bağın kopmasıdır. Bu ikisini ayırmadan yalnızca daha fazla test eklemek, canlıya başka bir paket çıkarılması gibi basit bir hatayı çözmeyebilir. Önce test sonucunun hangi nesneye ve hangi koşullara ait olduğu belirlenmelidir.

Varsayımsal bir örnek düşünün: aynı commit test ortamında derleniyor, başarılı oluyor ve üretim makinesinde tekrar derleniyor. Bağımlılık çözümü, ortam değişkeni veya derleme aracı farklıysa ikinci çıktı farklı olabilir. Commit kimliği ortak olsa da paket kimliği aynı değildir. Bu yazı bir olay incelemesi veya Velocize'ın mevcut dağıtım mekanizmasının açıklaması değildir. İncelediğimiz soru, kaynak değişikliği ile üretimde gözlenen çalıştırılabilir çıktı arasında nasıl doğrulanabilir bir kanıt zinciri kurulacağıdır.

Commit, paket ve ortam kimliği neden ayrıdır?

Commit kaynak durumunu, paket özeti belirli çıktı baytlarını, ortam kimliği ise dağıtım hedefini tanımlar. Bir sürüm kaydında bunların yanında derleme girdileri, araç sürümleri, test edilen paket özeti ve yapılandırma revizyonu bulunabilir. Hareketli bir ‘latest’ etiketi yerine değişmez paket özeti kullanmak, hangi dosyaların onaylandığını somutlaştırır. Özetin kendisini doğrulamadan yalnızca dosya adına güvenmek yeterli değildir. Aynı adla ikinci dosya yüklenmesi veya etiketin taşınması eski onayın anlamını değiştirebilir.

Bu yaklaşım aynı paketin her ortamda mutlaka aynı davranacağı anlamına gelmez. Başlangıç ayarları, veri, haricî servisler ve yetkiler yine değişebilir. Bu yüzden paketin bir kez üretilip aynı baytlarla ilerletilmesi çıktı kimliği sorununu azaltır; çalışma zamanı eşdeğerliği için ayrıca kabul gerekir. Bir ortamda yeniden derleme zorunluysa bunu gizlemeyin: yeni paket yeni bir kimlik almalı ve hangi kanıtın o pakete yeniden üretildiği belirtilmelidir. Önceki paketin test sonucunu değişmiş çıktıya otomatik taşımayın.

Derleme kökeni bilgisi neyi kanıtlar, neyi kanıtlamaz?

SLSA provenance, bir çıktının nasıl üretildiğine ilişkin yapılandırılmış bilgi için başvuru sağlar. SLSA'nın doğrulama rehberi ise yalnızca belgenin varlığına bakmaktan daha kapsamlı bir doğrulama gereğini açıklar. Tasarımda çıktı özeti, güvenilen üretici kimliği ve beklenen kaynak ilişkisi kontrol edilebilir. Ancak bu makaledeki örnek bir SLSA uygulaması veya seviyelendirme beyanı değildir. Bir paketin kökeni doğru olsa bile kodun işlevsel olarak hatalı olması mümkündür; köken kanıtı kalite testinin yerine geçmez.

Kanıtın nereden geldiği de önemlidir. Paketle aynı yazılabilir klasörde bulunan ve herkesin değiştirebildiği bir JSON belgesini tek güven kaynağı yapmak dairesel doğrulama yaratır. Kanıtı üreten kimlik, değiştirme yetkisi ve kabul politikası ayrı düşünülmelidir. Onay, hangi paket ve hedef için verildiğini taşımalıdır; yeni bir commit veya paket eski onayı devralmamalıdır. Böylece inceleyen kişi yalnızca ‘pipeline yeşil’ bilgisini değil, hangi değişmez çıktı için hangi kontrolün çalıştığını görebilir.

Bölüm kaynakları: SLSA v1.2 — Provenance ↗SLSA v1.2 — Verifying artifacts ↗

Paket ile test kanıtı arasındaki bağ nasıl sınanır?

Aşağıdaki bağımsız Node.js örneği, paket baytları ile onaylanan özetin, test edilen özetin ve hedef yapılandırmanın eşleşmesini kontrol eder. Ardından paket, test kaydı ve yapılandırma ayrı ayrı değiştirildiğinde kapının reddettiğini gösterir. Örnek güvenilen girdileri aynı dosyada üretir; bu öğretici kolaylık gerçek bir imza ve kimlik doğrulaması sağlamaz. Üretim kapısı kanıtı güvenilir kaynaktan almalı, politika sürümünü belirtmeli ve başarısızlık kaydını inceleme için saklamalıdır.

Gerçek süreçte bütün kontroller aynı aşamada çalışmayabilir. Birim testleri kaynak ve derleme girdileriyle, paket üzerindeki testler doğrudan paket özetiyle, üretim sağlık kontrolü ise çalışan sürüm kimliğiyle ilişkilendirilebilir. Hangi kontrolün hangi nesne üzerinde yapıldığı açık kalmalıdır. Birim testlerini yapay biçimde paket testi diye sunmak da yanlış güven oluşturur. Aşağıdaki basitleştirme, paket düzeyinde bir kabul kontrolü bulunduğunu varsayar ve o kontrolün sonucunun farklı bir pakete taşınmasını önler.

const { createHash } = require('node:crypto');
const assert = require('node:assert/strict');
const digest = (bytes) => createHash('sha256').update(bytes).digest('hex');
const artifact = Buffer.from('illustrative-build-output-v1');
// These inputs must come from trusted evidence in a real deployment.
const approved = {
  artifactDigest: digest(artifact),
  environment: 'production',
  configRevision: 'config-7'
};
const evidence = { testedDigest: digest(artifact), testsPassed: true };
function gate(bytes, approval, tests, target) {
  assert.equal(digest(bytes), approval.artifactDigest, 'artifact mismatch');
  assert.equal(tests.testedDigest, approval.artifactDigest, 'untested artifact');
  assert.equal(tests.testsPassed, true, 'tests failed');
  assert.equal(target.environment, approval.environment, 'wrong environment');
  assert.equal(target.configRevision, approval.configRevision, 'config changed');
}
const target = { environment: 'production', configRevision: 'config-7' };
gate(artifact, approved, evidence, target);
assert.throws(() => gate(Buffer.from('different-build'), approved, evidence, target));
assert.throws(() => gate(artifact, approved, { ...evidence, testedDigest: 'other' }, target));
assert.throws(() => gate(artifact, approved, evidence, { ...target, configRevision: 'config-8' }));
console.log('Approved tuple accepted; changed artifact, evidence and config rejected.');

Aynı paket yanlış yapılandırmayla nasıl bozulur?

Yanlış servis adresi, eksik özellik bayrağı, farklı zaman aşımı veya yetersiz yetki, test edilen kodu üretimde farklı bir yola sokabilir. Yapılandırmanın gizli olmayan revizyonu ve hedef ortamı sürüm kaydına bağlanabilir. Gizli değerleri rapora veya herkese açık özete dökmek gerekmez; erişim denetimli bir sır referansı ve sürüm kimliği kullanılabilir. Başlangıçta gerekli alanları doğrulamak eksik ayarları erken yakalar, fakat haricî servise gerçekten bağlanılabildiğini tek başına kanıtlamaz.

GitHub ortam belgeleri, dağıtım hedefleri için koruma kuralları ve ortam ilişkisini açıklayan bir örnek kaynaktır; bu yetenekler hesabın ve yapılandırmanın koşullarına bağlıdır. Bir onay düğmesi teknik kanıt incelemesinin yerine geçmez. Onaylayan kişi paket, ortam, yapılandırma ve geçiş planını görebilmelidir. Bekleyen yayın sırasında yapılandırma değişirse önceki onayın ne olacağı tanımlanır. Böylece birkaç saat önce verilen onay, arada değişen fakat kimliği güncellenmeyen bir kurulum için yanlışlıkla kullanılmaz.

Bölüm kaynakları: GitHub — Deployments and environments ↗

Uygulamayı geri almak neden veritabanını geri almaz?

Yeni kod bir kolonu kaldırdıysa eski kodun yeniden başlatılması veri şemasını eski hâline getirmez. Benzer biçimde yeni biçimde yazılmış kayıtlar veya dış sisteme gönderilmiş işlemler dosya değiştirerek geri alınamaz. Geçiş tasarımında genişletme, birlikte çalışma ve daraltma aşamaları ayrılabilir. Önce eski kodun çalışmasını bozmayan ek alan eklenir; ardından yeni kod ve veri doldurma süreci uygulanır. Eski kullanımlar kaldırılmadan önce bütün çalışan sürümlerin ve geri dönüş penceresinin durumu doğrulanır.

Örneğin yeni bir durum alanı eklendiğinde eski ve yeni uygulamanın aynı veriyi hangi kuralla okuyacağı, çift yazım varsa çatışmanın nasıl çözüleceği belirlenmelidir. Veri doldurma işlemi tekrar çalıştırıldığında aynı sonucu vermeli ve kısmi başarısızlık görünür olmalıdır. Bu bir evrensel otomatik geçiş reçetesi değildir; işlemsellik, kilitler ve veri hacmi veritabanına göre değişir. Kabulde temsili dolu veri, karışık uygulama sürümleri ve yarıda kesilen geçiş birlikte denenmelidir.

Kademeli yayında hangi oranlara bakmalıyız?

Sadece toplam hata sayısı karşılaştırması yanıltıcı olabilir. Varsayımsal kontrol grubunda 20.000 istekte 40 hata varsa oran yüzde 0,2'dir. Yeni sürüm grubunda 1.000 istekte 8 hata varsa oran yüzde 0,8 olur; daha az toplam hata, daha düşük hata oranı demek değildir. Fark 0,6 yüzde puanıdır. Bu sayılar gerçek Gokbilge ölçümü veya istatistiksel kesinlik iddiası değildir. Karar için trafik bileşimi, zaman aralığı, örnek büyüklüğü ve belirlenen işletme eşiği birlikte incelenmelidir.

Kritik işlem yollarını ayrıca ayırın. Yeni grupta az kullanılan bir ödeme veya kayıt uç noktasına yalnızca on istek gelmiş ve biri hata vermiş olabilir; genel ortalama bu sorunu örter. Gecikme dağılımı, kuyruk birikimi ve arka plan işlerinin başarısı da gözlenmelidir. Süre dolduğu için otomatik ilerlemek yerine yeterli gözlem oluşmadığında bekleme davranışı tanımlanabilir. Kademeli trafik dağıtımı da altyapıda gerçekten uygulanmalı; yalnızca bir izleme grafiğinin bulunması canary yayını yapıldığı anlamına gelmez.

Gerçek bir geri dönüş deneyi neleri kapsar?

Geri dönüş hedefi önceki paketin dosya adıyla sınırlı olmamalıdır. Önceki paket özeti, uyumlu yapılandırma, veritabanı durumu, kuyruktaki işler ve haricî etkiler birlikte değerlendirilir. Yeni sürümün oluşturduğu bir iş eski sürüm tarafından okunamıyorsa trafik geri alınsa bile arka plan işlemleri durabilir. Kuyruk biçimi ve görev sürümü bu nedenle sözleşmenin parçasıdır. Geri dönüş sonrası sadece ana sayfanın açılması yerine temsili bir işin uçtan uca tamamlanması denenmelidir.

Tatbikatta süreyi ölçün ama tek başarı ölçütü yapmayın. Çalışan sürüm kimliği beklenen pakete dönmüş mü, yeni hata üretimi durmuş mu, bekleyen işler işleniyor mu ve veri tutarlılığı korunmuş mu sorularını ayrı yanıtlayın. Hedef süreler kurumun gerçek operasyon ihtiyacından türetilmelidir. Geri alınamayan bir şema değişikliğinde otomatik eski paketi başlatmak yerine durdurma veya kontrollü ileri düzeltme gerekebilir. Hangi durumda hangi yolun seçileceği yayın başlamadan önce belirlenmelidir.

• Çalışan paket özeti, onay ve paket testi aynı çıktıya bağlıdır.
• Yapılandırma değişikliği ve şema geçişi açıkça sürümlenmiştir.
• Geri dönüş veri, kuyruk ve haricî etki sınırlarıyla denenmiştir.
• Gözlem yetersizse ilerleme yerine bekleme veya durdurma kararı tanımlıdır.

Velocize değerlendirmesinde hangi kanıtlar istenmeli?

Velocize kamuya açık olarak yaşam döngüsü izlenebilirliği, kanıt odaklı teslimat ve hazırlık yönetişimi alanında beta ürün olarak konumlanır. Bu makaledeki kapı, SLSA referansları ve kademeli yayın senaryosu ürünün hazır entegrasyon veya seviye beyanı değildir. Değerlendirmede gereksinimden teste, testten pakete ve paketten yayına hangi bağlantıların gösterilebildiği sorulmalıdır. Var olan kanıtların toplanması, yeni kanıt üretilmesi ve dağıtım altyapısında değişiklik yapılması ayrı iş paketleri olabilir.

İlk çalışma için tek bir servis ve bir yayın türü seçilebilir. Örnek paket, test çıktısı, onay kaydı ve başarısız geri dönüş senaryosu üzerinden eksik bağlar çıkarılır. Endüstriyel yazılım yetenekleri entegrasyon tarafını, Batur ise yayın olaylarının günlük toplama bağlamını değerlendirmek için ilgili alanlardır; aralarında hazır bağlantı bulunduğu varsayılmaz. Sonuçta amaç daha fazla onay kutusu üretmek değil, belirli bir sürüm için ‘neyi, hangi kanıtla, hangi sınırlar içinde canlıya aldık?’ sorusuna yeniden üretilebilir cevap vermektir.