Sürekli teslim ile daha hızlı ilerleme

10 yıldan fazla bir süre önce Amazon'da ekiplerimizin fikirleri yüksek kaliteli üretim sistemlerine ne kadar çabuk dönüştürdüklerini anlamak için bir proje yürüttük. Bu, bizim yazılım aktarım hızımızı ölçmemizi sağladı. Böylece uygulama hızımızı artırabildik. Bunun, kod girişi işleminden üretime kadar ortalama 16 gün sürdüğünü keşfettik. Amazon'da ekipler bir fikirle başladı ve daha sonra fikri hayata geçirmek için kod yazma işi genellikle bir buçuk gün sürdü. Yeni kodu oluşturmak ve dağıtmak için bir saatten az zaman harcadık. Zamanın geri kalanında yani neredeyse 14 gün boyunca ekip üyelerinin bir derleme başlatması, dağıtımları gerçekleştirmesi ve testler yapması için bekledik. Proje sonunda uygulama hızımızı arttırmak için giriş işlemi sonrası süreçlerimizi otomatikleştirmenizi getirmenizi tavsiye ediyoruz. Burada amaç kaliteyi korurken ve hatta geliştirirken gecikmeleri ortadan kaldırmaktı.

Bu önerinin temelinde yürütme hızımızı arttırmak için sürekli bir iyileştirme programı vardı. Yürütme hızımızı arttırma kararımızı En Yüksek Standartlarda Israr şeklindeki liderlik ilkesine dayandırdık. Bu ilke, inatla yüksek standartlara sahip olmak, sürekli çıtayı yükseltmek ve yüksek kaliteli ürünler, hizmetler ve süreçler sunmakla ilgilidir. Liderlik İlkelerimiz Amazon'un nasıl iş yaptığını, liderlerin nasıl liderlik ettiğini ve müşteriyi kararlarımızın merkezinde nasıl tuttuğumuzu açıklamaktadır.

Amazon, yazılım mühendislerimizi daha üretken hale getirmek için daha önceden yazılım geliştirme araçları tesis etmişti. Dağıtılabilecek bir yapıt üretmek amacıyla bir sunucu üzerinde bir dizi komut yürüten, kendimize ait merkezi ve barındırılan derleme sistemimiz olan Brezilya'yı yarattık. Bu noktada Brezilya kaynak kodu değişikliklerini önemsemedi. Bir kişi bir derleme başlatmak zorunda kaldı. Ayrıca bir dağıtımın başlatılmasının parçası olarak kendisine bir derleme yapıtının yüklenmesini gerektiren kendi dağıtım sistemimiz olan Apollo da vardı. Endüstride meydana gelen sürekli teslim ilgisinden esinlenerek Brezilya ile Apollo arasındaki yazılım teslim sürecini otomatikleştirmek için kendi sistemimiz Pipelines'i kurduk.

İşlem hatlarımız ve dağıtım sistemlerimiz de dahil olmak üzere sürüm süreçlerimiz bu kusurları olabildiğince hızlı bir şekilde tanımlamak ve müşterilerimiz üzerinde etkili olmalarını önlemek için tasarlanmalıdır. Sürüm süreçlerimizin doğru yapılandırıldığından ve derleme yapıtın amaçlandığı şekilde çalıştığından emin olmalıyız.

Dağıtım hijyeni: En temel dağıtım testi şekli yeni dağıtılan yapıtın başlatılabilmesini ve işe yanıt verebilmesini sağlar. Dağıtım sonrası iş akışının bir parçası olarak yeni dağıtılan yapıtın başlamasını ve trafiğe hizmet vermesini sağlayan hızlı denetimler gerçekleştiriyoruz. Örneğin, AWS CodeDeploy AppSpec dosyasındaki yaşam döngüsü olay kancalarını dağıtımı durdurmak, başlatmak ve doğrulamak amacıyla basit komut dosyalarını tetiklemesi için kullanıyoruz. Ayrıca müşteri trafiğine hizmet etmek için yeterli kapasiteye sahip olduğumuzu kontrol ediyoruz. Müşterilerimize hizmet sunmak için her zaman yetecek kapasiteye sahip olduğumuzu doğrulamak için CodeDeploy'da minimum sağlıklı ana bilgisayarlar gibi teknikler geliştirdik. Son olarak, dağıtım motoru bir arıza tespit ederse müşterilerin bir kusur gördüğü süreyi en aza indirmek için değişikliği geri alması gerekir.

