Sürekli teslim ile daha hızlı ilerleme
Mark Mansour
Sürekli teslim ile daha hızlı ilerleme
Sürekli gelişim ve yazılım otomasyonu
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.
Pipelines: Sürekli dağıtım aracımız
Az sayıda ekip için yazılım teslim sürecini otomatikleştirmek üzere bir pilot program başlattık.
Biz bunu gerçekleştirinceye kadar başlıca pilot ekibi giriş işleminden üretime kadar geçen sürede yüzde 90 oranında bir azalma elde etmişti.
Proje, ekiplerimizin yazılımı müşteriler için piyasaya sürmek amacıyla gerekli tüm adımları tanımlamaları için bir işlem hattı konseptini doğruladı. Bir işlem hattında ilk adım bir yapıt inşa etmektir. Bunun ardından işlem hattı, bu yapıtı tüm müşterilere ulaştırıncaya kadar bir dizi adım yoluyla bu derleme yapıtı çalıştırır. Yeni bir kod değişikliğinin müşterilerimizi olumsuz yönde etkileme riskini azaltmak için işlem hatlarını kullanıyoruz. İşlem hattındaki her bir adım, derleme yapıtın kusur içermediğine dair güvenimizi arttırmalıdır. Bir kusur üretime ulaşırsa üretimi mümkün olan en kısa sürede sağlıklı bir duruma getirmek istiyoruz.
Pipelines'i başlattığımızda her uygulama başına yalnızca tek bir sürüm süreci modelleyebiliyordu.
Bu sınırlama, bir ekibin sürüm süreçlerinin tutarlılığını, standartlaştırılmasını ve basitleştirilmesini sağlamıştır. Bu, daha az kusurla sonuçlandı. İşlem hatlarını kullanmaya başlamadan önce ekiplerin hata düzeltmeleri ve ana özellik sürümleri için farklı sürüm süreçlerine sahip olmaları
yaygın bir durumdu. Diğer ekipler otomatik teslimi yönlendiren ekiplerin başarısını gördükçe elle yönetilen sürüm süreçlerini bu süreçlerin tutarlılıklarını artırabilmeleri için işlem hatlarına taşımaya başladılar. Bir zamanlar çeşitli sürüm süreçlerine sahip olan ekipler artık herkesin kullandığı standartlaştırılmış bir sürece sahip oldular. Ayrıca, sürüm süreçlerini bir araca taşıdıklarında ekip üyeleri yaklaşımlarını sıklıkla gözden geçirdiler ve süreçlerini basitleştirmenin yollarını buldular.
Pipelines ekibinin “çekici benimseme” kullanarak kullanımı artırmak için yıllık hedefleri vardı.
Başka bir deyişle, ürünü o kadar iyi hale getirmeleri gerekiyordu ki böylece insanlar onu kullanmak isteyeceklerdi. Yazılımlarını üretime dağıtmak için bir işlem hattı kullanan ekip sayısını ölçtük ve işlem hatlarını otomasyon seviyelerine göre sınıflandırdık. Yazılımları piyasaya sürmek ve tam otomatik sürümlere doğru ilerlemek için bir işlem hattı kullanmayı hedefleyen ekipler gördük. Ancak, bazı kuruluşlarda kaliteyi ölçme şeklimizin ekiplerin herhangi bir test yapmadan sürüm sürecini otomatikleştirmelerine yol açabileceğini fark ettik.
“Ne kadar test yeterlidir?” sorusunun cevabı kanaate dayalı bir karardır. Bu, ekibin, içinde işlem yaptığı bağlamı anlamalarını gerektirir. Bu durumla başa çıkmak için başka bir liderlik prensibi olan Sahip Olmayı kullandık. Bu ilke, uzun vadeli düşünmek ve kısa vadeli sonuçlar için uzun vadeli değeri feda etmemekle ilgilidir. Amazon'daki yazılım ekiplerinin test çıtaları yüksektir ve çok fazla çaba harcarlar. Çünkü, bir ürüne sahip olmak aynı zamanda o üründeki herhangi bir kusurun sonucuna da sahip olmak anlamına gelir. Bir sorunun müşteriler üzerinde bir etkisi olması durumunda bu sorunu çözen ve gerçek zamanlı olarak düzelten küçük, tek iş parçacıklı yazılım ekibidir. Artan yürütme hızı ve üretimdeki sorunlara cevap vermek arasındaki gerilim ekiplerin test etmek için yeterince motive edilmeleri anlamına gelir. Ancak, teste fazla yatırım yaparsak başarılı olamayız çünkü diğerleri bizden daha hızlı hareket etmektedir. Şirkete engel teşkil etmeden yazılım sürüm süreçlerimizi sürekli olarak iyileştirmeye çalışıyoruz.
Karşılaştığımız bir diğer sorun, ekiplerin en iyi uygulamaları sağlayan yazılımları birbirlerinden öğrenmemeleriydi. Tek iş parçacıklı ekipler otonom bir şekilde çalışmaya teşvik edilmektedir ve bu da mühendislerin dağıtım sorunlarını bağımsız olarak çözmeleri anlamına geliyordu. Onlar yazılım sürüm ihtiyaçlarını karşılayan bir çözüm bulduklarında bu tekniği diğer mühendislere posta listeleri, operasyon toplantıları ve diğer iletişim kanalları yoluyla tanıtırlar. Bu iletişim tarzı ile ilgili iki sorun vardı. Birincisi, bu kanallar en iyi çaba iletişim kanallarıdır, yani herkes yeni teknikleri öğrenememekteydi. İkincisi, ekiplerini en iyi uygulamayı benimsemeleri için cesaretlendiren liderlerin ekiplerinin en iyi uygulamayı benimsemek için gerekli çabayı gerçekten gösterip göstermediklerini anlamalarının hiçbir yolu yoktu. Tüm mühendislerin öğrendiğimiz en iyi uygulamalara ulaşmalarına yardımcı olmaya ihtiyacımız olduğunu fark ettik ve liderlere dikkat etmesi gereken işlem hatları belirleme becerisi kazandırdık.
Çözümümüz, yazılımı oluşturmak ve piyasaya sürmek için kullandığımız araçlara en iyi uygulamaların denetimlerini ekleyerek öğrenmemizi mekanikleştirmekti. Bir kuruluş için en iyi uygulamanın başka bir kuruluş için iyi bir uygulama olamayacağına karşı duyarlı olduk. Bu yüzden bu denetimlerin her bir kuruluş bazında yapılandırılmasına izin verdik. Kuruluş düzeyinde en iyi uygulama denetimleri, liderlere işlerinin ihtiyaçlarını karşılamaları için kendi sürüm süreçlerini uyarlama olanağı verdi. Yeni bir en iyi uygulamayı teşvik etmek veya uygulamak isteyen liderler mühendislerin günlük olarak kullandıkları araçların içinden bir uyarı vererek başlayabiliyorlardı. Bu, mesajları araçlara yerleştirerek ekip üyelerinin en iyi uygulamayı
ve bu en iyi uygulamanın ne zaman etkili olacağını öğreneceklerini neredeyse garanti ediyordu.
Ekiplere yeni bir en iyi uygulama hakkında bilgi edinmek ve tartışmak için zaman vermek suretiyle bir kuruluşun en iyi uygulama kontrollerini yineleme ve geliştirme şansı bulduğunu gördük. Sonuçta bu, en iyi uygulamaların kalitesinin iyileştirilmesine ve mühendislik camiasından daha iyi satın alınmasına yol açtı.
Uygulanacak en iyi uygulamaları sistematik olarak belirledik. En üst düzey mühendislerimizden bir grup, çalışmayan bir sürümün ortak nedenlerini katalogladı. Sürümün çalışmasını sağlayacak adımları belirlediler. Daha sonra en iyi uygulama denetimlerimizi oluşturmak için bu listeyi kullandık. Bu süreçte yeni yazılım revizyonlarının müşterilere anında, ciddi çaba sarf etmeden ve erişilebilirliği düşürmeden anında ulaştırmak istememize rağmen sırasıyla erişilebilirliğe ardından hıza öncelik verdiğimizi ve sonra onu mühendislerimiz için daha kolay hale getirdiğimizi fark ettik.
Bir kusurun müşterilere ulaşma riskini azaltma
Tüm mühendislerin bir noktada sistemlerimizden birine ait bir kusur bulması bekleniyor. İş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 arttı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 sürümünün 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ı.
Uygulamamızın hızına yaklaşımımız
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.
