Şirketiniz DevOps veya CI/CD araçlarını yeni tanıtıyorsa, bunları tekrarlamamak ve başkasının ayağına basmamak için en yaygın hatalara aşina olmanız sizin için yararlı olabilir.
Ekip makaleyi tercüme etti .
Kültürü ve süreçleri değiştirmeye hazırlıksızlık
Döngüsel diyagrama bakarsanız DevOps uygulamalarında testin sürekli bir etkinlik olduğu ve her dağıtımın temel bir parçası olduğu açıktır.
DevOps Sonsuz Döngü Grafiği
Geliştirme ve teslimat sırasında test etme ve kalite güvencesi, geliştiricilerin yaptığı her şeyin önemli bir parçasıdır. Bu, testi her göreve dahil etmek için bir zihniyet değişikliği gerektirir.
Test, her ekip üyesinin günlük çalışmasının bir parçası haline gelir. Sürekli teste geçiş kolay değil, buna hazırlıklı olmanız gerekiyor.
Geri bildirim eksikliği
DevOps'un etkinliği sürekli geri bildirime bağlıdır. İşbirliği ve iletişime yer yoksa sürekli iyileştirme mümkün değildir.
Geriye dönük toplantılar düzenlemeyen şirketler, CI/CD'de sürekli geri bildirim kültürünü uygulamada zorluk yaşıyor. Her yinelemenin sonunda ekip üyelerinin neyin iyi, neyin kötü gittiğini tartıştığı geriye dönük toplantılar yapılır. Retrospektif toplantılar Scrum/Agile'ın temelidir ancak DevOps için de gereklidirler.
Çünkü geriye dönük toplantılar geri bildirim ve fikir alışverişi alışkanlığını kazandırıyor. Başlangıçtaki en önemli noktalardan biri, tüm ekip tarafından anlaşılır ve tanıdık hale gelmesi için tekrarlayan retro toplantılar düzenlemektir.
Yazılım kalitesi söz konusu olduğunda, tüm ekip üyeleri bunun sürdürülmesinden sorumludur. Örneğin, geliştiriciler birim testleri yazabilir ve ayrıca test edilebilirliği göz önünde bulundurarak kod yazabilir, bu da başlangıçtan itibaren riski azaltmaya yardımcı olur.
Test etme konusundaki düşünce değişikliğini yansıtmanın basit bir yolu, test uzmanlarını QA'yı değil, yazılım test uzmanını veya kalite mühendisini aramaktır. Bu değişiklik çok basit, hatta aptalca görünebilir. Ancak birine "yazılım kalite güvence elemanı" demek, ürünün kalitesinden kimin sorumlu olduğu konusunda yanlış bir fikir verir. Agile, CI/CD ve DevOps uygulamalarında yazılım kalitesinden herkes sorumludur.
Bir diğer önemli nokta ise kalitenin tüm ekip ve ekibin her bir üyesi, organizasyon ve paydaşlar için ne anlama geldiğini anlamaktır.
Aşama tamamlamanın yanlış anlaşılması
Kalite sürekli ve genel bir süreçse, aşamanın tamamlanması konusunda ortak bir anlayışa ihtiyaç vardır. Bir sahnenin bittiğini nasıl anlarsınız? Bir adım Trello'da veya başka bir Kanban panosunda tamamlandı olarak işaretlendiğinde ne olur?
Bitti Tanımı (DoD), CD DevOps/CI bağlamında güçlü bir araçtır. Ekibin neyi ve nasıl oluşturduğuna ilişkin kalite standartlarını daha iyi anlamaya yardımcı olur.
Geliştirme ekibi "Bitti"nin ne anlama geldiğine karar vermelidir. Tamamlanmış kabul edilebilmesi için oturup her aşamada karşılanması gereken özelliklerin bir listesini yapmaları gerekir.
DoD, süreci daha şeffaf hale getirir ve tüm ekip üyeleri tarafından anlaşılması ve karşılıklı olarak mutabakata varılması halinde CI/CD'nin uygulanmasını kolaylaştırır.
Gerçekçi, açıkça tanımlanmış hedeflerin eksikliği
Bu, en sık alıntılanan tavsiyelerden biridir, ancak tekrar etmekte fayda var. CI/CD veya DevOps da dahil olmak üzere herhangi bir büyük çabada başarılı olmak için gerçekçi hedefler belirlemeniz ve performansı bunlara göre ölçmeniz gerekir. CI/CD ile neyi başarmaya çalışıyorsunuz? Bu, daha iyi kalitede daha hızlı sürümlere izin veriyor mu?
Belirlenen hedefler yalnızca şeffaf ve gerçekçi olmamalı, aynı zamanda şirketin mevcut faaliyetleriyle de tutarlı olmalıdır. Örneğin, müşterileriniz ne sıklıkla yeni yamalara veya sürümlere ihtiyaç duyuyor? Kullanıcılara ek bir fayda sağlanmayacaksa süreçleri aşırı yüklemeye ve daha hızlı yayınlamaya gerek yoktur.
Ayrıca her zaman hem CD'yi hem de CI'yı uygulamanız gerekmez. Örneğin, bankalar ve tıbbi klinikler gibi sıkı düzenlemelere tabi şirketler yalnızca CI ile çalışabilir.
CI, DevOps'u uygulayan her şirket için iyi bir başlangıç noktası görevi görür. Uygulandığında şirketlerin yazılım teslimine yaklaşımları önemli ölçüde değişiyor. CI konusunda uzmanlaştıktan sonra tüm süreci iyileştirmeyi, kullanıma sunma hızını artırmayı ve diğer değişiklikleri düşünebilirsiniz.
Birçok kuruluş için CI tek başına yeterlidir ve CD yalnızca değer kattığı takdirde uygulanmalıdır.
Uygun kontrol panellerinin ve ölçümlerin eksikliği
Hedeflerinizi belirledikten sonra geliştirme ekibi, KPI'ları ölçmek için bir kontrol paneli oluşturabilir. Geliştirilmeden önce izlenecek parametrelerin değerlendirilmesinde fayda vardır.
Farklı ekip üyeleri için farklı raporlar ve uygulamalar faydalıdır. Scrum Master daha çok statü ve erişimle ilgilenir. Üst düzey yönetim uzmanların tükenmişlik oranıyla ilgilenebilir.
Bazı ekipler ayrıca her şeyi doğru yapıp yapmadıklarını veya bir hata olup olmadığını anlamak amacıyla CI/CD'nin durumunu değerlendirmek için kırmızı, sarı ve yeşil göstergeli kontrol panelleri kullanır. Kırmızı, olup bitenlere dikkat etmeniz gerektiği anlamına gelir.
Ancak gösterge tabloları standartlaştırılmazsa yanıltıcı olabilir. Herkesin hangi verilere ihtiyacı olduğunu analiz edin ve ardından bunların ne anlama geldiğine dair standartlaştırılmış bir açıklama oluşturun. Paydaşlar için neyin daha anlamlı olduğunu öğrenin: grafikler, metin veya sayılar.
Manuel test yok
Test otomasyonu, iyi bir CI/CD hattının temelini oluşturur. Ancak tüm aşamalarda otomatik test yapılması, manuel test yapmamanız gerektiği anlamına gelmez.
Etkili bir CI/CD işlem hattı oluşturmak için manuel testlere de ihtiyacınız vardır. Testlerin her zaman insan analizi gerektiren bazı yönleri olacaktır.
Manuel test çabalarını satış hattınıza entegre etmeyi düşünmeye değer. Bazı test senaryolarının manuel testi tamamlandıktan sonra dağıtım aşamasına geçebilirsiniz.
Testleri iyileştirmeye çalışmayın
Etkili bir CI/CD hattı, test yönetimi veya entegrasyon ve sürekli izleme gibi doğru araçlara erişim gerektirir.
Güçlü, kalite odaklı bir kültür yaratmak, , dağıtım sonrası müşteri etkileşimlerini izleme ve iyileştirmeleri izleme.
İşte kolayca uygulayabileceğiniz bazı pratik ipuçları:
- Testlerinizin yazılmasının kolay olduğundan ve kodu yeniden düzenlediğinizde bozulmayacak kadar esnek olduğundan emin olun.
- Geliştirme ekipleri test sürecine dahil edilmelidir; CI ardışık düzenleri sırasında test edilmesi önemli olan kullanıcı sorunlarının ve isteklerinin listesine bakın.
- Tam test kapsamına sahip olmayabilirsiniz ancak her zaman kullanıcı deneyimi ve müşteri deneyimi açısından önemli olan akışların test edildiğinden emin olun.
Son fakat en az önemli nokta
CI/CD'ye geçiş genellikle aşağıdan yukarıya doğru gerçekleştirilir, ancak sonuçta bu, liderliğin şirketten desteğini, zamanını ve kaynaklarını gerektiren bir dönüşümdür. Sonuçta CI/CD bir dizi beceri, süreç, araç ve kültürel yeniden yapılanmadır; bu tür değişiklikler yalnızca sistematik olarak uygulanabilir.
Konuyla ilgili başka ne okunmalı?:
- .
- .
- .
Kaynak: habr.com