Trunk Tabanlı Geliştirme ve Git Akışı

Kaliteli bir yazılım geliştirmek için tüm değişiklikleri takip edebilmemiz ve gerekirse geri alabilmemiz gerekir. Sürüm kontrol sistemleri, proje geçmişini izleyerek ve birden fazla kişi tarafından yapılan değişiklikleri birleştirmeye yardımcı olarak bu rolü doldurur. İşi büyük ölçüde hızlandırırlar ve bize hataları daha kolay bulma yeteneği verirler.

Ayrıca, dağıtık ekipler halinde çalışmak da büyük ölçüde bu araçlar sayesinde mümkündür. Birkaç kişinin aynı anda bir projenin farklı bölümlerinde çalışmasına ve daha sonra sonuçlarını tek bir üründe birleştirmesine olanak tanırlar. Versiyon kontrol sistemlerine daha yakından bakalım ve gövde tabanlı geliştirme ve Git akışının nasıl ortaya çıktığını açıklayalım.

Sürüm Kontrol Sistemleri Dünyayı Nasıl Değiştirdi?

Versiyon kontrol sistemleri oluşturulmadan önce, insanlar projelerin önceki versiyonlarını manuel olarak yedeklemeye güveniyorlardı. Birden fazla geliştiricinin çalışmasını aynı projede birleştirmek için değiştirilmiş dosyaları elle kopyalıyorlardı.

Çok fazla zamana, sabit disk alanına ve paraya mal olur.

Tarihe baktığımızda, üç nesil sürüm kontrol yazılımını geniş bir şekilde ayırt edebiliriz.

Onlara bir göz atalım:

Versiyon kontrol sistemleri olgunlaştıkça, projeler üzerinde paralel olarak çalışma yeteneğini artırma eğilimi olduğunu fark ediyoruz.

En çığır açan değişikliklerden biri, dosyaları kilitlemekten bunun yerine değişiklikleri birleştirmeye geçiş oldu. Programcıların daha verimli çalışmasını sağladı.

Bir diğer önemli gelişme, dağıtılmış sistemlerin tanıtılmasıydı. Git, bu felsefeyi birleştiren ilk araçlardan biriydi. Kelimenin tam anlamıyla açık kaynak dünyasının gelişmesini sağladı. Git, geliştiricilerin tüm depoyu çatallama adı verilen bir işlemle kopyalamasına ve birleştirme çakışmaları konusunda endişelenmeden istenen değişiklikleri yapmasına olanak tanır.

Daha sonra, değişikliklerini orijinal projeyle birleştirmek için bir çekme isteği başlatabilirler. İlk geliştirici, bu değişiklikleri diğer depolardan dahil etmekle ilgilenmiyorsa, bunları kendi başlarına ayrı projelere dönüştürebilir. Merkezi depolama kavramının olmaması sayesinde her şey mümkün.

Geliştirme Stilleri

Günümüzde en popüler sürüm kontrol sistemi kesinlikle Git'tir ve 2016'da yaklaşık yüzde 70'lik bir pazar payına sahiptir.

Git, Linux'un yükselişi ve genel olarak açık kaynak ortamı ile popüler hale geldi. Şu anda kamu projeleri için en popüler çevrimiçi depolama alanı olan GitHub, yaygınlığına da önemli ölçüde katkıda bulundu. Yönetilmesi kolay çekme isteklerinin tanıtımını Git'e borçluyuz.

Basitçe söylemek gerekirse, çekme istekleri, bir yazılım geliştiricisi tarafından yarattıkları değişiklikleri ana projeyle birleştirmek için oluşturulan isteklerdir. Bu değişiklikleri gözden geçirme sürecini içerir. Gözden geçirenler, geliştirilebileceğini düşündükleri her parçaya yorum ekleyebilir veya gereksiz olarak görebilirler.

Geri bildirim aldıktan sonra, içerik oluşturucu buna yanıt verebilir, bir tartışma oluşturabilir veya basitçe takip edebilir ve kodunu buna göre değiştirebilir.

Git sadece bir araçtır. Birçok farklı şekilde kullanabilirsiniz. Şu anda karşılaşabileceğiniz en popüler iki geliştirme stili Git akışı ve ana hat tabanlı geliştirmedir. Çoğu zaman, insanlar bu tarzlardan birine aşinadır ve diğerini ihmal edebilirler.

Her ikisine de daha yakından bakalım ve bunları nasıl ve ne zaman kullanmamız gerektiğini öğrenelim.

Git Akışı

Git akış geliştirme modelinde, ona katı erişimi olan bir ana geliştirme dalınız vardır. Genellikle develop dalı olarak adlandırılır.

