Entegrasyon, dallarla çelişiyor!
Endüstrinin özellikleri, farklı özelliklerin gelişimini ayırmak için popüler bir yaklaşımdır – ancak maalesef bu, entegrasyon amacı tüm değişiklikleri sürekli olarak entegre etmeye devam etmektedir. Peki ne yapmalı?
90'larda bir müşteri bir gün boyunca tavsiye ettim. Ancak sonunda, günün çoğunu birisinin yazılımı doldurmaya çalışmasını izlemek için geçirdim. Bu artık bir sorun değil: Kaotik projeler bile yeni tamamlanmış yazılımın nispeten güncel bir durumunu gösterebilir.
Üzerinde çalıştığım daha geniş bir projede başka bir seviyede zorluk vardı: ekiplerin her biri modüllerini inşa etti. Serbest bırakılmadan önce, bir görev gücü düzenli olarak çeşitli ekiplerin modüllerini entegre etmeye kararlıydı. Derleme için tüm modülleri yapmak genellikle haftalar talep etmiştir. Bugün, çoğu projede, sürümün kontrolüne kıyasla tüm değişiklikler düzenli olarak kontrol edilir, derlenir ve tüm takımlar tarafından test edilir. Sonuç olarak, bu sorunlar artık gerçekleşemez. Tüm takımların değişiklikleri sürekli olarak test edilir. Sürekli entegrasyondan bahsediliyor (sürekli entegrasyon): Tüm takımların tüm değişiklikleri sürekli olarak entegre edilmiştir.
Jenkins veya TeamCity gibi sürekli entegrasyon sunucuları bu işlemi otomatikleştirmek için araçlardır. Belirli bir daldaki değişiklikler versiyonun kontrolü ile seçilir, derlenmiş ve birim testleri gerçekleştirilir.
Özelliklerin özellikleri
İşlevsellik dalları, işlevselliğin geliştirilmesini bir sürüm kontrolü ile ayırmak için bir şemadır. Geliştiriciler, sürümü kontrol etmede bir sektörde yeni özellikler oluşturur. Bu şekilde, her özellik ayrı olarak geliştirilebilir. Git gibi modern araçlarla, bu birçok eski araçtan çok daha kolaydır. Git başlangıçta Linux'un geliştirilmesi için bir araç olarak başladı. Orada, ramifikasyon yeni özelliklerin gelişimini izole etmek ve ayrıca hata düzeltmelerini ayrı ayrı geliştirmek için kullanılır. Sadece bir revizyondan sonra değişiklikler gerçekten tespit edilecek.
Bu nedenle, özelliklerin dalları belirli değişiklikleri izole ediyor. Ve bu tam olarak sorun. Çeşitli özelliklere kıyasla değişiklikler artık entegre değil. Sadece ana dalda şube kabul edildiğinde, sektördeki değişiklikler diğer değişikliklerle entegre edilecektir. Ve ancak o zaman çatışmalar ve sorunlar ortaya çıkıyor. Bu nedenle artık sürekli entegrasyon, yani sürekli veya sürekli entegrasyon değildir. Bunun yerine, işlevselliğin dalları tekrar ayarlandığında bir entegrasyon vardır.
Şimdi, belirli bir anlamda, memur memurları arasındaki geliştiricilerin sürekli entegrasyon arasındaki çalışmalarına itiraz edilebilir. Haftalarca değişiklikleri hakkında yorum yapmayan herkesin de entegrasyon sorunları olacaktır. Bu bağlamda, bunlar da dallardır. Ancak pratikte, bu sorunlara neredeyse hiç yol açmaz, çünkü şimdi sık sık taahhüt etmişlerdir.
Endüstri, örneğin prototipler, zirveler veya bir şeyler denemek için başka nedenlerle de var olabilir. Böylece şubenizin izolasyonu, değişikliklerin ana dala akışından daha iyi olabilir ve daha sonra çıkarılmalıdır.
Şimdi ne var?
Karakteristik endüstri işe yarayabilir. Birçok takım iyi deneyimler yaşadı. Sektördeki uygulama çok fazla zaman almamalıdır, böylece çatışmalar çok büyük olmamalıdır. Aynı şekilde, şube sayısı çok büyük olmamalıdır. Kod, şubeler arasında düzenli olarak değiştirilmeli ve ana şubeden kod sektöre aktarılmalıdır. Ancak sürekli entegrasyonla çelişki olmaya devam ediyor: değişikliklerin hepsi entegre değil. Her işlevsellik sektörü için sürekli bir entegrasyon sunucusu yardımcı olmaz. Bu sunucu ile daldaki değişikliklerin diğer dallarla doldurulup entegrasyonunun mümkün olmadığını kontrol edebilir.
Teslimat sorunu sürdürür: Sürekli entegrasyon sunucularının entegrasyonu, derlenmesi ve test edilmesine ek olarak, sonunda DE yazılım DE'ye kadar boru hattına daha fazla test seviyesi eklenir. Tam bir sürekli dağıtım borusuna sahip her dalın ekipmanı sadece karmaşık değildir, aynı zamanda boru hattı üretimden önce bir yerde bitirmek zorunda kalmalıdır – sonuçta, sadece bir sektör üretime geçebilir.
Levetta'daki işlevsellik
Bununla birlikte, hemen üretime gitmeden özellikleri geliştirmek için sürekli entegrasyonla da mümkün olmalıdır. Ayrıca işlevsellik toogles vardır. Prensip olarak, bu sadece yeni özelliklerin üretimde kullanılamayacak şekilde devre dışı bırakılabileceği anlamına gelir – prensip olarak bunlar basit vaka farklılıklarıdır. Bu, endüstri olmadan yeni özellikler geliştirmenizi sağlar. Hepsi ana dalda birlikte uygulanır. Fonksiyonlar, üretimde hala devre dışı bırakılırken test ortamlarında etkinleştirilebilir.
İşlevsel faaliyetlerin de başka avantajları vardır: yeni bir işlevselliğin canlı bandı dağıtım tarafından reddedilir. Yazılım dağıtılabilir, işlevsellik önce devre dışı bırakılabilir ve bu nedenle belirli bir anda etkinleştirilebilir. Bu, belirli özellikler için son tarihleri daha kolay hale getirir. Yazılım çok daha erken üretimde olabilir, sadece bir işlevsellik anahtarı önemli tarihte farklı şekilde ayarlanır.
Özellikler aslında kolay. Ancak yine de herhangi bir sorun var: Belli bir noktada kod, yaramaz işlevden kurtulmalıdır. [-] Ama ne zaman? Ve elbette üretim için doğru özelliğin her zaman üretimde olduğu garanti edilmelidir. Buna ek olarak, konsept genellikle yanlış kullanılır: bir grup kullanıcının bir işlevi kullanabileceği ve başka bir işlevi kullanmadığı, ancak başka bir hedefe ihtiyacınız var. Karıştırma, test ve üretimdeki çeşitli testlerin yönetimini daha da karmaşık hale getirir.
Çözüm
Entegrasyon, dallarla çelişiyor. Entegrasyon, tüm değişikliklerin, endüstri endüstrisinin, özelliklerin izolasyonu ve inkâr edilmesine yönelik sürekli bir entegrasyonunu amaçlamaktadır. Bununla birlikte, bu, prosedürlerden birinin daha iyi olmasına izin vermez. Bugün işlevsellik dallarıyla başarılı bir şekilde çalışan ve entegrasyon sorunu olmayan herkes bu yaklaşımla çalışmaya devam edebilir. Sürekli entegrasyon, özelliklerin özellikleri ve diğer birçok kavram sadece takımların kişisel araçlarını bir araya getirebileceği araçlardır. Ayrıca işlevsellik faaliyetleri zorluksuz değildir.
PS: Meslektaşları Innoq Philipp Haußleiter, Alexander Heusingfeld, Willem Van Kerkhof, Andreas Krüger, Timo Loist ve Philipp Schirrmacher'a blog yazısının ilk versiyonunda tartışma için teşekkürler!
()