Sürekli Entegrasyon - Riskleri Azaltma
Bir projede işlerin ters gitme ihtimali vardır. CI'yi etkili bir şekilde uygulayarak, proje geliştirme döngüsüne girdiğinde daha sonra değil, yol boyunca her adımda ne olduğunu öğrenirsiniz. CI, ortaya çıktıklarında riskleri tanımlamanıza ve azaltmanıza yardımcı olarak, somut kanıtlara dayanarak projenin sağlığını değerlendirmeyi ve raporlamayı kolaylaştırır.
Bu bölüm, Sürekli Entegrasyon kullanılarak önlenebilecek risklere odaklanacaktır.
Herhangi bir projede yönetilmesi gereken birçok risk vardır. Geliştirme yaşam döngüsünün erken aşamalarında riskleri ortadan kaldırarak, bu risklerin daha sonra, sistem fiilen hayata geçtiğinde sorunlara dönüşme şansı daha düşüktür.
Risk 1 - Kurulabilir Yazılım Eksikliği
“It works on my machine but does not work on another”- Bu muhtemelen herhangi bir yazılım organizasyonunda karşılaşılan en yaygın ifadelerden biridir. Yazılımda günlük olarak yapılan değişikliklerin sayısı nedeniyle, bazen yazılım yapısının gerçekten çalışıp çalışmadığına dair çok az güven vardır. Bu endişenin aşağıdaki üç yan etkisi vardır.
Yazılımı inşa edip edemeyeceğimize çok az güveniyor veya hiç güvenmiyoruz.
Yazılımı dahili olarak (yani test ekibi) veya harici olarak (yani müşteri) teslim etmeden önce uzun entegrasyon aşamaları, bu süre zarfında başka hiçbir şey yapılmaz.
Test edilebilir yapılar üretememe ve yeniden üretememe.
Çözüm
IDE ile derleme süreçleri arasındaki sıkı bağlantıyı ortadan kaldırır. Yalnızca yazılımı entegre etmek için ayrı bir makine kullanın. Yazılımı oluşturmak için ihtiyacınız olan her şeyin sürüm kontrol havuzunda bulunduğundan emin olun. Son olarak, bir Sürekli Entegrasyon sistemi oluşturun.
Sürekli Entegrasyon sunucusu, sürüm kontrol havuzundaki değişiklikleri izleyebilir ve depoda bir değişiklik algıladığında proje oluşturma komut dosyasını çalıştırabilir. Sürekli Entegrasyon sisteminin kapasitesi, yapının testlerden geçmesini, incelemelerin gerçekleştirilmesini ve yazılımın geliştirme ve test ortamlarında konuşlandırılmasını içerecek şekilde artırılabilir; bu şekilde her zaman çalışan bir yazılıma sahip olursunuz.
“Inability to synchronize with the database”- Bazen geliştiriciler, geliştirme sırasında veritabanını hızlı bir şekilde yeniden oluşturamaz ve bu nedenle değişiklik yapmakta zorlanır. Genellikle bu, veritabanı ekibi ile geliştirme ekibi arasındaki bir ayrılıktan kaynaklanır. Her ekip kendi sorumluluklarına odaklanacak ve birbirleri arasında çok az işbirliği olacak. Bu endişenin aşağıdaki üç yan etkisi vardır:
Veritabanında veya kaynak kodunda değişiklik yapma veya yeniden düzenleme korkusu.
Veritabanını farklı test verileri kümeleriyle doldurmada zorluk.
Geliştirme ve test ortamlarının (ör. Geliştirme, Entegrasyon, Kalite Güvencesi ve Test) sürdürülmesinde zorluk.
Çözüm
Yukarıdaki sorunun çözümü, tüm veritabanı yapılarının sürüm kontrol havuzuna yerleştirilmesinin gerçekleştirilmesini sağlamaktır. Bu, veritabanı şemasını ve verilerini yeniden oluşturmak için gereken her şey anlamına gelir: veritabanı oluşturma komut dosyaları, veri işleme komut dosyaları, depolanmış prosedürler, tetikleyiciler ve diğer veritabanı varlıklarına ihtiyaç vardır.
Veritabanınızı ve tablolarınızı bırakıp yeniden oluşturarak, derleme komut dosyanızdaki veritabanını ve verileri yeniden oluşturun. Ardından, depolanan prosedürleri ve tetikleyicileri uygulayın ve son olarak test verilerini ekleyin.
Veritabanınızı test edin (ve inceleyin). Genellikle, veri tabanını ve verileri test etmek için bileşen testlerini kullanırsınız. Bazı durumlarda, veritabanına özgü testler yazmanız gerekir.
Risk 2 - Kusurları Yaşam Döngüsünün Geç Keşfi
Kaynak kodunda birden fazla geliştirici tarafından sık sık meydana gelen çok fazla değişiklik olduğundan, kodda yalnızca daha sonraki bir aşamada tespit edilebilecek bir kusurun ortaya çıkma ihtimali her zaman vardır. Bu gibi durumlarda, bu büyük bir etkiye neden olabilir çünkü yazılımda hata ne kadar geç tespit edilirse, hatayı gidermek o kadar pahalı hale gelir.
Çözüm
Regression Testing- Bu, herhangi bir yazılım geliştirme döngüsünün en önemli yönüdür, tekrar test edin ve test edin. Yazılım kodunda büyük bir değişiklik varsa, tüm testlerin çalıştırıldığından emin olmak kesinlikle zorunludur. Ve bu, Sürekli Entegrasyon sunucusunun yardımıyla otomatik hale getirilebilir.
Test Coverage- Test senaryoları kodun tüm işlevselliğini kapsamıyorsa test etmenin bir anlamı yoktur. Uygulamayı test etmek için oluşturulan test senaryolarının eksiksiz olduğundan ve tüm kod yollarının test edildiğinden emin olmak önemlidir.
Örneğin, test edilmesi gereken bir giriş ekranınız varsa, başarılı bir giriş senaryosuna sahip bir test senaryosuna sahip olamazsınız. Bir kullanıcının farklı bir kullanıcı adı ve şifre kombinasyonu girdiği ve ardından bu tür senaryolarda ne olduğunu görmeniz gereken negatif bir test senaryosuna sahip olmanız gerekir.
Risk 3 - Proje Görünürlüğünün Olmaması
Manuel iletişim mekanizmaları, proje bilgilerinin doğru kişilere zamanında dağıtılmasını sağlamak için çok fazla koordinasyon gerektirir. Yanınızdaki geliştiriciye yaslanmak ve onlara en son derlemenin ortak drive'da olduğunu bildirmek oldukça etkili, ancak çok iyi ölçeklenmiyor.
Ya bu bilgiye ihtiyaç duyan başka geliştiriciler varsa ve onlar ara veriyorsa veya başka bir şekilde müsait değilse? Bir sunucu çökerse, nasıl bilgilendirilirsiniz? Bazıları, manuel olarak bir e-posta göndererek bu riski azaltabileceklerine inanıyor. Ancak bu, bilginin doğru zamanda doğru kişilere iletilmesini garanti edemez çünkü yanlışlıkla ilgili tarafları dışarıda bırakabilirsiniz ve bazıları o anda e-postalarına erişemeyebilir.
Çözüm
Bu sorunun çözümü yine Sürekli Entegrasyon sunucusudur. Tüm CI sunucuları, yapılar başarısız olduğunda tetiklenecek otomatik e-postalara sahip olma özelliğine sahiptir. Tüm kilit paydaşlara gönderilen bu otomatik bildirim ile, herkesin yazılımın mevcut durumu hakkında bilgi sahibi olması da sağlanır.
Risk 4 - Düşük Kaliteli Yazılım
Kusurlar var ve sonra potansiyel kusurlar var. Yazılımınız iyi tasarlanmadığında veya proje standartlarına uymuyorsa veya bakımı karmaşıksa potansiyel kusurlarınız olabilir. Bazen insanlar buna kod veya tasarım kokuları diyor - "bir şeylerin yanlış olabileceğinin bir belirtisi."
Bazıları, düşük kaliteli yazılımın yalnızca ertelenmiş bir proje maliyeti olduğuna inanıyor (teslimattan sonra). Ertelenmiş bir proje maliyeti olabilir, ancak yazılımı kullanıcılara teslim etmeden önce başka birçok soruna da yol açar. Aşırı karmaşık kod, mimariyi takip etmeyen kod ve yinelenen kod - bunların tümü genellikle yazılımda kusurlara yol açar. Bu kod ve tasarım kokularını kusurlara dönüşmeden önce bulmak hem zamandan hem de paradan tasarruf sağlayabilir ve daha yüksek kaliteli yazılımlara yol açabilir.
Çözüm
CI yazılımı ile entegre edilebilen bir kod kalitesi kontrolü gerçekleştirmek için yazılım bileşenleri vardır. Bu, kodun gerçekten uygun kodlama yönergelerine uyduğundan emin olmak için kod oluşturulduktan sonra çalıştırılabilir.