Sürüm Yönetimi Pratikleri - III
Sürüm Yönetiminde en önemli konulardan biri de Hata ve İstek Takip araçlarıdır. (Issue Tracking Tools) Maalesef ülkemizde hala birçok yazılım evi ve departmanı bu takip işini e-mail veya telefonla yapmaktadır.
Doğal olarak bu firmalar yazılım yaşam döngüsü boyunca ortaya çıkan işleri düzgünce kayıt altına alamadıkları için takip edememekte, takip edemedikleri bir ürünün de Sürüm Yönetimini yapamamaktadırlar.
Bazı firmaların yaptığı diğer bir yanlış iş ise farklı talep tipleri için farklı araçlar kullanmalarıdır. Eğer hataların (bugs) takibi için ayrı bir araç, yeni iş istekleri için ayrı bir araç kullanılırsa sağlıklı bir Sürüm Yönetimi yapmak zorlaşır.
Bu yazımda Sürüm Yönetimi için nasıl bir İş Takip Sistemi'ne ihtiyacımız olduğundan ve bu iş için kullanacağımız araçtan beklentilerimizi ortaya koymaya çalışacağım.
a) Release Notes (Sürüm Notları)
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.
1) Issue Tracking Tool : Sağlıklı bir Sürüm Notu hazırlamak için öncelikle JIRA gibi güzel bir araca ihtiyacımız var. (Neden JIRA? sorusu için ayrı bir blog hazırlıyorum)
2) Issues : Geliştirdiğimiz proje, ürün, uygulama vs. ile ilgili her türlü konuyu (bug, task, new feature, improvement, problem, support request, etc.) İş Takip Arac'ı üzerinden takip etmemiz gerekiyor. (Örnek-I)
3) Affect Version(s) : Herhangi bir ortamda (DEV, TEST, PROD) uygulama kullanılırken tespit edilen hatalar takip sistemine girilirken mutlaka Sürüm Yönetimi Pratikleri - I başlıklı bloğumda bahsi geçen sürüm/versiyon numarası da (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.
4) Fix Version(s) : Bir hata çözüldüğünde veya bir istek tamamlandığında bu işin hangi sürümle (fix version ??? link) 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 örnek linkteki gibi Sürüm Notlarını online olarak takip edebiliriz: (JBoss Application Server Release Notes)
5) SCM and Issue Integration : 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 (CVS, SVN, ClearCase, vs.) değişikliklerin, İş Takip Araçlarındaki konularla ilişkilendirilmesidir.
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.
6) Issue Linking : 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.
Bu konu ile ilgili diğer bloglar:
Sürüm Yönetimi Pratikleri - I
Sürüm Yönetimi Pratikleri - II
Doğal olarak bu firmalar yazılım yaşam döngüsü boyunca ortaya çıkan işleri düzgünce kayıt altına alamadıkları için takip edememekte, takip edemedikleri bir ürünün de Sürüm Yönetimini yapamamaktadırlar.
Bazı firmaların yaptığı diğer bir yanlış iş ise farklı talep tipleri için farklı araçlar kullanmalarıdır. Eğer hataların (bugs) takibi için ayrı bir araç, yeni iş istekleri için ayrı bir araç kullanılırsa sağlıklı bir Sürüm Yönetimi yapmak zorlaşır.
Bu yazımda Sürüm Yönetimi için nasıl bir İş Takip Sistemi'ne ihtiyacımız olduğundan ve bu iş için kullanacağımız araçtan beklentilerimizi ortaya koymaya çalışacağım.
a) Release Notes (Sürüm Notları)
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.
1) Issue Tracking Tool : Sağlıklı bir Sürüm Notu hazırlamak için öncelikle JIRA gibi güzel bir araca ihtiyacımız var. (Neden JIRA? sorusu için ayrı bir blog hazırlıyorum)
2) Issues : Geliştirdiğimiz proje, ürün, uygulama vs. ile ilgili her türlü konuyu (bug, task, new feature, improvement, problem, support request, etc.) İş Takip Arac'ı üzerinden takip etmemiz gerekiyor. (Örnek-I)
3) Affect Version(s) : Herhangi bir ortamda (DEV, TEST, PROD) uygulama kullanılırken tespit edilen hatalar takip sistemine girilirken mutlaka Sürüm Yönetimi Pratikleri - I başlıklı bloğumda bahsi geçen sürüm/versiyon numarası da (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.
4) Fix Version(s) : Bir hata çözüldüğünde veya bir istek tamamlandığında bu işin hangi sürümle (fix version ??? link) 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 örnek linkteki gibi Sürüm Notlarını online olarak takip edebiliriz: (JBoss Application Server Release Notes)
5) SCM and Issue Integration : 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 (CVS, SVN, ClearCase, vs.) değişikliklerin, İş Takip Araçlarındaki konularla ilişkilendirilmesidir.
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.
6) Issue Linking : 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.
Bu konu ile ilgili diğer bloglar:
Sürüm Yönetimi Pratikleri - I
Sürüm Yönetimi Pratikleri - II
Etiketler: Affect Version, Fix Version, Issue Tracking, Release Management, Sürüm Yönetimi
Mustafa Tan tarafından gönderildi saat:
11:31 ÖS
7 Yorum:
Merhabalar Mustafa Bey;
Bitirme projemde Issue Tracking amaçlı bir ürün geliştirmeye çalıştığım için bu yazı dizisini dikkatli bir şekilde takip ediyorum.
Aklıma takılan bir nokta ise bu gibi araçların ve yönemlerin uygulanabilirliği konusunda. DEV. aşamasında kimler ne şekilde bunlara uyabiliyor yada uyuyor çok merak ediyorum. Öğrencilik döneminde benim bunu görme imkanım yok ama siz piyasada bu konuda deneyimlisiniz hatta aranan bir isimsiniz :)
Mesela 5. maddede geçen IssueKey'in comment olarak yazılması olayı: bu birazcık developer'a a müdaheleye giriyor ve buna gerçekten uyum sağlanabiliyor mu merak ediyorum.
Kolay gelsin
Selamlar İbrahim,
Öncelikle "Estağfurullah", öyle aranan bir isim olduğumuz yok. Naçizane birkaç şey varsa bildiğimiz, onları paylaşmaya çalışıyoruz.
Eğer geliştirilen proje 2-3 kişiden oluşuyor ise dediğin gibi bu tip ekstra işler developerlar için angarya ve gereksiz olabilir.
Ama eğer projede en az 15-20 kişi (Analyist,Developer,Tester, vs.) çalışıyorsa ve biribirine bağımlı çok sayıda bileşen aynı anda geliştiriliyorsa, değişikliklerin kayıt altına alınması çok önemlidir.
Yoksa ortaya Gerilla Development dediğimiz kaos ortamı ortaya çıkar. Bu durum her ne kadar Developer'ları rahatsız etmese de Proje Yönetimi açısından çok sıkıntılara yol açar.
Bu yüzden ekip ve bileşen sayısının fazla olduğu projelerde Sürüm Notları mutlaka hazırlanmalıdır. En sağlıklı Sürüm Notu da kod değişiklikleri ile ilişkilendirilendir.
Developer'lar muhakkak Yazılım Geliştirme Sürecinin en önemli elemanlarıdır ama hep onların keyfine uymaya çalışırsak yanarız :)
Biz bile bazen 2 kişi yaptığımız projelerde sistemli uygulama geliştirmemenin cezasını çekiyoruz.
Bazen diyorum demekki 15-20 kişi falan olsak vay halimize.
Dediğiniz gibi birşeyleri bastan düzgün yapmak , kayıt altına almak ilk başlarda angarya gibi görünse de gerekli birşey.
Hele ekipten ayrılmalar vs. oluyorsa yada kodların tekrar kullanımı gibi durumlar söz konusuysa dokümantasyon ve koda yorum ekleme şart.
Sürüm notunu kod değişikliği ile ilişkilendirmek olayın otomatize edilmesi açısından sanırım daha kolay olacaktır.
Kolay gelsin
Bu yorum yazar tarafından silindi.
Merhaba Mustafa abi, öncelikle ellerine sağlık, dertlere derman şekilde anlatmışssın bildiklerini:)
JIRA, ve sürüm yönetim pratikleri dizisini özellikle çok faydalı buldum. Bir şey merakımı cezbetti:
..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.
çalıştığım eski şirkette, kodları geliştirirken, kodun içine içgüdümsel olarak, kendim takip edebilmek amacıyla IssueKey'lerini not ediyordum. Bende kodlama sırasında saplantı derecesinde dökümantasyon arzusu var:) Ama bunların raporlanabileceği konusunda hiçbir fikrim yoktu.JIRA ve CVSin entegre olduğu durumlardamevzunu biraz açar mısın, yeni çalışmaya başladığım şirkette bu konuda çok eksiğimiz var ve bununla ilgili çalışmalara öncülük etmek istiyorum,ve bilgilerin benim için çok faydalı. Örneğin JIRA-SubVersion entegrasyonu gibi bir durumda geçerli mi, koda eklenen yorumlarla,resimdeki gibi bir raporlamayı nasıl elde ediyoruz,kaynak gösterebilir misin, teşekkürler!
Selam Perihan,
Çok teşekkkürler yorumların için.
JIRA kendi ekibinin veya müşterilerinin geliştirdiği pluginler ile tüm Versiyon Kontrol Sistemleriyle entegre olabiliyor.
Subversion açık kaynak dünyada en fazla kullanılan bir VCS olduğu için JIRA'da entegrasyon daha yetenekli. Aşağıda bu konuda işine yarayacak linkler mevcut:
JIRA-Subversion Plugin
JIRA-Subversion SlideShow
Commit Acceptance Plugin
Eğer şirketinizde JIRA ve Subversion kullanıyorsanız developer'ların tek yapmaları gereken issue-id'lerini kodlarında değişiklik yaptıkları yerlere comment olarak girmeleri. Ondan sonrasını JIRA ve Sürüm Yöneticisi halleder :)
Kolay Gelsin
Merhaba Mustafa Bey,
Subversion eklentisi ni outsource bir firma ile kullanma münkünmü kodları mutlaka kendi ortamımazdamı tutmamız gerekiyor.Entegrasyonunu biraz açabilir misiniz?
Yorum Gönder
Kaydol: Kayıt Yorumları [Atom]
<< Ana Sayfa