Cuma günleri deployment yapıp yapmamanız konusunda epeydir devam eden bir tartışma var gibi görünüyor.
Cuma günü büyük bir ürün güncellemesi yapmamanın arkasındaki mantığın sebebi, teknik olabileceği gibi taktik de olabilir.
Büyük bir launch sürecinde tüm ekiplerin uygun bir iletişim stratejisi olduğundan emin olması gerekir, herkes müşterilerden gelen soruları yanıtlamaya hazır olmalıdır. Bu süreçte genelde çoğu ekip ürün sorunlarını hafta sonu çözmekten hoşlanmaz.
Geliştiriciler ve operasyon ekipleri, bir şeyler ters giderse ve hafta sonlarını acil durum düzeltmeleri yapmak zorunda kalmaları durumunda Cuma günü değişiklik yapmak veya uygulamaları dağıtmak konusunda geleneksel olarak tereddütlüdür.
Hatta bazı şirketlerin işe alım süreçlerinde Cuma günleri deployment yapmadıkları politikadan bahsederken sektörde çoğu kişinin tereddütlü olması kaçınılmaz sonuçlar arasında ????
Güçlü bir CI/CD süreci ile herhangi bir zamanda, deployment yapmamak için bir neden olmamalıdır.
Cuma günleri deployment yapmak için tam olarak güveniniz yoksa, bu konuda test ve Q&A prosedürlerinizi düzeltmeniz daha sağlıklı ilerlemenizi sağlayabilir.
Tasklar ne zaman tamamlanmalı?
Cuma günlerinin tehlikesiyle nasıl mücadele edileceğini anlamak için yazılımın yaşam döngüsünde “X özelliğini implement etmem gerekiyor” ile “Production sürecinde kullanmalıyım” arasındaki döngünün detayına inmek gerekebilir.
Yazılımcı bakış açısından, X özelliğinin ne zaman tamamlandığını söylersiniz? Brachleri merge ettikten sonra mı? Kodu deploy ettikten sonra mı? Cevap, ekibinizin sorumluluk algısı ve bakış açısına bağlıdır.
Full Cycle Development yapan ekiplerde, kodu yazan kişi aynı zamanda test eden, çalıştıran ve deploy eden kişidir. Bu, özellik yalnızca production sürecinde kullanıldığında bitti olarak işaretlenebileceği anlamına gelir.
Deploy, yalnızca bir adımdır, ardından değişikliği kullanıcılarınızın bazıları veya hepsi ile paylaşarak ve bunu istediğiniz gibi çalışıp çalışmadığını gözlemlersiniz. Deploy sürecini yazılım yaşam döngüsünün başka bir aşaması olarak ele almak, gözlenebilirlik odaklı geliştirme sağlar.
Feedback looplarını optimize etme
Yukarıda gösterilen yazılım yaşam döngüsü şeması, gerçekte düz bir çizgi değildir. Her adım sizi bir önceki adıma geri döndürebilir.
Verimli bir ekibin sırrı, bu geri bildirim döngülerini mümkün olduğunca kısa tutmaktır. Testlerinizin çalışması 30 dakika sürerse, sorunu fark ettiğinizde, zaten bir sonraki task’ınız için çalışmaya başlamışsınız demektir.
Bu nedenle, süreçle ilgili önemli gördüğünüz şeyleri dökümante etmelisiniz.
Deployment süreçleri nasıl iyileştirilir?
Daha az korkutucu deployment sürecine sahip olmak için yapabileceğiniz en önemli değişiklik, küçük değişiklikleri deploy etmektir.
One Pull Request ➡️ one Deploy
Küçük değişiklikleri deploy etmek, kodunuzun hizmeti nasıl etkilediği konusunda size daha iyi bir görünürlük sağlar. Geliştiriciler, her seferinde bir değişiklik yayınlayarak kodun üretimde nasıl davrandığını gözlemlemek ve hataları kullanıcılarınızdan önce tespit etmek için telemetri kullanabilir.
Aynı zamanda daha küçük değişiklikler, daha kısa code review anlamına gelir. Bu, daha küçük değişikliklerin daha iyi kod kalitesi getirmesinin başka bir yoludur.
Deploying != Releasing
Deploy ve release arasındaki temel fark, iş mantığıdır. Deploy etmek, ilgili farklı ortamlarda açıkça görülebileceği gibi, kullanıcıların özelliklere erişimi olduğu anlamına gelmez.
Daha önce belirtildiği gibi, bu daha fazla deployment anlamına gelebilir fakat genellikle devasa sürüm yaklaşımından daha güvenlidir.
Bu durum, tüm kullanıcıların siz deploy eder etmez yeni değişiklikleri hemen görebileceği anlamına gelmez.
Deploy ve release terimleri bazen birbirinin yerine kullanılır, bu yüzden tekrar tanımlamalarını yapmak gerekebilir.
Deploy’u kodun yeni bir sürümünü production sürecine getirmek olarak tanımlarken, release’i ise bazı işlevleri kullanıcılar için kullanılabilir hale getirmek olarak tanımlayabiliriz.
Yeni işlevlerin kullanıcılara hangi oranda sunulacağını kontrol edebilirsiniz. Yalnızca ileri düzey kullanıcıların bir alt kümesinin üzerinde çalıştığınız şeyi görebildiği ve özellik daha geniş bir kitleye sunulmadan önce geri bildirim sağladığı bir kullanıma sunma stratejisi kullanmak faydalı olabilir.
Bu durum, kritik bir hata bulunması durumunda, kodu basit bir yapılandırma değişikliğiyle (deploy gerektirmeden) etkinleştirip devre dışı bırakabilmenin ekstra avantajını sağlar.
Bu konuda daha detaylı bilgi için Candost Dağdeviren’in “Why should you deploy your code in smaller chunks and release software often?” yazısına göz atabilirsiniz.
Test etmekle ilgili mi?
Kaç testiniz olursa olsun, kapsamınız ne kadar iyi olursa olsun, bir hata yapmadığınızdan emin olamazsınız.
Çoğu otomatik test, geliştirme sırasında geliştiricinin bulabileceği senaryoları doğrulamakla ilgilidir. Tahmin edemeyeceğimiz şeyleri hesaba katmazlar. Bu nedenle çoğu test, testi yazan kişinin hayal gücü ile sınırlıdır.
Bu konuyla ilgili, Edsger W. Dijkstra bir cümlesinde, program testinin hataların varlığını göstermek için kullanabileceğini, fakat eksikleri asla göstermediğinden bahsediyor.
Netflix, Cuma günleri deployment için temkinli davranıyor ????
Teknoloji devi Netflix’in bu konuda belirlediği kültürel bir normu var.
Bu durum Netflix yeterince test yapmadığı için mi? Ya da izlemeleri hafta sonu çalışacak kadar iyi değil mi? Her günün her saati diğer günlerle tamamen aynıysa, bunun bir anlamı olmaz.
Özetlemek gerekirse; deploy etmek, yazılım yaşam döngüsünün yalnızca ek bir adımıdır. Kodunuzun production sürecinde nasıl davrandığını gözlemlemeye istekli olmanız koşuluyla, haftanın herhangi bir günü deploy edebilirsiniz.
Gelecekte değişikliklerimizi otomatik olarak gözlemlemek için DevOps AI’ya sahip olabiliriz. O zamana kadar, kodunuzun istendiği gibi çalıştığından emin olmak için Cuma günleri deployment için dikkatli olmalısınız.
