Sık yayımlayan ekipler için release yönetimi süreci

Release yönetimi süreci, bir değişikliği “merge edildi”den “üretimde çalışıyor ve etkilediği insanlara anlatıldı”ya taşıyan adımlar bütünüdür. Sık yayımlayan bir ekip için yedi adıma iner: kapsamı planla, değişikliği izole et, build ve test et, onayla, deploy et ve doğrula, duyur ve gözden geçir. Her adımın belli bir sahibi ve bir çıkış ölçütü olmalı, yoksa sessizce yapılmaz olur.

Bu rehber, haftalık ya da günlük deploy eden ve sürecin yoldan çekilmesini isteyen, 5 ila 50 mühendislik ekibi varsayar.

Release yönetimi süreci nedir?

Bir değişikliğin kullanıcılara ulaşmak için izlediği tekrarlanabilir yoldur: kapsam, build, test, onay, deploy, doğrulama, duyuru ve geriye bakış. Yazılı hâle getirmenin amacı, her release’in aynı yolu izlemesidir; böylece tatildeki bir kişi, yeni bir çalışan ya da gece 2’deki nöbetçi mühendis, kimseye nasıl çalıştığını sormadan onu yürütebilir.

Release yönetiminin farklı türleri nelerdir?

Üç pratik tür var: sürekli deployment, zamanlanmış release’ler ve düzenlemeye tabi değişiklik yönetimi. Bir release’ten önce ne kadar şey olduğu ve ne kadarının otomatik olduğu bakımından ayrılırlar. Sürekli deployment merge edilen her değişikliği yayımlar, zamanlanmış release’ler değişiklikleri bir trene toplar ve düzenlemeye tabi değişiklik yönetimi resmi onay ve bir denetim izi ekler.

Çoğu ekip bir karışımdır. Bir SaaS ürünü sürekli deploy ederken mobil uygulaması haftalık bir trenle çıkabilir ve denetçilerin önemsediği tek ödeme servisi resmi bir değişiklik kaydını izler. Türü şirkete göre değil servise göre seçin. Değişikliklerin sadece kademeli olarak açıldığı yerde release ve duyuru ayrı olaylara dönüşür, bu da feature flag release notları yazısının ele aldığı durumdur.

Release manager’ın sorumlulukları nelerdir?

Release manager, bir değişikliğin üretime giden yolunun sahibidir. Release takvimini tutar, bir değişikliğin hazır olup olmadığına karar verir, deploy’u yürütür ya da denetler, rollback kararını verir, kullanıcılara haber verilmesini sağlar ve sonrasındaki gözden geçirmeyi yürütür.

Release’ten önce kapsamı doğrular ve her riskli değişikliğin bir rollback yolu olup olmadığını kontrol eder. Sırasında deploy kontrol listesini yürütür, üretim metriklerinin ilk dakikalarını izler ve rollback’i erken çağırır. Sonrasında notların çıktığını doğrular ve süreçte neyin düzeltileceğini kaydeder.

Küçük bir ekipte rolü haftalık döndürün ve kontrol listesini kimsenin sözlü bilgiye ihtiyaç duymayacağı şekilde yazın. Bağımsız olarak yayımlanan birçok paketi olan bir monorepo genellikle paket başına bir release sahibi ister, yoksa rol bir darboğaza dönüşür.

Release yönetimi için temel KPI’lar nelerdir?

DORA yazılım teslimat metriklerini izleyin ve kendinizden bir tane ekleyin: kullanıcılara haber verilmesinin ne kadar sürdüğü. DORA’nın araştırması, üretim hızı (değişiklik lead time’ı, deployment sıklığı, başarısız deployment kurtarma süresi) ve kararsızlık (değişiklik başarısızlık oranı, deployment yeniden iş oranı) diye ayrılan beş metriği belirler.

DORA’nın rehberi bunları düz terimlerle tanımlar (dora.dev, software delivery metrics):

Eski kaynaklar dört anahtar sayar ve kurtarmaya “time to restore” der. Güncel rehber yukarıdaki beşini kullanır.

Aynı rehber bunları hedef olarak ele almaya karşı uyarır. “Her şey yıl sonuna kadar günde birkaç kez deploy edilsin” gibi bir hedef koymak, ekipleri sayıları oynamaya davet eder ve metriklerin şirket genelinde harmanlanmak yerine uygulama ya da servis başına okunması amaçlanır. Hepsini iyileştirmek için pratik önerisi, her değişikliğin boyutunu küçültmektir, çünkü küçük değişiklikleri incelemek, pipeline’dan geçirmek ve onlardan kurtulmak daha kolaydır.