Üretim öncesi test etme: Amazon’un en iyi uygulamalarından biri birimi, entegrasyonu ve ön üretim testleri otomatikleştirmek ve bu testleri işlem hattımıza eklemektir. Bu testleri işlem hatlarımıza eklemek için ön yargılı olarak yük ve güvenlik testleri yapmakta ısrar ediyoruz. Ünite testleri dediğimizde stil denetimleri, kod kapsamı, kod karmaşıklığı ve daha fazlası dahil olmak üzere yapım makinenizde yapmak isteyebileceğiniz tüm testleri kastediyoruz. Arıza enjeksiyonu, otomatik tarayıcı testi ve benzerleri gibi tüm kapalı kutu testleri de dahil olmak üzere entegrasyon testlerini düşünüyoruz. Birim ve entegrasyon testleriyle ilgili birçok harika makale mevcuttur. Bu yüzden, burada daha fazla ayrıntıya girmeyeceğim.

Ünite ve entegrasyon testlerimiz derleme yapıtımızın davranışının işlevsel olarak doğru olduğunu doğrulamayı amaçlamaktadır. Ne kadar çok doğrulama işlemi yaparsak kusurun müşterilerimize ulaşma riski o kadar düşük olur. Bir ürünün müşterinin eline geçmesi için gereken süreyi azaltmak amacıyla bir kusuru sürüm aşamasında mümkün olduğu kadar erken tespit etmeye çalışırız. Genel olarak bu, testleriniz daha küçük ve daha hızlıysa değişiklikleriniz ile ilgili sorunlarınız için daha hızlı geri bildirim alacağınız anlamına gelir.

Amazon'da ön üretim testi dediğimiz tekniği kullanıyoruz. Ön üretim ortamı, değişikliklerimizi üretime dağıtmadan önce testlerin yapıldığı son yerdir. Bir ön üretim ortam testi sistemin üretim yapılandırmasını kullanır. Dolayısıyla bu, tam anlamıyla bir üretim sistemi gibi işlev görür. Bu yaklaşımın iki avantajı vardır. Birincisi, ön üretim ortamları hizmetin üretim veri depoları dahil olmak üzere tüm üretim kaynaklarına doğru şekilde bağlanabildiğinden emin olmak için üretim yapılandırmasını test eder. İkincisi, sistemin bağlı olduğu üretim hizmetlerinin API'leri ile doğru etkileşime girmesini sağlar. Ön üretim ortamları yalnızca bu hizmete sahip olan ekip tarafından kullanılır ve hiçbir zaman müşterilerden trafik gönderilmez. Ön üretim testlerini yapmak, aynı kodun ve yapılandırmanın üretimde işe yarayacağına olan güvenimizi artırır.

Üretimde doğrulama: Müşterilerimize kod verirken hepsini tek seferde yapmayız. Bir kusurun tüm müşterilere tek seferde verilmesinin etki kapsamı çok büyüktür. Bunun yerine, bir hizmetin tamamen bağımsız bir bulut sunucusu olan hücrelere dağıtım yaparız. İlk hücremizdeki ilk grup müşterilerimize değişiklikleri dağıttığımızda son derece dikkatli davranırız. Yeni değişikliği yalnızca az sayıda müşterinin görmesine izin veriyoruz ve yeni kodun çalışıp çalışmadığı hakkında geri bildirim alıyoruz. Bir kanarya dağıtımından sonra hizmetlerimizin yayınladığı hata miktarını izliyoruz. Hata oranı yükselirse değişikliği otomatik olarak geri alırız. Örneğin, dağıtıma devam etmeden önce negatif veri noktası olmadan 3.000 pozitif veri noktası bekleyebiliriz.