Geliştiriciler bu ana daldan özellik dalları oluşturur ve bunlar üzerinde çalışır. Tamamlandıktan sonra, çekme istekleri oluştururlar. Çekme isteklerinde, diğer geliştiriciler değişiklikler hakkında yorum yapar ve genellikle oldukça uzun tartışmalar yapabilir.

Değişikliklerin nihai versiyonu üzerinde anlaşmak biraz zaman alır. Üzerinde mutabık kalındığında, çekme talebi kabul edilir ve ana dalla birleştirilir. Ana dalın serbest bırakılmak için yeterli olgunluğa ulaştığına karar verildikten sonra, nihai versiyonu hazırlamak için ayrı bir dal oluşturulur. Bu daldaki uygulama test edilir ve son kullanıcılara yayınlanmaya hazır olana kadar hata düzeltmeleri uygulanır. Bu yapıldıktan sonra, nihai ürünü master dalla birleştirir ve yayın sürümüyle etiketliyoruz. Bu arada, develop dalında yeni özellikler geliştirilebilir.

Aşağıda, genel bir iş akışını gösteren Git akış şemasını görebilirsiniz:

Git akışının avantajlarından biri sıkı kontroldür. Yalnızca yetkili geliştiriciler, değişiklikleri yakından inceledikten sonra onaylayabilir. Kod kalitesini garanti eder ve hataların erken ortadan kaldırılmasına yardımcı olur.

Ancak bunun da büyük bir dezavantaj olabileceğini unutmamalısınız. Yazılım geliştirmeyi yavaşlatan bir huni oluşturur. Öncelikli endişeniz hız ise, bu ciddi bir sorun olabilir. Ayrı ayrı geliştirilen özellikler, ana proje ile birleştirilmesi zor olabilecek uzun ömürlü şubeler oluşturabilir.

Dahası, çekme istekleri kod incelemesini yalnızca yeni koda odaklar. Koda bir bütün olarak bakmak ve onu bu şekilde geliştirmeye çalışmak yerine, yalnızca yeni yapılan değişiklikleri kontrol ederler. Bazı durumlarda, daha hızlı gerçekleştirmek için bir şeyler uygulamak her zaman mümkün olduğundan, erken optimizasyona yol açabilirler.

Ayrıca, çekme talepleri, lider geliştiricinin kelimenin tam anlamıyla her bir kod satırını yönettiği kapsamlı mikro yönetime yol açabilir. Güvenebileceğiniz deneyimli geliştiricileriniz varsa, bununla başa çıkabilirler, ancak zamanlarını ve becerilerini boşa harcıyor olabilirsiniz. Ayrıca geliştiricileri ciddi şekilde motive edebilir.

Daha büyük kuruluşlarda, çekme talepleri sırasında ofis politikaları başka bir endişe kaynağıdır. Çekme isteklerini onaylayan kişilerin, belirli geliştiricilerin kod tabanında herhangi bir değişiklik yapmasını bilerek engellemek için konumlarını kullanmaları düşünülebilir. Bunu, güven eksikliğinden dolayı yapabilirler, bazıları ise kişisel puanlarını belirlemek için konumlarını kötüye kullanabilir.

Git Akışı Artıları ve Eksileri

Gördüğünüz gibi, çekme istekleri yapmak her zaman en iyi seçim olmayabilir. Yalnızca uygun olan yerlerde kullanılmalıdırlar.

Git Akışı En İyi Ne Zaman Çalışır?

• Açık kaynaklı bir proje çalıştırdığınızda.
  Bu tarz açık kaynak dünyasından geliyor ve en iyi orada çalışıyor. Herkes katkıda bulunabileceğinden, tüm değişikliklere çok sıkı erişime sahip olmak istersiniz. Her bir kod satırını kontrol edebilmek istiyorsunuz çünkü açıkçası katkıda bulunan insanlara güvenemezsiniz. Genellikle bunlar ticari projeler değildir, bu nedenle geliştirme hızı bir endişe kaynağı değildir.

• Çok sayıda genç geliştiriciniz olduğunda.
  Çoğunlukla genç geliştiricilerle çalışıyorsanız, çalışmalarını yakından kontrol etmenin bir yolunu bulmak istersiniz. Onlara işleri nasıl daha verimli yapacaklarına dair birçok ipucu verebilir ve becerilerini daha hızlı geliştirmelerine yardımcı olabilirsiniz. Çekme isteklerini kabul eden kişiler, kod kalitesinin bozulmasını önlemek için yinelenen değişiklikler üzerinde sıkı denetime sahiptir.

  

