Özellik Dalları Gidilecek Nihai Yol mu?

Git için ortak iş akışı (git akışı), her yeni özellik için ayrı bir dalın oluşturulduğu özellik dallarını kullanır. Geliştiriciler bu yalıtılmış dallara yeni işlevler uygular ve ardından değişikliklerini tekrar main veya master dalda birleştirir.

Bu iş akışının faydaları açıktır: QA ortamında ayrı bir şube uygun bir şekilde dağıtılabilir ve test edilebilir ve kritik hatalar tespit edilirse main şubeyle birleştirilmez. Aynı dalda sorunlar düzeltilebilir ve kod geliştirilebilir.

Bu arada ana şube sürekli olarak konuşlandırılabilir durumda kalır ve bu sorunlardan korunur.

Ne yazık ki, bu stratejinin önemli bir dezavantajı var: birleştirme çatışmaları. Bir noktada kaçınılmaz olan uzun ömürlü dallarla bu çatışmaların çözümü çok zor olabilir ve daldan tamamen kurtulmak ve sıfırdan başlamak daha kolay hale gelebilir.

Ayrıca, çok sayıda çatışma olduğunda birleştirme sonucu tahmin edilemeyebilir.

Ancak olası tek strateji bu değildir ve bu makale, yukarıda listelenen dezavantajlar olmadan yeni ürün özelliklerini yönetmenin alternatif bir yolunu ele alacaktır.

Birleştirme Çatışmaları Neden Oluşur?

Git tasarımına göre, birleştirme sırasında dalların aynı dosya satırında farklı içeriğe sahip olması durumunda birleştirme çakışmaları meydana gelir.

Bunu açıklamak için, iki ekibin aynı hizmete yönelik güncelleştirmeleri uyguladığı bir senaryoyu ele alalım. A Takımı kredi kartı desteğini entegre ederken, B Takımı kullanıcı profili sayfasını yeniliyor. Bu özelliklerin birbiriyle hiçbir ilgisi yok gibi görünüyor.

Ancak ödemeyle ilgili kodun daha önce profil sayfası koduyla aynı yerde bulunduğu ortaya çıktı. Böylece her iki ekip de kodlarını ayrı dallara çıkardı ve entegrasyonu yeniden yazdı.

Şimdi soru şu: Diğer takım ortaya çıkan çatışmayı çözmeye çalışırken, değişikliklerini main dalda birleştiren ve sorun kendi tarafında değilmiş gibi davranan ilk kişi kim olacak?

Gövde Tabanlı Geliştirme

Birleştirme çatışmalarından tamamen kaçınmak imkansızdır, ancak aşağıdaki iyi bilinen kuralı kullanarak bunların çözülmesini kesinlikle daha kolay hale getirebiliriz:

Git açısından bu, mümkün olduğu kadar sık birleşmemiz gerektiği anlamına gelir (ideal olarak her işlemde). Ve elbette bu durumda çatışmalar daha sık yaşanacaktır, ancak bunları çözmek çok daha kolay olacaktır.

Buna gövde tabanlı geliştirme denir ve değişiklikleri doğrudan main dala itmek ve gereksiz dalları kullanmaktan kaçınmak anlamına gelir.

Yukarıdaki örnekte, eğer her iki takım da düzenli olarak değişikliklerini main şubeye gönderseydi, aynı dosyayı değiştirmeye çalıştıklarını hemen fark edeceklerdi.

Dahası, sorunlardan tamamen kaçınabilirlerdi. İkinci takım, ilk takım bu güncellemeleri dikkate alarak dosyayı değiştirdikten sonra değişikliklerini yapmaya başlayacaktı.

Dikkatli bir okuyucu şunu merak edebilir: Her şey kulağa harika geliyor ama testi nasıl yapacağız? Özellik başına dallar, tüm yeni işlevselliğin yayınlanmadan önce ayrı ayrı test edilmesine olanak tanır; değişiklikleri sürekli olarak main şubeye entegre edersek bunun şansı kalmayacaktır.

Özellik Bayraklarıyla Tanışın

Özellik bayrağı veya özellik geçişi, çalışma zamanında belirli bir özelliğin değiştirilmesine izin veren basit bir dinamik bayraktır. Genel olarak özellik bayrakları, QA mühendisleri, personel, belirli müşteriler vb. gibi belirli kullanıcı grupları için özelliklerin etkinleştirilmesine veya devre dışı bırakılmasına da olanak tanır.

Özellik bayraklarının birkaç ekstra avantajı vardır:

• Risksiz dağıtım

• Doğrudan üretimde daha güvenilir testler

• Gerektiğinde değişiklikleri hızla geri alın.

Özellik bayraklarının kullanılması, main dalda yapılan değişiklikleri daha güvenli hale getirir. Özellik bayrağı kapalıyken değişiklikler kimseyi etkilemez.

Bu teknik, doğrudan main dalla çalışmaya veya kısa ömürlü dallar oluşturmaya olanak sağlar. Bu nedenle, birleştirme çatışmaları oldukça nadir hale geliyor ve hızla çözülüyor.

Çözüm

Özetle, özellik bayraklarıyla birleştirilmiş gövde tabanlı geliştirme, özellik dallarındaki çelişkili değişikliklerin yol açtığı birçok sorunun önlenmesine yardımcı olan mükemmel bir tekniktir.

Ancak her zaman olduğu gibi herkese uyacak tek bir kalıp yoktur. Aynı veri deposunda çalışan az sayıda ekip için işe yarar; bu sayının arttırılması genellikle bazı ayarlamalar gerektirir.

Üstelik her iki yöntemi de kullanmak her zaman mümkündür: belirli duruma ve göreve bağlı olarak özellik dallarını veya özellik bayraklarını kullanın.