Git iş akışı

Jun 24, 2018 3 minute read

Çalıştığım projelerin çoğunda Git kullanıyoruz ve tüm sürüm çıkarma, projenin teste açılması, testten sonra production sürümünün hazırlanması, acil düzeltilmesi gereken işler olduğunda sürecin esnetilmesi ve bunun gibi birçok iş akışı Git reposu üzerinden yürüyor. Aşama aşama deneyimlerimi paylaşıyorum.

1. Aşama: Prototipe odaklan

Yeni bir projeye başlıyorsunuz, ekip henüz oluşturulmamış veya tek başınasınız ve derhal kabul edilebilir bir prototip1 hazırlamanız gerekiyor. Öncelikli kural, eğer hep aynı teknik araçları kullanıyorsanız bir öncekilerden iskelet yaratıp olduğu gibi yeni projeye aktarmanız. Çok az kuralımız var:

  • Ana branş master branşıdır ve bu branşın bir sorumlusu olur.
  • Kod iskeleti hazırlanıp basit bir yayına alma süreci oturtulana kadar sorumlu, master branşını yönetir.
  • Sorumlu, master branşına gönderilen değişiklikleri kontrol altına almak için isterse geliştiricilerin yetkilerini kısıtlar ve herkesin kendi branşında çalışmasını isteyebilir. Bu durumda geliştiriciler kendi dallarındaki çalışmaların master branşına yansıtılması için pull-request oluştururlar.

Geliştiriciler kendi branşlarını oluştururken ana branş olarak master branşını kullanırlar ve iş numarasıyla kendi branşlarını isimlendirebilirler:

# terminal
$ git checkout master
$ git checkout -b issue-692         # iş numarası 692
$ git checkout -b issue-698.1       # aynı iş için ikinci branş
$ git checkout -b issue-590-gokmen  # aynı iş için ikinci geliştirici
$ git checkout -b hotfix-499        # önemli bir hatayı düzelten branş

Bu aşamada tüm değişiklikler master branşına gider ve bu branştan bir prototip sürümü üretilir.

2. Aşama: Test ve Production’u ayır

Proje belli bir noktadan sonra artık ekip arasında veya şirket içinde denenmekten çıkıp müşteriye gösterilmeye başlayınca (eğer proje sizin değilse müşterinizin müşterisine), artık master branşında çok esnek olamamaya başlarsınız ve bu branşa bir değişiklik yapmadan önce başka bir branşta test etme ihtiyacı duyarsınız. Bu branşı develop diye isimlendirelim ve bu branşı master branşını baz alarak oluşturalım. Müşteriye asla develop branşından oluşturulmuş bir test sürümü gösterilmeyecek, sadece master branşından üretilecek production sürümünü kullanabilecek, ona erişebilecek.

Bu aşamada kurallar biraz değişecek:

  • Birinci aşamadan farklı olarak geliştirme branşımız master yerine develop olacak. Bundan sonra yeni branşlar develop üzerinden oluşturulacak.
  • Ancak buna tek istisna acil düzeltilmesi istenen hotfix branşları hariç. Hotfix branşları master branşı üzerinden oluşturulmaya devam edecek.
  • master branşının olduğu gibi develop branşının da bir sorumlusu olacak ve bu kişi aynı kişiler de olabilir, farklı kişiler de.
  • Bu iki branşın sorumlularının sorumlulukları birbirinden farklı olacak. develop branşının sorumlusu gözden geçirme ve test süreçlerinden sorumlu olacak, master branşının sorumlusu müşteri için stable bir sürüm çıkarmaktan.

Bu aşamada master branşına gönderilecek her değişiklikten sonra bir etiketleme yapılır:

# terminal
$ git checkout master
$ git merge --no-ff develop
$ git tag 5.6.0
$ git push --all
$ git push --tags

3. Aşama: Süreci otomatikleştir

Bu aşamaya kadar atladığım çok şey olmasına karşın kabaca süreç böyle işliyor. Fakat bir müddet sonra bazı işler sürekli tekrarlamaya başlayacak. Her seferinde sürüm numarasını düzelt, statik dosyaları oluştur ve gerekli yerlere taşı, çeviri dosyalarını güncelle, testleri çalıştır, hatta yeni sürümü belli bir tarih ve saatte yayınla, mail at, haber ver vesaire. Tüm bunları yapan bir script hazırlanabilir, Chef - Puppet - Ansible - Salt gibi otomasyon araçları kullanılabilir, onlarca Continuous Delivery, Continous Deployment, Continuous Integration gibi isimlendirmelerle bu süreçleri otomatikleştiren servisler var. Ben genellikle Bitbucket Pipelines kullanıyorum ve Git barındırma servisi olarak Bitbucket kullanıyorsanız kesinlikle denemelisiniz:

# bitbucket-pipelines.yml
image: python:3.5

pipelines:
  branches:
    master:
      - step:
         deployment: production
         script:
           - pip install fabric
           - fab production deploy
   develop:
     - step:
         deployment: test
         script:
           - pip install fabric
           - fab staging deploy

Artık bundan sonra projenin ihtiyaçlarına iş akışını arada bir gözden geçirmek, gerektiğinde güncellemek gerekir.


  1. MVP kısaltmasıyla bilinen Minimum Viable Product hakkında detaylı bilgiye buradan erişebilirsiniz. [return]