Elle yapılan dağıtımlar. Önlenebilir riskler.

Tipik bir akış, çalışmanın nerede beklediğini ve hangi adımları yalnızca belirli kişilerin gerçekleştirebildiğini gösterir. Değişikliği, derlemeyi, testleri, devirleri ve üretim onayını birlikte inceleriz. Burada amaç, her manuel işlemi istisnasız ortadan kaldırmak değildir. Öncelikle bu işlemin hangi amaca hizmet ettiği ve bir karar için hangi bilgilerin gerektiği net olmalıdır. Bazı gecikmeler eksik erişimlerden, bazıları ise belirsiz sorumluluktan veya farklı yapılandırmalardan kaynaklanır. Bu nedenlerin her biri farklı bir çözüm gerektirir.

Analizden net şekilde sınırlandırılmış bir ilk görev geliştirilir. Bu görev, sürecin hangi bölümünün iyileştirileceğini, hangi paydaşların katkıda bulunacağını ve sonucun neye bakılarak anlaşılacağını tanımlar. İşleyen yöntemler ve mevcut araçlar dikkate alınır. Böylece değişiklik ekibiniz için yönetilebilir kalır ve gerçek bir sürüm yayınlama süreci üzerinden değerlendirilebilir. Elde edilen bulgular, en başından itibaren tüm geliştirme ve işletim süreçlerini aynı anda dönüştürmeden, daha sonra başka uygulamalar için de kullanılabilir.

Test ve üretim ortamları farklı şekilde kurulduğunda, başarılı testler kanıt değerinin bir kısmını yitirir. Bu nedenle kararlaştırılan kapsamda altyapı, izlenebilir ve sürümlenmiş bir yapılandırma olarak tanımlanır. Değişiklikler kontrol edilebilir ve öngörülen ortama atanabilir. Buna, adımları belgelenmiş bir dağıtım süreci de eklenir. Amaç her ortamı birbirinin aynısı yapmak değildir: İstenen farklılıklar görünür kalırken, istenmeyen sapmalar daha kolay fark edilip görüşülebilir.

Derleme sonuçları, testler ve onaylar ilgili değişiklikle ilişkilendirilir. Kimlik bilgileri ayrı bir yönetim gerektirir ve üretime yönelik değişiklikler üzerinde mutabık kalınan kararlara göre yapılır. Hangi kontrollerin otomatik olarak yapılacağı ve hangi noktalarda hâlâ sorumlu bir kişinin değerlendirmesinin gerekli olduğu birlikte belirlenir. Eksiksiz bir deneme, paydaşların süreci kullanabildiğini ve sonuçları anlayabildiğini gösterir. Teknik pipeline ancak bununla, geliştirme ve işletimin günlük çalışmada birlikte üzerine inşa edebileceği bir yönteme dönüşür.

Bir sürüm yayınlama yöntemi, bir adım başarısız olduğunda dahi yol gösterebilmelidir. Hatayı kim değerlendirir, hangi bilgiler hazır bulunur ve işlem ne zaman yeniden çalıştırılabilir? Geri dönüş yolları önceden görüşülür; bu sırada veri değişiklikleri veya harici bağımlılıklar özel dikkat gerektirebilir. Uygulama sürümünün geri alınması, üretime yönelik bir değişikliğin her sonucunu otomatik olarak çözmez. Bu nedenle kararlaştırılmış hata senaryoları somut süreç üzerinden ele alınır ve öngörüldüğü ölçüde birlikte test edilir.

Devirden sonra otomasyonun da sorumluları olmalıdır. Araçlar, uygulama ve altyapı değişir; kontrollerin ve yapılandırmanın da buna uygun şekilde güncel tutulması gerekir. Bu nedenle ekibiniz, kararlaştırılan sürece ilişkin dokümantasyon ve pratik bir bilgilendirme alır. Açık kısıtlamalar, başarılı bir gösterimin ardına gizlenmek yerine açıkça belirtilir. Böylece çözüm, proje sona erdikten sonra da geliştirilebilir ve yalnızca onu başlangıçta kuran kişilerin bilgisine bağlı kalmaz.