Devops, yazılım geliştirmedeki en acımasız terimlerden biri olabilir, ancak çoğumuz beş etkinliğin ne olduğu konusunda hemfikiriz: sürekli entegrasyon, sürekli teslimat, bulut altyapısı, test otomasyonu ve konfigürasyon yönetimi. Bu beş şeyi yaparsanız, devops yaparsınız. Açıkçası, beşinin tümü de doğru yapmak için önemlidir, ancak yanlış yapmak çok kolaydır. Özellikle, sürekli entegrasyon ve sürekli teslimat (CI / CD), ustalaşmak için en zor adımlar olabilir.
Sürekli entegrasyon (CI), geliştiricilerin ve test uzmanlarının yeni kodu işbirliği içinde doğruladığı bir süreçtir. Geleneksel olarak, geliştiriciler kod yazdı ve test için ayda bir entegre etti. Bu verimsizdi - dört hafta önceki bir kod hatası, geliştiricileri bir hafta önce yazılan kodu revize etmeye zorlayabilirdi. Bu sorunun üstesinden gelmek için CI, kodu sürekli olarak entegre etmek ve test etmek için otomasyona bağlıdır. CI kullanan Scrum takımları en azından günlük olarak kod taahhüt ederken, çoğunluğu yapılan her değişiklik için kod taahhüt eder.
Sürekli teslim (CD), sürekli olarak yayınlanabilir yapılar oluşturma sürecidir. Bazı şirketler kullanıcılara günde bir veya birkaç kez yayınlarken, diğerleri yazılımı pazar nedenleriyle daha yavaş bir hızda yayınlar. Her iki durumda da, serbest bırakma yeteneği sürekli olarak test edilir. Bulut ortamları sayesinde sürekli dağıtım mümkündür. Sunucular, sunucuları kapatmadan ve manuel olarak güncellemeden üretime dağıtabileceğiniz şekilde ayarlanmıştır.
Dolayısıyla, CI / CD, yeni kodun sürekli geliştirilmesi, test edilmesi ve teslimi için bir süreçtir. Facebook ve Netflix gibi bazı şirketler, haftada 10 veya daha fazla yayını tamamlamak için CI / CD kullanır. Diğer şirketler bu hıza ulaşmakta zorlanıyor çünkü daha sonra tartışacağım beş tuzaktan birine veya daha fazlasına yenik düşüyorlar.
CI / CD tuzağı # 1: Önce yanlış işlemleri otomatikleştirmek
Bu tuzak, şelale gelişiminden devoplara geçiş yapan kuruluşları vurma eğilimindedir. Yeni kuruluşlar, CI / CD'yi sıfırdan uygulama avantajına sahiptir. Mevcut şirketler, manuel geliştirmeden yüksek düzeyde otomatik geliştirmeye kademeli olarak gitmek zorundadır. Tam geçiş birkaç ay sürebilir, bu da CI / CD'yi nasıl benimsediğiniz konusunda yinelemeli olmanız gerektiği anlamına gelir.
"Bunun şimdi otomatikleştirilmesi gerekiyor mu?" Diye sorduğunuzda aşağıdaki kontrol listesini uygulayın:
- Süreç veya senaryo ne sıklıkla tekrarlanıyor?
- Süreç ne kadar sürüyor?
- Süreçte hangi kişiler ve kaynak bağımlılıkları yer alıyor? CI / CD'de gecikmelere neden oluyorlar mı?
- İşlem otomatik değilse hataya açık mı?
- Süreci otomatik hale getirmenin aciliyeti nedir?
Bu kontrol listesini kullanarak bir CI / CD uygulamasındaki adımlara öncelik verebilirsiniz. Her şeyden önce, kodu derleme sürecini otomatikleştirin. İdeal olarak, kodu günde birkaç kez entegre edersiniz (1). Manuel olarak, işlem birkaç dakika ila birkaç saat sürer (2). Bu, derleyici görevi tamamlayana kadar çıktıyı durdurur (3). Aynı zamanda insan hatasına da duyarlıdır (4) ve CI / CD, otomatik entegrasyon olmadan boş bir rüya olduğu için bu acildir (5).
Aynı kontrol listesini testlerde de çalıştırabiliriz. CI / CD'ye geçerken merak ediyor olabilirsiniz: Önce fonksiyonel testi veya UI testini otomatikleştirmeli miyiz? Her ikisi de günde en az bir kez tekrarlanacaktır (1). Orta ölçekli bir uygulama için her ikisi de iki ila üç saat sürebilir (2). Ancak çoklu bağımlılıkları içerirler (3). İşlevsel testi otomatikleştirirseniz, otomasyon komut dosyasını bu kadar sık güncellemeniz gerekmeyebilir. Öte yandan, kullanıcı arayüzü sıklıkla değişir ve bu nedenle sık sık komut dosyası değişiklikleri gerektirir. Her ikisi de hataya açık olsa da (4), kaynaklarınızdan en iyi şekilde yararlanmak için kullanıcı arayüzü testinden önce işlevsel testlere öncelik vermelisiniz (5).
Bunu ortam kurma süreciyle bir kez daha yapalım. Bu senaryo yalnızca bir işe alma çılgınlığındaysanız veya yoğun bir kayıp yaşıyorsanız sıklıkla tekrarlanır (1). Günler olmasa da birkaç saat sürebilen oldukça zaman alıcı bir süreçtir (2). Yeni ekip üyeleri ortamlar olmadan yararlı hiçbir şey yapamazlar, bu nedenle açıkça bir bağımlılık ve gecikme vardır (3). Sürecin hataya açık olduğunu söylemem (4), bu yüzden hala acil mi (5)? Evet'e eğilimliyim, ancak yine de önce entegrasyon ve fonksiyonel testlere öncelik veriyorum.
Aşırı otomatikleştirme diye bir şey yoktur. Sınırsız kaynağınız olsaydı, mümkün olan her şeyi otomatikleştirirdiniz. Bununla birlikte, tam test otomasyonu elde edemezsiniz . Bazen görevleri daha küçük bölümlere ayırabilir ve yamalar halinde otomatikleştirebilirsiniz. Bazen süreci ayrıntılı olarak belgelemeli ve manuel olarak yürütmelisiniz.
CI / CD tuzağı # 2: Sürekli dağıtım için kafa karıştırıcı sürekli dağıtım
Sürekli dağıtım, kod tabanında yapılan her değişikliğin, boru hattının sonuçları başarılı olursa neredeyse hemen üretime dağıtılacağı kavramıdır. Bu, çoğu kuruluş için ürkütücüdür çünkü hızlı ürün değişiklikleri kullanıcıları korkutabilir.
Şirketler, sürekli dağıtım uygulamazlarsa CD yapmadıklarına inanırlar. Sürekli dağıtım ile sürekli teslim arasında ayrım yapamazlar.
Sürekli teslimat, kod tabanındaki her değişikliğin üretim dışı ortamlara dağıtım noktasına kadar boru hattından geçtiği kavramdır. Ekip sorunları hemen bulur ve çözer, daha sonra kod tabanını yayınlamayı planladıklarında değil.
Kod tabanı her zaman sürüm için güvenli olan bir kalite düzeyindedir. Kod tabanının üretime ne zaman bırakılacağı bir iş kararıdır.
Sürekli dağıtım çoğu kuruluşu rahatsız ederken, sürekli teslimat onlarla yankılanır. Sürekli teslimat, onlara ürün sunumu, işlevsellik ve risk faktörleri üzerinde kontrol sağlar. Alfa testi, beta müşterileri, erken benimseyenler vb. İçin zaman vardır.
CI / CD tuzağı # 3: Anlamlı gösterge tablolarının ve ölçümlerin eksikliği
CI / CD uygulamalarında, scrum ekibi, üyelerin neyi izlemeleri gerektiğini bilmeden önce bir gösterge panosu oluşturabilir. Sonuç olarak, ekip mantıksal bir yanılgıya kapılır: "Bunlar bizim sahip olduğumuz metrikler, bu yüzden önemli olmalılar." Bunun yerine, bir gösterge panosu tasarlamadan önce aşamalı bir değerlendirme yapın .
Bir BT organizasyonunun farklı üyelerinin ve hatta bir scrum ekibinin çeşitli üyelerinin farklı öncelikleri vardır. Örneğin, bir ağ operasyon merkezindeki (NOC) insanlar kırmızı, sarı ve yeşil göstergeleri sever. Bu tür trafik ışığı panoları, NOC personelinin, yoğun metinleri okumadan veya analitik yeteneklerini yitirmeden sorunları ayırt etmesini sağlar. Trafik ışıkları, yüzlerce sunucunun yönetilebilir olmasına yardımcı olur.
CI / CD için de bir trafik ışığı panosu kullanmak isteyebilirsiniz. Yeşil, yolumuzdayız. Yellow, yoldan çıktık, ancak bunu çözmek için bir planımız var. Red, yoldan çıktık ve muhtemelen hedeflerimizi değiştirmemiz gerekiyor.
Bu gösterge panosu muhtemelen bir scrum ustası için yararlıdır, peki ya geliştirme başkan yardımcısı veya CTO? Bir scrum takımının iki haftalık bir sprint için önceden 350 saat çalışması varsa ve 10 üyesi her biri 35 saat sorumluysa, buna karşılık gelen sayıda hikaye puanı alırlar. Üst yönetim, hikaye noktalarının durumuyla daha az ilgilenebilir ve "tükenme" oranını daha çok merak edebilir: görev tamamlama hızı. Ekip üyeleri yüklerini taşıyor mu? Ne kadar hızlı? Zamanla gelişiyorlar mı?
Ne yazık ki, çeşitli paydaşlar scrum ekibinin üzerinde mutabık kaldığı alışkanlıklarını anlamazsa, tükenme oranları yanıltıcı olabilir. Bazı takımlar puanları gittikçe erken yakarlar. Diğerleri açık noktaları yakmak için sprint sonuna yakın beklerler. Kontrol paneli bunu hesaba katmalıdır.
Herkesin hangi verileri istediğini değerlendirebilir ve bu verilerin ne anlama geldiğine dair standart bir açıklama oluşturabilirseniz, o zaman kullanışlı bir gösterge tablosu tasarlayabilirsiniz. Ama görünüş pahasına özü saplantı haline getirmeyin. Paydaşların nasıl görünmesini istediklerini sorun. Grafikler, metin veya sayılar en iyisi mi?
Bunlar, aşamalı bir değerlendirmede araştırılması gereken hususlardır. Kullanışlı bir CI / CD panosu yapmanın ve herkesi mutlu etmenin ne kadar zor olduğunu gösteriyorlar. Çoğu zaman, en sesli ekip üyesi süreci ele geçirir ve diğerleri panonun yalnızca bir kişinin tercihlerini karşılaması nedeniyle hayal kırıklığına uğrar. Herkesi dinleyin.
CI / CD tuzağı # 4: Sürekli entegrasyon ve sürekli teslimat arasında koordinasyon eksikliği
Bu tuzak bizi, sürekli entegrasyon ve sürekli teslimatın iki farklı öğe olduğunu tutan mutabakat tanımımıza geri götürüyor. CI CD'yi besler . Düzgün bir sürekli entegrasyon hattı ve tam bir sürekli teslimat sistemi uygulamak aylar sürer ve işbirliği gerektirir. Kalite güvencesi, devops ekibi, operasyon mühendisleri, scrum ustaları - hepsi katkıda bulunmalıdır. Belki de CI / CD'nin en zor yanı, tartıştığımız herhangi bir teknik zorluktan ziyade bu insan faktörüdür. İki kişi arasında sağlıklı bir ilişki programlayamadığınız gibi, işbirliğini ve iletişimi de otomatikleştiremezsiniz.
Bu koordinasyon düzeyini ölçmek için, CI / CD sürecinizi sektördeki en iyilerle kıyaslayın. Netflix gibi şirketler entegrasyonu, testi ve teslimatı iki ila üç saat içinde tamamlayabilir. Kararsız ve tartışmadan elden ele şifre geçiren bir sistem kurdular. Hayır, yüzde 100 otomatik değil çünkü mevcut teknolojiyle bu imkansız.
CI / CD tuzağı # 5: Sürekli entegrasyon işleri ve kaynak kullanımı çalıştırma sıklığını dengelemek
Kodda tanıtılan her değişiklik için sürekli tümleştirme işlerinin tetiklenmesi beklenir. Başarılı işler değişikliklerin uygulanmasına izin verirken, başarısızlıklar değişiklikleri reddeder. Bu, geliştiricileri daha küçük kod parçalarını kontrol etmeye teşvik ederek bir günde daha fazla derlemeyi tetikler. Ancak, gereksiz sürekli entegrasyon işleri kaynakları tüketir ve bu da zaman ve para israfına neden olur.
Bu süreç çok fazla kaynak kullanımı (CPU, güç, zaman) içerdiğinden, yazılım daha hızlı çalışan ardışık düzenler oluşturmak için daha küçük bileşenlere bölünmelidir. Veya sürekli entegrasyon işleri, ilk olarak yerel olarak test edilen check-in'leri toplu hale getirmek için tasarlanmalıdır. Amaç, sürekli entegrasyon işlerini yürütme sıklığı ile kaynakların kullanımı arasında bir denge bulmaktır.
Hedefi görünürde tutun
CI / CD'nin - tüm ezoterik terminolojisiyle tamamlanan - tuzaklarını araştırırken, bunun neden önemli olduğunu gözden kaçırmak kolaydır . Nihayetinde, CI / CD, iş hedeflerini karşıladığı için önemlidir.
Teknoloji yöneticileri, sürekli gelişimin, hızlı düzeltmelerin ve kaliteli sonuçların müşterileri yarattığını ve elde tuttuğunu bilir. Başarısız bir sürümün bir canavarı App Store incelemelerine davet ettiğini ve yüksek incelemeleri geri almanın onları saklamaktan daha zor olduğunu biliyorlar. Devops, ekibiniz için daha iyi bir iş deneyimi oluşturabilir, ancak şirketlerin devops uygulamasının nedeni bu değildir.
Basitçe söylemek gerekirse, CI / CD'nin tuzakları gözden geçirilmeye değer çünkü milyarlarca dolar tehlikede. CI / CD panonuza bir hisse senedi şeridi veya App Store inceleme izleyicisi eklemenizi önermesem de, bunun farkında olmanızı tavsiye ediyorum. Bir çok şey, CI / CD'nin ayrıntılarına bağlıdır.
Zubin Irani, 50'den fazla Fortune 100 firması ve Silikon Vadisi'nin en büyük işverenlerinin birçoğu için çevik dönüşümler uygulayan ve çevik çözümler sunan bir tam hizmet danışmanlığı olan cPrime'ın kurucu ortağı ve CEO'sudur.
Yeni Teknoloji Forumu, ortaya çıkan kurumsal teknolojiyi benzeri görülmemiş bir derinlik ve genişlikte keşfetmek ve tartışmak için bir mekan sağlar. Seçim özneldir, önemli olduğuna inandığımız ve okuyucuların en çok ilgisini çeken teknolojileri seçmemize dayanır. yayın için pazarlama materyallerini kabul etmez ve katkıda bulunan tüm içeriği düzenleme hakkını saklı tutar. Tüm sorularınızı [email protected] adresine gönderin.