Otomatikleştirilmiş testleriniz bir kullanım örneğini kaçırırsa bir komplikasyon ortaya çıkabilir. Otomatik veya manuel olsun yapılandırılmış ve yinelenebilir testlerimiz ile tüm hataları yakalamak için mücadele ediyoruz. Ancak, elimizden gelenin en iyisini yaptığımızda bile, bir kusur gözden kaçabilir. Testlerimizi denemek için ekip dışı bir üyenin bir sorun bulup bulmadığını görmek amacıyla üretimdeki yeni değişikliği belli bir süre bırakırız. Değişikliklerin yalnızca üretimde olmasına izin vermemizin gerekip gerekmeyeceği veya bir dağıtım grubunun geri kalanına dağıtmadan önce bir kanarya dağıtımından sonra ne kadar beklememiz gerektiğini tartışarak çok zaman harcadık. Ekiplerimizin birçoğu, dağıtım rutinimizde ilerlemeden önce pozitif veri noktaları toplamanın yanı sıra belirli bir süre beklemeye karar vermiştir. İşlem hattının beklediği süre yüksek oranda bir ekibe bağlıdır. Bazı ekipler saatlerce beklerken diğerleri dakikalarca bekler. Etki ne kadar yüksek ve sorunu çözme süresi ne kadar uzun olursa sürüm işlemi o kadar yavaşlar.

İlk hücrede güven kazandıktan sonra tamamen piyasaya çıkana kadar yeni kod değişikliğini gittikçe daha fazla müşteriye göstereceğiz. Kanarya dağıtımında yaptığımız gibi bir sonraki hücreye geçmeden önce ilk yeni hücreye dağıtımda güven kazanmayı bekliyoruz. Derleme yapıtında daha fazla güven kazandıkça kod değişikliğini doğrulamak için harcadığımız zamanı azaltırız. Bu, giriş işleminden ilk üretim müşterimize mümkün olan en kısa sürede ulaşmayı hedeflediğimiz bir model ile sonuçlanır. Ancak, üretimden sonra, yeni kodu yavaş yavaş müşterilere veririz ve dağıtımlarımızın geri kalanını adım adım hızlandırarak ek güven kazanmaya çalışırız.

Üretim sistemlerimizin müşteri isteklerine cevap vermeye devam etmesini sağlamak için sistemlerimizde sentetik trafik oluştururuz. Hizmetimiz doğru çalışmıyorsa hızlı geri bildirim istiyoruz, bu nedenle sentetik testlerimizi en az dakikada bir yaparız. İşlemekte olan süreçlerimizin sağlıklı olduğundan emin olmak ve genellikle tüm halka açık API'lerin test edilmesini içeren tüm bağımlılıkların test edilmesini sağlamak için sentetik testler tasarlıyoruz.

Yazılımın ne zaman piyasaya sürüldüğünü kontrol etme: Yazılım sürümlerimizin güvenliğini kontrol etmek için değişikliklerin işlem hattımızdaki hareket hızını kontrol etmemizi sağlayan mekanizmalar oluşturduk. Yazılımımızın piyasaya sürülmesinin ne zaman yapıldığını kontrol etmek için ölçümleri, zaman aralıklarını ve güvenlik denetimlerini kullanıyoruz.

Ölçümlerdeki bir değişikliğe bağlı olarak alarm verildiğinde dağıtımı önlemek için işlem hatları yapılandırılabilir. Ölçümleri yaygın olarak kullanıyoruz ve sistemlerimizin sağlığı, hücrelerimizin sağlığı, Erişilebilirlik Alanları ve Bölgeleri ve düşünebileceğiniz neredeyse her şey hakkında alarmlarımız mevcuttur. Önemli bir ölçüm bir alarmı tetiklediğinde kod dağıtımını durduracak şekilde işlem hatlarını yapılandırıyoruz. Ancak, bazen bir ekibin sistemin alarmına yönelik sorunların üzerine gitmek için bir düzeltme dağıtması gerekebilir. Bu senaryo için ekiplerin değişikliklerin bir işlem hattından geçmesini önleyen alarmları devre dışı bırakmasına izin veriyoruz.

İşlem hatlarımız içerisinde değişikliklerin bir işlem hattı boyunca ilerlemesine izin verildiği bir zaman aralığı belirleyebilir. Ekipler, müşterilere ulaştığında değişiklikleri kısıtlamak için kendi zaman aralıklarını bulabilirler. AWS ekipleri bir dağıtımın neden olduğu bir sorunu hızla yanıtlayabilen ve azaltabilen çok sayıda insan olduğunda yazılımı piyasaya sürmeyi tercih eder. Bunu gerçeğe dönüştürmek için ekipler genellikle kendi zaman aralıklarını ayarlarlar. Böylece yalnızca çalışma saatlerinde dağıtım yaparlar. Amazon'daki diğer ekipler düşük müşteri trafiği olduğunda yazılımı piyasaya sürmeyi tercih eder. Bu zaman aralıkları gerektiğinde geçersiz kılınabilir.

