Tecrübe Paylaşımı — Continuous Delivery
Bazı projeler vardır ya da bazı projelerin kritik dönemleri. İşte bu dönemlerde sürekli teslim yapmanız gerekir.
Bu dönemler mesela;
- Projenin teknoloji değişikliği ihtiyacı olabilir.
- Mobil uygulama geliştirmeleriyle alakalı Web katmanlarında yapılması gereken geliştirmeler olabilir.
- Düzensiz gelen müşteri talepleri,
- Denetim süreçlerine girecek projeler olabilir…
Burada tabi ki projenin yapısı ve hızlı teslim amacı göz önünde bulundurulmalıdır. Benim aşağıda yazacağım maddeler yukarıdaki sebeplere bağlı olarak düşünülmelidir.
Avantajları
- Hızlı aksiyon alındığının görülmesi müşteri tarafında memnuniyet getirir.
- Elimizde teslim edilmemiş iş birikmez.
Her geliştirme öncesi hem mevcut geliştirme ortamı ile hem canlı ortam ile analiz yapılmasına duyulan ihtiyaç ya da ayrılan süre çok çok azalır. Canlı ile geliştirme ortamının büyük farklılıkları olmadığı için bize burdan vakit kazandırıyor. - Hata çıktığında odaklanılacak yerler bariz belli olur. Zaten en son neleri teslim ettiysek direk buralara odaklanarak hatayı çok hızlı tespit ederiz.
Dezavantajları
- Yayınlamaya çok daha fazla vakit ayrılması gerekir. Geliştirme sonrası toplu yayınlamada 1 birim harcanacaksa sürekli teslimde her gün ya da her haftada 1 birim olduğunda ve bunu aya vurduğunuzda çok daha fazla vakit aldığını görüyoruz.
- Beraberinde canlı testleri ve müşteri ile diyaloğu arttırıyor.
- Üste üste yapılacak teslimlerin etkisi büyükse ekipteki stres yükü ve yorgunlukla birlikte çıkacak olan hatanın sıklığı da artıyor. Böyle olunca her gün hata veren bir sistem gibi algılanmasına sebep olabiliyor.
- Açık kaynak kullandığınız kütüphaneler güncel sürüm çıkarmazsa ve sizin yüksek sürüme uyumluluğunuz isteniyorsa iş yükünüz artabiliyor.
Meydan Okumaları
- Eğer canlı ortam için destek personeliniz yoksa sürekli tetikte bir ekip gerekliliği getiriyor :)
- Geliştiricinin “ya ben bunu çok rahat yaparım” diye girdiği işin içinden çıkamayacağı iş akışlarıyla karşılaşması (Çıkamayacağı değilde çıkması için daha çok vakte ihtiyacı olduğu diyeyim :))
- Veri odaklı bir sistemde her test için ayrı veri senaryoları oluşturulması gerekliliği haliyle bir meydan okumaya dönüşüyor.
- Müşterinin dün istediği şey sonrası bugün değişiklik yapması ve geliştiricinin o sırada işi yarılamış olması :)
Öneriler
- Teknik ve süreçsel anlamda projeyi kavrayan kişi talepleri değerlendirmeli ve geliştirmeyi analiz ettikten sonra netleştirmeli
- Analiz edilmeden ve müşteriniz ile son çıktı üzerinde onaylaşmadan geliştirmeye başlanmamalı
- Her bir backlog ayrı branch üzerinde çalışılmalı ve code review sonrası merge edilmeli
Tecrübe köşesinden saygılar… 🦉🦉🦉