• Yerleşik bir ürününüz olduğunda.
  Bu tarz, zaten başarılı bir ürününüz olduğunda da iyi oynuyor gibi görünüyor. Bu gibi durumlarda, odak noktası genellikle uygulama performansı ve yük yetenekleridir. Bu tür bir optimizasyon çok kesin değişiklikler gerektirir. Genellikle zaman bir kısıtlama değildir, bu nedenle bu tarz burada iyi çalışır. Dahası, büyük işletmeler bu tarz için çok uygundur. Milyonlarca dolarlık yatırımlarını bozmak istemedikleri için her değişikliği yakından kontrol etmeleri gerekiyor.

Git Akışı Ne Zaman Sorunlara Neden Olabilir?

• Yeni başladığınızda.
  Yeni başlıyorsanız, Git akışı size göre değil. Hızlı bir şekilde minimal uygulanabilir bir ürün yaratmak istemeniz olasıdır. Çekme istekleri yapmak, tüm ekibi önemli ölçüde yavaşlatan büyük bir darboğaz yaratır. Bunu göze alamazsın. Git akışındaki sorun, çekme isteklerinin çok zaman alabilmesidir. Bu şekilde hızlı bir gelişme sağlamak pek mümkün değil.

• Hızlı bir şekilde yinelemeniz gerektiğinde.
  Ürününüzün ilk sürümüne ulaştığınızda, müşterilerinizin ihtiyaçlarını karşılamak için büyük olasılıkla birkaç kez döndürmeniz gerekecektir. Yine, birden çok şube ve çekme talebi, geliştirme hızını önemli ölçüde azaltır ve bu gibi durumlarda tavsiye edilmez.

• Çoğunlukla kıdemli geliştiricilerle çalıştığınızda.
  Ekibiniz esas olarak birbirleriyle daha uzun süre çalışmış kıdemli geliştiricilerden oluşuyorsa, yukarıda bahsedilen çekme isteği mikro yönetimine gerçekten ihtiyacınız yoktur. Geliştiricilerinize güveniyorsunuz ve onların profesyonel olduklarını biliyorsunuz. Bırakın işlerini yapsınlar ve tüm Git akışı bürokrasisiyle onları yavaşlatmayın.

Trunk Tabanlı Geliştirme İş Akışı

Trunk tabanlı geliştirme modelinde, tüm geliştiriciler ona açık erişimle tek bir dal üzerinde çalışır. Genellikle sadece master daldır. Ona kod veriyorlar ve çalıştırıyorlar. Çok basit.

Bazı durumlarda, kısa ömürlü özellik dalları oluştururlar. Dallarındaki kod derlenip tüm testleri geçtiğinde, onu doğrudan master ile birleştirirler. Geliştirmenin gerçekten sürekli olmasını sağlar ve geliştiricilerin çözülmesi zor birleştirme çakışmaları oluşturmasını önler.

Şimdi gövde tabanlı geliştirme iş akışına bir göz atalım.

Böyle bir yaklaşımda kodu incelemenin tek yolu tam kaynak kodu incelemesi yapmaktır. Genellikle, uzun tartışmalar sınırlıdır. Kaynak kod tabanında neyin değiştirilmekte olduğu üzerinde hiç kimsenin katı bir kontrolü yoktur; bu nedenle uygulanabilir kod stilinin yerinde olması önemlidir. Bu tarzda çalışan geliştiriciler, kaynak kod kalitesini düşürmeyeceklerini bilmeniz için deneyimli olmalıdır.

Bu çalışma tarzı, deneyimli yazılım geliştiricilerden oluşan bir ekiple çalıştığınızda harika olabilir. Gereksiz bürokrasi olmadan hızlı bir şekilde yeni iyileştirmeler yapmalarını sağlar. Ayrıca, doğrudan master şubeye kod ekleyebildiklerinden, onlara güvendiğinizi de gösterir. Bu iş akışındaki geliştiriciler çok özerktir; doğrudan teslim ederler ve çalışan üründeki nihai sonuçlar üzerinde kontrol edilirler. Bu yöntemde kesinlikle çok daha az mikro yönetim ve ofis politikası olasılığı vardır.

Öte yandan, deneyimli bir ekibiniz yoksa veya herhangi bir nedenle onlara güvenmiyorsanız, bu yöntemi kullanmamalısınız - bunun yerine Git akışını seçmelisiniz. Sizi gereksiz endişelerden kurtaracaktır.

Trunk Tabanlı Geliştirmenin Artıları ve Eksileri

Maliyetin her iki tarafına da daha yakından bakalım - en iyi ve en kötü senaryolar.