Ayrıca, derleme yapıtının içeriğine bağlı olarak bir işlem hattını durdurma yeteneğine sahibiz. Örneğin, bilinen bir kötü paketi veya belirli bir Git referansını içeren bir derleme yapıtı engelleyebiliriz. Bu özelliği bir paket değişikliğinin performans regresyonu içerdiğini keşfettiğimizde kullandık. Paketi yalnızca paket depomuzdan çıkarsaydık, o zaman zaten kusurlu paketi içeren işlem hatları hâlâ müşterilere bu kötü değişikliği dağıtırdı.

Ekiplerin otomasyonu benimseme konusunda istekli olduklarını gördük. Müşterilerimize yaşamlarını iyileştiren özellikler oluşturmak ve piyasaya sürmek için son derece motive olduk ve sürekli teslim bunu sürdürülebilir kılıyor. Otomasyonun sinir bozucu, hataya açık ve zahmetli el işlerini kaldırarak mühendislere zaman kazandırdığını gördük. Sürekli dağıtımın kaliteyi olumlu yönde etkilediğini gösterdik. Otomasyonun ekiplerin sürekli piyasaya sürmesini, her seferinde değişiklik yapmasını ve regresyonları tanımlamasını kolaylaştırdığını gördük.

Sistemler yeni olduğunda test edilecek yüzey alanı çoğu ekip üyesi tarafından anlaşılır ve bu da bazı manuel testlerin izlenmesini sağlar. Bununla birlikte, sistemler daha karmaşık hale geldikçe ve ekip üyeleri değiştikçe otomasyonun değeri artmaktadır. Sistemlerimizi otomatikleştirmeyi seviyoruz. Böylece bu değişiklikleri müşteriye verme sürecini elle yönetmek yerine müşteri değeri katmaya odaklanabiliyoruz.

Amazon, yıllarca müşterilere sunduğumuz yazılımların hızı ve bu sürümlerin güvenliği üzerine odaklanmış sürekli gelişim programları yürütmektedir. Bu makalede yazmış olduğum tüm risk kontrollerine ve testlere başlamadık. Zaman içerisinde riski tanımlamanın ve azaltmanın yollarını bulduk.

Sürekli gelişim programları işletme liderleri tarafından kuruluşun farklı seviyelerinde yürütülmektedir. Bu, iş liderlerinin işlerine yönelik riskleri ve etkileri eşleyecek şekilde kendi yazılımlarının sürüm işlemlerini ayarlamalarını sağlar. Sürekli iyileştirme programlarımızdan bazıları Amazon'un büyük bölümlerinde yürütülmekte ve bazen daha küçük kuruluşların liderleri kendi programlarını yürütmektedir. Kurallarda her zaman istisnalar olduğunu biliyoruz. Sistemlerimizde vazgeçme mekanizmaları vardır. Bu yüzden, kalıcı veya geçici muafiyet gerektiren ekipleri yavaşlatmayız. Sonuç olarak, ekiplerimiz kendi yazılım davranışlarına sahipler ve yazılım sürüm sürecine uygun şekilde yatırım yapmaktan sorumludurlar.

Acımızın nerede olduğunu ölçerek, onu ele alarak ve yineleyerek başladık. Bu çalışmayı sürdürülebilir kılmak için onu aşamalı olarak yapmamız ve zaman içindeki gelişmeleri kutlamamız gerekiyordu. Amazon işlem hatlarını ilk defa kullanmaya başladığında birçok ekip sürekli dağıtımın işe yarayacağından emin değildi. Ekipleri başlatmak için onları kendi mevcut sürüm süreçlerini, manuel adımlarını ve hepsini bir işlem hattında kodlamaları için teşvik ettik. Birçok ekip için kendi işlem hatları bir üretim süreci boyunca derleme yapıtlarını otomatik olarak teşvik etmeden sürüm süreci için görsel bir arayüz görevi gördü. Kendilerine güvenleri arttıkça işlem hattının herhangi bir basamağını manuel olarak tetiklemelerine gerek kalmayana kadar işlem hattının farklı aşamalarında otomasyonu kademeli olarak açtılar.

Günümüze doğru hızlı ilerleme. Amazon şu anda ekiplerin yeni kod yazarken tam otomasyonu hedefledikleri noktada. Otomasyon bizim için işimizi büyütmeye devam edebilmemizin tek yoludur.