1. Sürüm Yönetiminin aslında esas hedefi ve çıktısı
sağlıklı Sürüm Notlarıdır. Sürüm Notları bir yazılıma ait
işlerin (new feature & bug fix) ne zaman ve hangi
sürümde devreye alınacağını veya alındığını gösterir.
2. Sağlıklı bir Sürüm Notu hazırlamak için
öncelikle güzel bir araca ihtiyacımız var. Biz JIRA’yı
tercih ediyoruz.
3. Geliştirdiğimiz proje, ürün, uygulama vs. ile ilgili her
türlü konuyu (bug, task, new feature, improvement,
problem, support request, etc.) Issue Tracking Tool
üzerinden takip etmemiz gerekiyor.
4. Herhangi bir ortamda (DEV, TEST, PROD) uygulama
kullanılırken tespit edilen hatalar takip sistemine
girilirken (affect version) kullanılmalıdır. Bu sayede
hatanın hangi versiyonda ortaya çıktığı belli olacak ve
Sürüm Notlarında gözükecektir.
5. Bir hata çözüldüğünde veya bir istek
tamamlandığında bu işin hangi sürümle (fix version)
devreye alınacağı mutlaka İş Takip Aracı'nda
belirtilmelidir. Bu bilgi Sürüm Notlarının
hazırlanabilmesi için çok önemlidir.
Bu bilgileri kullanarak Sürüm Notlarını online olarak
takip edebiliriz.
6. Sürüm Yönetimi açısından en önemli konulardan biri
de kodlar'daki değişikliklerin sürüm kapsamında yapılıp
yapılmadığının kontrolüdür. Hiç kimse kapsam dışındaki
bir değişikliğin production ortamına alınmasını istemez.
Bunun önlemenin en iyi yolu Versiyon Kontrol
Araçlarındaki değişikliklerin, İş Takip Araçlarındaki
konularla ilişkilendirilmesidir.
7. Eğer developer'lar her check-in yaptıklarında, kod'un
içerisinde ilgili yere bu değişikliğin nedeni olan
IssueKey'i comment olarak yazarlarsa, JIRA ve CVS'in
entegre olduğu durumlarda bu değişiklik JIRA'daki ilgili
issue ile ilişkilendirilir ve raporlanır. Biz git üzerinden
branch sistemi ile gitmeyi tercih ediyoruz. Bunun
avantajları ve dez avantajları vardır.
8. Bir sürüm kapsamındaki işlerin bağımlılıklarının takip
edilmesi çok önemlidir. Örneğin 2.1.7 sürümünde
çıkartacağınız bir iyileştirmenin bir parçası 2.2.0
sürümde çıkartmayı planladığınız bir iyileştirmeye
bağımlı ise Sürüm Planını tekrardan yapmanız
gerekecektir. Burada esas sorun planın tekrar yapılması
değil bu bağımlılığın önceden ve kolayca tespit
edilebilmesidir.
9. Her developer ve QA'in production ortamının
replikası olan testboxları var.
10. Developerlar test edilmeye göndermeden önce
yazdıkları kodu jiradaki issue numarasını verdikleri
branchlere merge ediyorlar ve testboxlarına deploy
edip kontrol ediyorlar.
11. Teste gelen işler masterla merge edilip QA
tarafından testboxlara deploy edip sadece yapılan kod
değişikliğini test ediyorlar.
12. Testten geçen issue'ların branchleri dev-ops ekibi
tarafından kendi yazdığımız bir scriptle birleştirilip fix
versionları ekleniyor.
Çıkan conflictler dev-ops ekibinin takibinde conflict
çıkan branchin developer'ı tarafından düzeltiliyor.
Bu işlemler tamamlandıktan sonra release paketi devops ekibi tarafından testbox'a deploy ediliyor ve eğer
varsa operation document'i uygulanıyor (SQL,curl etc.)
13. QA otomasyon ekibi otomatik testleri bu paket
üzerinde çalıştırıyor. Ve Qa manuel ekibi system
checklisti uyguluyor. Bu aşamaya pre-production testi
diyoruz.
Testten geçen paket onaylanıp dev-ops ekibine
gönderiliyor .
14. Dev-ops tarafından release rename ediliyor ve
system-admin ekibine deployment approval statusuna
gönderiliyor.