Release iletişimi release yönetimi sürecine nasıl oturur?

Altıncı adımdır ve her diğer adım gibi bir sahibi ve bir çıkış ölçütü vardır: notlar kullanıcıların okuduğu yerde yayımlandı ve iç ekiplere haber verildi. Ekipler en sık bunu atlar, çünkü deployment araçları kod canlıya çıktığı anda başarıyı bildirir.

Bu adımı programda tutmanın en ucuz yolu, girdiyi release yayımlandığında değil, değişiklik merge edildiğinde yazmaktır. Pull request zaten başlığı, yazarı, bağlı issue’yu ve bağlamı tutar. Ondan kurulan bir taslak, bir hafta sonra hafızadan yazılmak yerine düzenlenir. Changelog otomasyonunun fikri budur: merge’de bir taslak türet, onay için bir insana beklet, sonra tek kaynaktan her yerde yayımla. Changeloop böyle çalışır: merge edilen pull request’lerden AI ile girdi taslağı hazırlar ve hiçbir şey yayımlanmadan önce onay için bekletir.

Önceden planlamaya değer iki varyasyon var. Destek ve satışın müşterilerden farklı bir nota ihtiyacı vardır, dahili release notları bunun içindir. Bir olay güdümlü release’in normal taslak döngüsüne zamanı yoktur, o yüzden acil durum release notes yazısında anlatıldığı gibi hazırda kısa bir şablon tutun. Release notes şablonu müşteriye dönük sürüm için bir başlangıç şekli verir.

Süreç nasıl hafif tutulur?

Bir makinenin kontrol edebileceği her çıkış ölçütünü otomatikleştirin ve yargı gerektiren işleri insanlara bırakın. Yeşil bir pipeline, panolarda bir deploy işareti ve merge edilen her pull request için bir changelog girdisi taslağı kontrol edilebilir. Bir rollback planının inandırıcı olup olmadığı ya da notların bir müşteriye anlamlı gelip gelmediği ise bir insan ister.

Süreci test etmek için geçen aydan bir release seçin ve ekibin dışındaki birinin sadece yazılı kayıttan neyin yayımlandığını, kimin onayladığını, nasıl doğrulandığını ve kullanıcılara ne zaman haber verildiğini söyleyip söyleyemeyeceğini sorun. Her boşluk bir sonraki iyileştirmenizdir.

FAQ

Release yönetimi ile değişiklik yönetimi arasındaki fark nedir? Release yönetimi bir değişiklik kümesinin build edilmesini, test edilmesini, deploy edilmesini ve duyurulmasını sağlar. ITIL anlamındaki değişiklik yönetimi ise her değişikliğin etrafındaki onay ve risk sürecidir. Sık yayımlayan ekipler onayı kod incelemesine ve otomatik kontrollere katar.

Ne sıklıkla release çıkarmalıyız? Testleriniz ve rollback yolunuz izin verdiği kadar sık; birçok web ekibi için bu günlük ya da daha fazladır. DORA’nın önerisi her değişikliğin boyutunu küçültmektir, çünkü küçük değişiklikleri incelemek ve onlardan kurtulmak daha kolaydır.

Küçük ekiplerin bir release manager’a ihtiyacı var mı? Sorumluluklara ihtiyaçları var, ama unvana şart değil. Rolü mühendisler arasında döndürün, nöbetteki kişiye yazılı bir kontrol listesi verin ve yedi adımın her birinin bir sahibi olduğundan emin olun.

Bir release kontrol listesi neleri içermeli? Doğrulanmış kapsam, yayımlanacak commit’te yeşil pipeline, adlandırılmış rollback yolu, kaydedilmiş onay, deploy sonrası smoke kontrolleri, metriklerin referansla karşılaştırılması, yayımlanmış release notes, bilgilendirilmiş destek ve planlanmış bir gözden geçirme. Tek bir sayfada tutun.

Bu yazıdaki teknik iddialar bağımsız olarak kontrol edilmedi. Yanlış bir şey varsa bize söyle, düzeltelim.

changeloop'ta ilgili sayfalar: Geliştirici dokümantasyonu, Release notu şablonu