More Related Content
Similar to Release Management (20)
Release Management
- 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.
- 15.  Deployment yapıldıktan sonra QA release notes'u yayınlıyor. Post-production testi yapılıp issuelar kapatılıyor. Karşılaşılan buglar affected version eklenerek jiraya açılıyor.