Continous Integration - Sürekli Entegrasyon ve Testler

Merhaba,

Kendime en anladığım yazıları toparladığım bir makale yazacağım. Orjinal kaynakları en alt satırdan bulabilirsiniz. CI/ CD süreçlerine yeni geçiş yapacağım. Android Developer'ım..

CI : Yazılım akışını yöneten bir modeldir. 
Integration yani Entegrasyon : geliştirme sürecinde takım üyelerinin yaptığı değişikliklerin ana koda dahil edilmesi anlamında kullanılır.
Herkesin ana branch'e kod değişikliklerini commit edip sürekli push ettiği model aslında bir continuous integration modelidir

Ancak : 

Kod yarım yamalak push'lanırsa, mesela derlenmez haldeyse bu sefer o halini çeken takım üyeleri ellerinde çalışmayan bir kod elde ederler (bkz: build break). 

Bu takımın çalışmasını durdurur. Herkesin o bozukluğu kafasına göre düzeltmeye çalışmasına, Çakışmalara ve oldukça vakit kaybına yol açar.

O yüzden her değişiklik push'landığında bunları derlemeye çalışıp hata varsa değişikliği yollayanı uyaran bir sistem gerekir. 

İşte bunlara ci yazılımı deniyor. jenkins, hudson, travis gibi yazılımların temelde çıkış amacı bu.
Peki yazılım başarıyla derlense yetiyor mu? 

Yetmiyor. Yazılımcı belki kodun derlenmesini değil ama doğru çalışmasını bozan bir değişiklik push etti.

Bu sefer diğer takım üyeleri bu halini çekerlerse yazılımı doğru olarak test edemez hale geliyorlar. Kendi geliştirme süreçleri yine duruyor.
Buna engel olmak için de CI yazılımlarına "unit testleri de çalıştır" özelliği eklenir. 

Testler hata vermeye başlarsa değişikliği yapan uyarılır. Takımın "bak bu halini çekersen elinde patlar düzeltilene kadar bekle" mesajı alması sağlanır.


Peki unit testler yetiyor mu? 

Yetmiyor. Belki sadece son kullanıcının kullanım senaryolarında bir hata ortaya çıktı? Bunları da "ui test"lerle bulmak mümkün olabilir ama onları otomatik geliştirmesi ve her ui değişikliğinde güncel tutması zahmetli. 

Ne yapılabilir? O durumda ci yazılımı kodun son halini alır bir yere çalışır halde koyar (deploy eder). Böylece geliştiricilerin ve varsa testçilerin kodun son halini test etmesi ve bir hata varsa raporlaması mümkün olur.

Ci kullanılmasa ne olur? 

Herkes kendi branch'lerinde çok uzun süre çalışırsa sonunda kod birleştirilemez bir hal alabilir. Windows vista'nın geliştirme sürecinde başa gelen ve kodun en baştan yazılmasına yol açan meşhur longhorn reset olayı gibi mesela.

 Tabi o çok uçuk ve büyük çaplı bir durum ama küçük projelerde dahi geliştiriciler birbirlerinden kopuk ilerlerse bir süre sonra kodları birbirlerini tanımaz hal alablir.

CI genel olarak agile disiplinlerinde de tercih edilir.



Yani CI pipeline'i 3 adımdan oluşuyor:  

• Kaynak kodun güncel halinin alınması ve derlenmesi - BuildTestlerin çalıştırılması - TestBuild paketinin uygulama sunucusuna deploy edilmesi - Deploy

Konularında bize yardımcı oluyor.

Şimdi, projemizde çok sayıda unit/integration vb. test yazdığımızı ve CI pipeline ımızın Test adımının bir hayli zaman aldığını düşünelim. Eğer az sayıda proje üzerinde çalışan küçük bir ekipseniz bu durum sizin için önemsiz olabilir. Öyle olsa bile CI sunucunuzu yani kaynaklarınızı verimli kullanmak istersiniz. Öte yandan çok fazla projenin olduğu, birden fazla alt takımdan oluşan organizasyonlarda ise, uzun süren CI pipeline’ları kuyrukta bekleme süresini uzatacakYani çok sayıda test senaryonuz( dolayısıyla test metodunuz ) varsa, testlerin çalıştırılma süresini gereksiz yere uzatmaktan kaçınmanız gerekiyor

3 Ay sonra güncelleme - Build Pipeline nedir? 

Kodunuz çalışıyor mu? Developa kod doğru ve çalışır bir şekilde eklendi mi? Testlerinizde ya da Dagger da ya da kodda bir hata var mı? Tüm kodu derliyor. Eğer Build Succes ise kodu başarıyla branch'e merge ediyorsunuz..

Biz hangi CI/CD tool'u kullanıyoruz ? 

Azure Devops.

Kaynak :
 https://medium.com/devopsturkiye/unit-test-mi-integration-test-mi-34ddea054696  

https://eksisozluk.com/surekli-entegrasyon--5114871?p=