Symphony Branch Model · Baris Gece
Yaptığımız araştırmalar sonucunda GIT DVCS(dağıtık versiyon kontrol sistemini) kullanan firmalar genel olarak aşağıdaki 3 Branch Modeli üzerinden ilerlemektedirler.
Son trendler incelendiğinde, DevOps kültürünü benimsemiş ve bu kültürde yaşayabilen firmalar Trunk Based Development modeli ile ilerlemektedirler. Trunk Based Development remote repository üzerindeki branch yapısını reddeder. Çünkü, iyi yönetilemeyen branch'ler daha sonraki süreçlerde repository üzerinde branch çöplüğüne, yapılan her push sonrası Merge Conflict'lere ve hangi branch'te ne bulunduğunun bilinmemesi gibi sonuçlara sebep olmaktadır. Ek olarak yaşanan her Merge Conflict, ürünün müsteriye teslim sürecini direk olarak etkilemekte ve yavaşlatmaktadır. Bu konu hakkında daha detaylı bilgilere Dave Farley'in yazmış olduğu aşağıdaki makalelerden ulaşabilirsiniz.
Fakat uygulayacak olduğunuz branch yapısını bulunduğunuz firmanın kültürü ve alışkanlıklarıyla birlikte modellemek gerekmektedir, aksi takdirde X firmasında çok başarılı olan bir model Y firmasında hüsranla sonuçlanabilmektedir. Bizde Symphony ekibi olarak içinde olduğumuz yeni dönüşüm sürecinide kendi kültür ve alışkanlıklarımızla SymphonyFlow branch modelini oluşturduk.
Aşağıda uyguladığımız SymphonyFlow Branch Modelini bulabilirsiniz.
Branch sayısı arttıkça uygulayacak olduğunuz kural setleride artmaktadır. Trunk Based Development'ı yapısı gereği güçlü kılan başka bir yanıda kısıtlayıcı fiziksel kuralların olmamasıdır. Burada belli mantıksal kurallar çerçevesinde Master Branch'in sağlığı geliştiriceye bırakılır. Fakat, dönüşüm sürecinde olan bizim gibi firmaların bu yapıda ilerlemesi daha ağır sonuçlara sebep olabilmektedir. Bu yüzden SymphonyFlow branch modelini yukarıdaki gibi tasarladık. Bu yapıda 2 ana branch bulunmaktadır. Bunlar;
Ek olarak 3 adet yardımcı(destek) branch bulunmaktadır. Bunlar;
Bu branchlerin aralarındaki ilişkiler aşağıdaki gibidir.
Master Branch safezone olarak adlandırdığımız branch'dir. Master Branch üzerinde sadece canlı sistem üzerinde koşan kodlar bulunmakta ve bu branch üzerinde sadece CI Automation araçları ile işlem yapılabilmektedir.
Hotfix Branches sadece Master Branch üzerinden yaratılabilir. Canlı ortamda yaşanan hata Hotfix Branch üzerinde çözülüp testler gerçekleştikten sonra Canlı sisteme yeni versiyon Hotfix üzerinden çıkılır. İşlem sonrası sistem otomatik olarak Master ve As is Release branch'i Hotfix branch'le merge eder.
Release Branches projemizde her sprint'i bir release olarak değerlendirdiğimizden, her sprint sonrası Master Branch üzerinden yeni bir Release Branch oluşturulur. Sprint sonrası oluşan karalı sürüm yine Release Branch üzerinden canlı ortama çıkılır ve otomatik olarak Master Branch ile Merge edilir.
Feature Branches sprint sonrası karar verilen Yeni Feature'lar için branch sprint için oluşturulan Release Branch üzerinden yaratılır ve geliştirme sonrası ekipteki en az bir kişinin Review'ından geçerek Pull Request açılır. Proje Yöneticisi tarafından onaylandıktan sonra ilgili Feature Release Branch'i Merge olur.
Bugfix Branches sprint sonrası çözülmesine karar verilen Bug'lar için branch sprint için oluşturulan Release Branch üzerinden yaratılır ve geliştirme sonrası ekipteki en az bir kişinin Review'ından geçerek Pull Request açılır. Proje Yöneticisi tarafından onaylandıktan sonra ilgili Bugfix Release Branch'i Merge olur.
Yukarıda belirlenen kuralları otomatik, hızlı ve en az hataya sebep olacak şekilde uygulaya bilmek için JIRA ve BitBucket kullanarak ilerlenmiştir.
BitBucker ve Jira Üzerinde Yapılan İşlemler
Release Package adında yeni bir Issue Type oluşturudu.
Release Packege sprint sonrası planlı olarak canlı sisteme çıkacak olduğumuz yeni özellik ve hata çözümlerinin linklendiği bir issue olarak düşünebilirsiniz.
BitBucket - Jira entegrasyonu ile ilgili projenin Jira Issue'ları üzerinden, yine ilgili projenin repository'sinde ilişkili branch açılması sağlandı.
BitBucket üzerinde Project Permission ve Branch Permission kullanılarak yukarıda bahsedilen kısıtlamalar getirildi.
Aşağıda uyguladığımız örnek bir akışı bulabilirsiniz.
Her sprint sonrası bir adet Release Package tipinde Issue oluşturulur.
Release Package Issue üzerinden Create Branch'e tıklanarak BitBucket üzerinde o sprit ile ilişkili bir release- branch'i oluşturur.
Not-1: Açılan ekrandaki Repository alanıda ilişkili Proje Repository seçilmeli
Not-2: Oluşturulan release- branch'i master branch üzerinden türetilmelidir.
Not-3: Oluşturulan release- branch'i için anlaşılır isimlendirme yapılmalı.
Yukarıdaki işlem tamamlandıktan sonra aşağıdaki gibi BitBucket üzerinde master'dan türemiş yeni bir release- branch'i oluşmuş olacak.
Not: Aşağıdaki şekilde BitBucket üzerinde branch-permission ayarı yapıldıktan sonra ilgili Repository üzerinde sadece yetki verilen kişi ve sistemler yeni branch oluşturabilir. Bizim yapımızda Release* branch sadece proje yönetici tarafından açılabilir.
Yetkisi olmayan kullanıcı release- branch oluşturmak istediğinde hata alacaktır.
Release branch yaratıldıktan sonra uygulama geliştiren kişiler üzerlerindeki Bug, Feature ve HotFix tipinde açılmış issue'lar üzerinde Create Branch diyerek kendilerine yeni branchler oluşturabilirler
Not-1 Açılan her Bug, Feature ve HotFix issue tiplerinde kesinlikle FixVersion girilmiş olmalıdır. Aksi takdirde Issue Links kısmında ilişkili Release Package gelmez.
Not-2 Oluşturulacak olan branch kesinlikle ilişkili olduğu release- branch üzerinden açılmalı. Branch Type issue tipine göre seçilmeli.
Not-3 Branch adı feature-JIRAID şeklinde olabilir.
Branch yaratıldıktan sonra bitbucket üzerindeki son durum aşağıdaki gibidir. Ek olarak branch üzerinde ilişkili Jira Issue ID'de bulunmaktadır.
Bu şekilde ilerlendiğinde ilişkili Jira Issue üzerinden yapılan commit ve merge işlemleri rahat şekilde takip edilir olmakatadır.
Git Commit Jira Issue ID