Trunk Tabanlı Geliştirme En İyi Ne Zaman Çalışır?

• Yeni başladığınızda.
  Minimum uygulanabilir ürününüz üzerinde çalışıyorsanız, bu tarz sizin için idealdir. Minimum formalite ile maksimum geliştirme hızı sunar. Herhangi bir çekme talebi olmadığından geliştiriciler, ışık hızında yeni işlevler sunabilir. Sadece deneyimli programcıları işe aldığınızdan emin olun.

• Hızlı bir şekilde yinelemeniz gerektiğinde.
  Ürününüzün ilk versiyonuna ulaştığınızda ve müşterilerinizin farklı bir şey istediğini fark ettiğinizde, iki kere düşünmeyin ve yeni bir yöne dönmek için bu stili kullanın. Hala keşif aşamasındasınız ve ürününüzü olabildiğince hızlı değiştirebilmeniz gerekiyor.

• Çoğunlukla kıdemli geliştiricilerle çalıştığınızda.
  Ekibiniz ağırlıklı olarak kıdemli geliştiricilerden oluşuyorsa, onlara güvenmeli ve işlerini yapmalarına izin vermelisiniz. Bu iş akışı onlara ihtiyaç duydukları özerkliği verir ve mesleklerinde ustalıklarını kullanmalarını sağlar. Sadece onlara bir amaç verin (başarılacak görevler) ve ürününüzün nasıl büyüdüğünü izleyin.

Trunk Tabanlı Geliştirme Ne Zaman Sorunlara Neden Olabilir?

• Açık kaynaklı bir proje çalıştırdığınızda.
  Açık kaynaklı bir proje yürütüyorsanız Git akışı daha iyi bir seçenektir. Değişiklikler üzerinde çok sıkı kontrole ihtiyacınız var ve katkıda bulunanlara güvenemezsiniz. Sonuçta, herkes katkıda bulunabilir. Çevrimiçi troller dahil.

• Çok sayıda genç geliştiriciniz olduğunda.
  Çoğunlukla genç geliştiricileri işe alırsanız, yaptıklarını sıkı bir şekilde kontrol etmek daha iyi bir fikirdir. Sıkı çekme talepleri, becerilerini geliştirmelerine yardımcı olacak ve olası hataları daha hızlı bulacaktır.

• Ürün kurduğunuzda veya büyük ekipleri yönettiğinizde.
  Halihazırda başarılı bir ürününüz varsa veya büyük bir kuruluşta büyük ekipleri yönetiyorsanız, Git akışı daha iyi bir fikir olabilir. Milyonlarca dolar değerindeki köklü bir üründe olup bitenler üzerinde sıkı bir kontrole sahip olmak istiyorsunuz. Muhtemelen, uygulama performansı ve yük yetenekleri en önemli şeylerdir. Bu tür bir optimizasyon çok kesin değişiklikler gerektirir.

Doğru İş için Doğru Aracı Kullanın

Daha önce de söylediğim gibi Git sadece bir araçtır. Diğer tüm araçlar gibi, uygun şekilde kullanılması gerekir.

Git akışı, tüm değişiklikleri çekme istekleri aracılığıyla yönetir. Tüm değişikliklere sıkı erişim kontrolü sağlar. Açık kaynak projeleri, büyük işletmeler, yerleşik ürünleri olan şirketler veya deneyimsiz genç geliştiricilerden oluşan bir ekip için harikadır. Kaynak koduna neyin dahil edildiğini güvenle kontrol edebilirsiniz. Öte yandan, kapsamlı mikro yönetime, ofis politikalarını içeren anlaşmazlıklara ve önemli ölçüde daha yavaş gelişmeye yol açabilir.

Trunk tabanlı geliştirme, programcılara tam özerklik verir ve onlara ve yargılarına daha fazla inancı ifade eder. Kaynak koduna erişim ücretsizdir, bu nedenle ekibinize gerçekten güvenebilmeniz gerekir. Mükemmel yazılım geliştirme hızı sağlar ve süreçleri azaltır. Bu faktörler, yeni ürünler yaratırken veya mevcut bir uygulamayı tamamen yeni bir yöne döndürürken onu mükemmel kılar. Çoğunlukla deneyimli geliştiricilerle çalışıyorsanız harikalar yaratır.

Yine de, genç programcılarla veya tam olarak güvenmediğiniz kişilerle çalışıyorsanız, Git akışı çok daha iyi bir alternatiftir.

Bu bilgiyle donanmış olarak, projenize mükemmel şekilde uyan iş akışını seçebileceğinizi umuyorum.