Kaynağı ve derleme tarifini sabitleyin
CI/CD kurulumu için depoyu, yayın dalını, tetikleyiciyi ve çalıştırılan komutları açık yazın. Derleme ortamının runtime sürümü ve bağımlılık kilidi kayıtlı olmalıdır. Yerel ortamda geçen komut CI ortamında farklı dosya veya ayar kullanıyorsa bu fark çözülür. Aynı commitin hangi girdilerle üretildiği bilinmeyen bir çıktı, yeniden üretilebilir teslim sayılmaz.
Cache derlemeyi hızlandırabilir fakat gerekli kontrolün yerine geçmez. Başarısız kurulumda lockfileı CI içinde sessizce yeniden oluşturmayın; değişiklik kaynakta incelenmelidir. Loglarda paket kurulumu, test, derleme ve dağıtımı ayrı sonuçlar olarak görünür tutun. Referans commit, çalışma kimliği ve artefakt kimliğini kaydedin. Önceki yeşil koşunun kanıtı, farklı commit veya farklı ortam için kendiliğinden geçerli olmaz.
Test kapılarını ve yayın kararını tanımlayın
Uygulama kabul kriterleri pipeline testlerine yön verir. Tür kontrolü, derleme, kritik işlev testi ve uygun güvenlik kontrollerinden hangilerinin zorunlu olduğunu yazın. Testin atlanması veya uyarıyla bitmesi başarıyla aynı değildir. Yeni sürüm için hangi koşunun kanıt kabul edildiğini ve hata durumunda sonraki adımın durduğunu doğrulayın.
GitHub'ın resmî dağıtım belgesi ortamlar, eşzamanlılık ve koruma kurallarını açıklar. Özelliklerin kullanılabilirliği hesap ve depo koşullarına bağlı olabilir; gerçek yapılandırmayı inceleyin. Yetkili kişi, onayladığı commit ve hedef ortamı görmelidir. Manuel onay ihtiyacını işin riskine göre tanımlayın. Sadece düğmenin varlığı erişim kontrolü sağlandığını kanıtlamaz; kimlerin onu kullanabildiğini sınayın.
Zorunlu kapı
Kritik kontrol başarısız veya çalışmamışsa dağıtım başlamaz. Kontrolün adı, çalışma kimliği ve başarısızlık davranışı doğrulanır.
Yetkili karar
Onay sahibi, kaynak sürümü ve hedef ortamı görür. Kapsam dışı bir yönetici geçişi varsa gerekçe ve yetki politikası açık kaydedilir.
OKUMADAN SONRAKİ ADIMA
Yayın sürecini değerlendirelim
Mevcut iş akışını, ortamları ve son yayın bulgusunu paylaşın.
Ortamları ve gizli değerleri sınırlandırın
API ve servis ortamlarında test ve üretim hedefleri, veritabanları, depolar ve yayın kimlik bilgileri ayrı olmalıdır. İki farklı ekranın aynı üretim verisine yazması gerçek ortam ayrımı değildir. Staging testlerinde canlı bildirim veya müşteri kaydı oluşturan işlemleri kontrol edin; sentetik veri ve onaylanmış hedefler kullanın. Gerçek talep göndererek kontrol yapmayın.
Microsoft'un Türkçe gizli bilgi rehberi kaynak ve yapılandırma dosyalarında anahtar saklamayı ele alır. Secret değerini loga yazdırmadan varlık ve yetki kapsamını doğrulayın. İstemci çıktısına servis anahtarı girmediğini kontrol edin. Yayın kimliği yalnızca gereken ortama ve işe erişmelidir. Ekipten ayrılma, token süresi dolması veya yanlış ortam hedefi için güncelleme sahibini belirleyin; kimlik bilgilerinin kendisini rapora eklemeyin.
Artefaktı sürümleyin ve veri geçişini ayrı hazırlayın
Sunucu uygulaması tesliminde dağıtılacak çıktıyı hash, sürüm veya platform kimliğiyle tanımlayın. “En son” etiketi değişebilir; kabul edilen çıktıyla yayınlanan çıktının aynı olduğu kanıtlanmalıdır. Staging ile üretim için yeniden derleme gerekiyorsa girdi farklarını açık kaydedin ve ilgili doğrulamayı yeniden yapın. Hangi yolun kullanıldığı belirsiz bırakılmaz.
Veritabanı değişikliği uygulama dosyasıyla aynı şekilde geri alınmayabilir. Migration sırası, veri etkisi, yedekleme ve eski/yeni uygulamanın şemayla uyumu değerlendirilir. İlk aşamada ekleme, ardından kod kullanımı, son aşamada kaldırma gibi ayrımlar proje ihtiyacına göre seçilir. Yedek var ifadesi geri yükleme denemesi değildir. Veri silen işlem için ayrı karar ve kurtarma kanıtı gerekir; sıradan kod yayınının arkasına gizlenmez.
| Teslim parçası | Kaydedilecek kanıt | Ayrı karar |
|---|---|---|
| Uygulama artefaktı | Commit ve hash/sürüm kimliği | Hangi ortama dağıtılacak |
| Yapılandırma | Secret olmayan anahtar isimleri ve kapsam | Değişiklik/geri alma sahibi |
| Veri geçişi | Migration kimliği ve deneme sonucu | Uyumluluk ve kurtarma yolu |
Sağlık kontrolünü kullanıcı görevine bağlayın
Web uygulaması yayın kontrolünde yalnızca bir HTTP 200 sonucu yeterli olmayabilir. Ana sayfa açılırken API, oturum veya veri kaynağı bozuk kalabilir. Uygulamaya uygun sentetik görev belirleyin: oturum açılan test ortamı, salt okunur kayıt görüntüleme veya kritik bağımlılığa kontrollü bağlantı. Kontrolün gerçek müşteri talebi üretmediğinden emin olun.
Dağıtım bittiğinde çalışma kimliği ile canlı sürüm kimliğini karşılaştırın. Hata oranı, yanıt davranışı ve kritik işlev için kabul sınırlarını projenin taban durumuna göre belirleyin; evrensel bir yüzde uydurmayın. Alarmın nereye ulaştığı ve kimin değerlendireceği yazılı olsun. İzleme penceresi dolmadan “hatasız yayın” iddiası kullanmayın. Belirli bir görevin çalışması bütün sistemin sağlıklı olduğu anlamına gelmediğinden kontrolün sınırını raporda belirtin.
Geri dönüşü deneyin ve yayın sonucunu kapatın
Yayın süreci kabulünde önceki çalışan artefaktın nerede bulunduğu ve geri dönüşü kimin başlatabileceği belli olmalıdır. Aynı ortama eşzamanlı iki yayın, sırayı ve sonucu bozabilir; çakışma davranışını tanımlayın. Devam eden yayını iptal etmek her aşamada aynı derecede güvenli değildir, özellikle veri işlemi başladıysa yarım duruma dikkat edilmelidir.
Kontrollü ortamda geri dönüş veya ileri düzeltme senaryosunu deneyin. Kod, yapılandırma ve veri için hangi yolun uygulanacağını ayrı yazın. Son kayıtta dağıtılan sürüm, hedef ortam, kapı sonuçları, sağlık gözlemi, açık bulgular ve sorumlu bulunur. Her eksik için yeniden test tarihi verin. Tekrarlayan hatalarda kapıyı kaldırmak yerine nedeni araştırın. Kontrol listesi yayın disiplinini görünür yapar; kesintisiz hizmet veya bütün risklerin sıfırlandığı anlamına gelmez.
Kontrol listesini al ve kapsamını değerlendir
E-posta ve telefon bu taleple ilgili iletişim içindir. Bülten aboneliği oluşturmaz.
KARAR VERMEDEN ÖNCE
Sık sorulan sorular
Yeşil pipeline başarılı yayın anlamına gelir mi?
Yalnızca tanımlı adımların sonuçlarını gösterir. Doğru artefaktın doğru ortamda çalıştığını ve gerekli kullanıcı görevlerinin geçtiğini ayrıca doğrulayın. Atlanan kontrol, başarısız olup tolere edilen iş ve yayın sonrası hata ayrı kaydedilmelidir.
Her yayın manuel onay ister mi?
İşin riski, erişim modeli ve kurum politikası belirler. Küçük, iyi doğrulanmış değişiklikler otomatik ilerleyebilir; veri veya kritik servis değişimi farklı karar gerektirebilir. Onay varsa kim, hangi commit ve ortam için yetkili açık yazılır.
Staging ve üretim aynı secretı kullanabilir mi?
Gereksiz ortak erişim ortam sınırını zayıflatır. Hangi kimliğin hangi kaynağa eriştiğini inceleyin; üretim yazma yetkisini test işine taşımayın. Secret değerlerini paylaşmadan isim, kapsam, sahibi ve yenileme ihtiyacını belgeleyin.
Geri dönüş yalnızca önceki kodu yayınlamak mıdır?
Hayır. Yapılandırma, veritabanı ve dış servis etkileri yeni koddan bağımsız kalabilir. Eski sürüm yeni şemayla çalışmayabilir. Geri dönüş planı kod, ayar ve veriyi ayrı ele alır; geri yükleme veya ileri düzeltme denemesi ister.
Bir test ara sıra başarısız oluyorsa kaldırmalı mıyız?
Önce nedenini araştırın: ortam, süre, veri veya gerçek davranış olabilir. Tekrar koşusunda hangi kanıtın değiştiğini kaydedin. Kritik kontrolü kaldırmak, sorun çözülmüş demek değildir; kapsam ve risk kararı açık verilmeden yayın kapısını gevşetmeyin.
KAPSAMI BİRLİKTE BELİRLEYELİM
Yayın sürecini değerlendirelim
Mevcut iş akışını, ortamları ve son yayın bulgusunu paylaşın.
CI/CD kapsamını görüş