Artık git ile çalışmayan kalmadı sanırım. Bilindiği üzere gitflow isminde bir çalışma modeli var. Bu modelde uzun ömürlü feature branchlar ve ihtiva ettikleri daha geniş kapsamlı commitler ile çalışılmakta. Bu yazımda sizlerle bu modelin dejavantajları ve sebep olduğu sorunlar ve zorunlulukklar hakkındaki fikirlerimi paylaşmak istiyorum.
İlk etapta bir feature branch bünyesinde çalışmak mantıklı bir opsiyon olarak görünebilir. Programcı mevcut master ya da develop branchdan “git checkout -b feature/my-feature-branch” ile bir feature branch oluşturur ve üstlendiği işi bu branch bünyesinde geliştirir. Bu süreç sonunda bir pull request yardımı ile feature branch bünyesindeki değişilik ekibe duyurulur ve code review yapılması sağlanır. Bu işlem sonunda feature branch bünyesindeki yeni kodun kaynağa geri dönmesi amacıyla trunk olarak tabir edilen master ya da develop ile merge edilir. Bu işlem gerçekleştiği anda trunk sürekli entegrasyon dahilinda build ve deploy edilir.
Şimdi bu süreçde neler olduğuna ve ne gibi sorunların doğduğuna bir göz atalım. Öncelikle feature branch oluşumu gerçekten (reality) kopuş ve izolasyona girmek anlamına gelmektedir. Yazılımcı kendisini feature branch oluşturuğu andan itibaren öncelikle sürekli entegrasyon sürecinin dışına almaktadır. Sürekli entegrasyon uygulamanın her daim tüm değişikliklerle derlenebilir, deploy edilebilir ve test edilebilir olmasını sağlamaktadır. Sürekli entegrasyon trunk dahilinde yapıldığı taktirde tüm ekibin yaptığı değişiklikleri entegre edebilir. Feature branch bünyesinde çalışan bir yazılımcının yaptığı değişiklikler feature branch içinde kalındığı sürece sürekli entegre edilmez ve bu şekilde yazılımcı feature branch bünyesinde izolasyona mahkum kalır. Burada trunk ile rebase yapılması hiçbir şey ifade etmez, çünkü yazılımcının rebase ile trunkdan aldığı değişiklikler sürekli entegrasyondaki kaliteyi sağlamaz, yani rebase sürekli entegrasyonun yerini alamaz.
Feature branch bünyesindeki commit sayısı ve commitlerin hacimleri daha büyüktür. Yazılımcı trunk bünyesindeki gelişmelere bakmak zorunda kalmadan rahat bir şekilde kendi işi üzerinde çalışmaya devam eder. Bu haftaları alan bir sürece dönüşebilir. İki haftadan fazla bir gelişmeyi ihtiva eden feature branchı tekrar trunk ile merge etmek çok zor bir hal alabilir ya da mümkün değildir. Bu kod bazında da entegrasyonun sekteye uğradığı anlamına gelmektedir ve bu projeyi sıkıntı ve rizikoya solabilecek bir durumdur.
Diğer bir sorun ise feature branch modelinin feature branch deployment zorunluluğu doğuruabilmesidir. Yazılımcı feature branch bünyesinde çalıştığı sürece bir paralel evrende yaşar ve projenin sürekli entegrasyon ve sürekli deployment gibi nimetlerinden faydalanamaz. Sürekli deployment ile uygulama ihtiva ettiği tüm özellikleri ile tanımlı bir ortamda çalışır hale getirilmektedir. Feature branchın trunka dönmediği sürece ne oranda entegre ve deploy edilebilir olduğu muammadır. Bazı şartlar altında feature branch bünyesinde yapılan değişikliklerin test edilebilmesi için dev ortamına deploy edilmesini gerektirebilir. Örneğin milyonlarda kafka mesajını lokalde işleyemeyen (kapasite eksikliği, işlemin uzun sürmesi ya da gerekli veritabanı ya da kafka altyapısına erişimin lokalde olmaması) bir fetaure branch test edilmek amacıyla dev ortamına taşınmak zorunda kalınacaktır. Bu feature branch deployment anlamına gelmektedir. Böyle bir yapıdaki en büyük problem yine diğer değişikliklerle entegre olmamış bir yapının kendi izolasyonu bünyesinde deploy edilip, test edilmesidir. Tam entegre olmamış bir uygulamanin bu şekilde test edilmesi hiçbir şey ifade etmemektedir, çünkü entegratif bir yapı ile oluşması mümkün yan etkilerin ortaya çıkma şansı bulunmamaktadır. Bunun yanı sıra feature branch deploy edildikten sonra yazılımcı sadece kendi bölümüne konsantre olduğu için diğer bölümler test edilemeyecek ve yine oluşması mümkün yan etkilerin ortaya çıkması engellenmiş olacaktır.
Gitflow sürekli entegrasyon ve sürekli deployment önünde büyük engel oluşturmakta ve paralel evrenlerin oluşmasını teşvik etmektedir. Feature branch ile çalışmak yazılımcıya güven verebilir. Buradaki ana niyet değişikliklerin izole bir şekilde uygulamaya zarar vermeden yapılmasına alan tanımaktır. Lakin oluşan bu alan feature branch ile ın arasını açmakta ve entegrasyonun yapılmasını engellemektedir. Bu sebeple gitflow modeli ile çalışılması tavsiye edilmektedir.
Bunun yerine trunkbased calışmak, yapılan değişikliklerin meydan vereceği etkileri anında görmeyi mümkün kılacaktır. Bu geri bildirim uygulamanın hangi durumda olduğunu görmek ve gerekli tedbirlerin alınmasını kolaylaştıracaktır.
EOF (End Of Fun)
Özcan Acar
