Sürekli Entegrasyon - Gereksinimler
Sürekli Entegrasyon için en önemli gereksinimlerin listesi aşağıdadır.
Check-In Regularly- Sürekli entegrasyonun düzgün çalışması için en önemli uygulama, kaynak kodu havuzunun ana hattına veya ana hattına sık sık yapılan kontrollerdir. Kod girişi günde en az birkaç kez yapılmalıdır. Düzenli olarak check-in yapmak birçok başka fayda sağlar. Değişiklikleri küçültür ve dolayısıyla yapıyı bozma olasılığını azaltır. Bu, yazılımın geri dönülecek en son sürümünün, sonraki herhangi bir derlemede bir hata yapıldığında bilinmesi anlamına gelir.
Ayrıca, kodu yeniden düzenleme konusunda daha disiplinli olmaya ve davranışı koruyan küçük değişikliklere bağlı kalmaya yardımcı olur. Çok sayıda dosyayı değiştiren değişikliklerin diğer insanların çalışmalarıyla çelişme olasılığının düşük olmasını sağlamaya yardımcı olur. Geliştiricilerin daha keşfedici olmalarına, fikirleri denemelerine ve son taahhüt edilen sürüme geri dönerek onları atmalarına olanak tanır.
Create a Comprehensive Automated Test Suite- Kapsamlı bir otomatik test paketiniz yoksa, başarılı bir yapı yalnızca uygulamanın derlenebileceği ve birleştirilebileceği anlamına gelir. Bazı ekipler için bu büyük bir adım olsa da, uygulamanızın gerçekten çalıştığına dair güven sağlamak için belirli düzeyde otomatik testlere sahip olmak çok önemlidir.
Normalde Sürekli Entegrasyonda yapılan 3 tip test vardır: unit tests, component tests, ve acceptance tests.
Birim testleri, uygulamanızın küçük parçalarının davranışını ayrı ayrı test etmek için yazılır. Genellikle tüm uygulamayı başlatmadan çalıştırılabilirler. Veritabanına (uygulamanızda varsa), dosya sistemine veya ağa isabet etmezler. Uygulamanızın üretim benzeri bir ortamda çalışmasını gerektirmezler. Birim testleri çok hızlı çalışmalıdır - tüm paketiniz, büyük bir uygulama için bile, on dakikadan daha kısa bir sürede çalışabilmelidir.
Bileşen testleri, uygulamanızın çeşitli bileşenlerinin davranışını test eder. Birim testleri gibi, her zaman tüm uygulamanın başlatılmasını gerektirmezler. Ancak, veritabanına, dosya sistemine veya diğer sistemlere çarpabilirler (bunlar kapatılabilir). Bileşen testlerinin çalıştırılması genellikle daha uzun sürer.
Keep the Build and Test Process Short - Kodu oluşturmak ve birim testlerini çalıştırmak çok uzun sürerse, aşağıdaki sorunlarla karşılaşırsınız.
İnsanlar tam bir derleme yapmayı bırakacak ve check-in yapmadan önce testleri çalıştıracak. Daha başarısız yapılar almaya başlayacaksınız.
Sürekli Entegrasyon süreci o kadar uzun sürer ki, siz yapıyı tekrar çalıştırabildiğiniz zaman birden fazla kaydetme gerçekleşmiş olur, böylece hangi girişin yapıyı bozduğunu bilemezsiniz.
İnsanlar daha az check-in yapacaklar çünkü yazılımın oluşturulmasını ve testlerin çalışmasını beklemek için yaşları boyunca oturmak zorunda kalıyorlar.
Don’t Check-In on a Broken Build- Sürekli entegrasyonun en büyük hatası, bozuk bir yapıyı kontrol etmektir. Derleme bozulursa, sorumlu geliştiriciler onu düzeltmeyi bekler. Kırılmanın nedenini mümkün olan en kısa sürede tespit edip düzeltiyorlar. Bu stratejiyi benimsersek, kırılmaya neyin sebep olduğunu bulmak ve derhal düzeltmek için her zaman en iyi konumda olacağız.
İş arkadaşlarımızdan biri bir check-in yaptıysa ve sonuç olarak yapıyı bozduysa, en iyi tamir şansına sahip olmak için, sorunu net bir şekilde çözmeye ihtiyaçları olacaktır. Bu kural ihlal edildiğinde, yapının düzeltilmesi kaçınılmaz olarak çok daha uzun sürer. İnsanlar yapının bozuk olduğunu görmeye alışırlar ve çok hızlı bir şekilde yapının her zaman bozuk kaldığı bir duruma girersiniz.
Always Run All Commit Tests Locally Before Committing- Uygulama için tasarlanan testlerin CI sunucusunda çalıştırılmadan önce yerel bir makinede çalıştırıldığından her zaman emin olun. Bu, doğru test senaryolarının yazıldığından emin olmak içindir ve CI sürecinde herhangi bir başarısızlık varsa, bunun nedeni başarısız test sonuçlarıdır.
Take Responsibility for All Breakages that Result from Your Changes- Bir değişiklik yaparsanız ve yazdığınız tüm testler geçerse, ancak diğerleri bozulursa, yapı hala bozuktur. Genellikle bu, uygulamaya bir gerileme hatası oluşturduğunuz anlamına gelir. Değişikliklerinizin sonucu olarak geçmeyen tüm testleri düzeltmek sizin sorumluluğunuzdadır - değişikliği siz yaptınız. CI bağlamında bu açık görünmektedir, ancak aslında pek çok projede yaygın bir uygulama değildir.