Sürüm Yönetimi Pratikleri - II

Bir önceki blogumda Sürüm Yönetimi pratiklerine bir giriş yapmış, Sürüm Numarasının Runtime'da kullanımına (Version.class) değinmiştim. Bu yazıda ise diğer kullanım şekillerinden bahsedeceğim.

Version Control Tool

Hangi Versiyon Kontrol aracını (CVS, SVN, ClearCase, StarTeam, vs.) kullanırsanız kullanın tüm bu araçlarda mutlaka bir etiketleme (Tag, Label, vs.) sistemi vardır. Sürümü oluştururken bir önceki blog 'da bahsettiğim Sürüm Numarasını kullanarak, sürüm kapsamına giren java, jsp, xml, html, sql, vs. tüm dosyalara mutlaka etiket atılmalıdır. gibi

Etiketleme işleminde kullanılan Sürüm Numarası genelde en sade formattadır.

Örnek: TestProject_2.1.2_15022006 , TestProject_2.1.2 veya 2.1.2 gibi.

Etiketleme işleminde baz alınacak versiyonların seçimi için 3 yöntemden birini seçebilirsiniz:

1) Development Baseline (Latest Version) Bu yöntemde sürüm zamanı geldiğinde Development Baseline 'ındaki kodların son versiyonlarına etiket atılır. Sürüme dahil edilmek istenmeyen versiyonlar etiketleme öncesi geri alınarak sürüme çıkması engellenir. Bu yöntem genelde bir dosya üzerinde birden fazla kişinin çalışmadığı, küçük takımlardan oluşan, yapılan değişikliklerin kısa sürede sürümlere dahil edildiği projelerde tercih edilir. Bu yöntemde eğer ekip üyeleri dosyalarına ve değişikliklerine hakim ise çok sorun yaşanmaz ama gene de diğerlerine göre en riskli yöntemdir. Etiketleme işlemi tamamlandıktan sonra, etiketlenen dosyalar Production Baseline 'ına transfer edilir.

2) Production Baseline (Latest Version) Bu yöntemde developer'lar sürüme dahil olmasını istedikleri dosyaları kendileri manuel olarak Production Baseline (branch) 'ına transfer ederler. Sürüm zamanı geldiğinde bu baseline 'deki kodların son versiyonlarına etiketleme yapılır. Bu yöntem diğerlerine göre en güvenli olanıdır. Yanlış kodların gönderilmesi gibi hataların önüne bu yöntemle geçilmiş olur. Bu yöntemin en büyük handikapı ise developer'ların sık sık, gerçekten sürüme dahil olması gereken dosyaları bu baseline' a transfer etmeyi unutmalarıdır.

3) Development Baseline (Release Label) Bu yöntemde ise developerlar Development Baseline 'ında sürüme dahil olmasını istedikleri dosyalarının ilgili versiyonlarına TO_RELEASE, TO_TEST, TO_PROD vs. gibi önceden belirlenmiş sabit etiketler atarlar. (ya da kaydırırlar) Sürüm zamanı geldiğinde Sürüm Yönetimi, üzerinde bu sabit etiketten bulunan dosyaların ilgili versiyonlarını sürüm numarası ile etiketler. Bu yöntemde genelde ayrıca bir Production Baseline kullanılmaz.

Bu etiketleme işlemini ister ant yardımıyla otomatik, isterseniz de manual yapabilirsiniz:

Manual Etiketleme çok sık sürümün çıkarılmadığı projelerde en çok tercih edilen yöntemdir. Bu işlem developerlar veya Sürüm Yöneticisi tarafından gerçekleştirilebilir. Dikkat edilmesi gereken nokta ise etiketleme işleminin daha evvelden Sürüm Yönetimi tarafından yayınlanmış tarihte ve saatte yapılmasıdır. Özellikle derleme ve paketleme işlemi belli bir saatte otomatik olarak başlayacaksa zamanlama çok daha önemli olacaktır.

Otomatik Etiketleme genelde periyodik olarak çok sık sürüm çıkarılan projelerde tercih edilen bir yöntemdir. Otomatik etiketleme işlemi, derleme ve paketleme işleminin bir ön işi olarak birlikte gerçekleştirilir. Otomatik yapılan işlemlerde treni kaçıran :) developer sayısı çok olsa da, sürümler sık çıktığı için bir sonraki sefere yetişilerek bu durum kolayca telafi edilebilir.

Genelde developer ve testçi sayısının fazla olduğu büyük projelerde periyodik olarak sürüm zamanları ve numaraları önceden belirlenir ve yayınlanır. Ayrıca bu sürüm numaraları, test sürümleri baz alınarak oluşturulur. Küçük ekiplerin geliştirdiği ve sürümlerin çok sık çıkmadığı projelerde ise sürüm numaları production sürümleri baz alınarak oluşturulur.

Sürüm Yönetimi hakkında konuşacağımız daha çok şey var, bir sonraki blogda görüşmek üzere :)

Sürüm Yönetimi Pratikleri - I

İster kurumsal bir firmanın yazılım departmanı olsun, isterse küçük bir yazılım evi olsun. Yazılım geliştiren her organizasyonun mutlaka bir Sürüm Yönetimi (Release Management) olmalı. Maalesef çoğu kişi tarafından Sürüm Yönetimi deyince akla sadece, program kaynak kodlarının CVS, ClearCase gibi Versiyon Kontrol Sistemlerinde (SCM) saklanması geliyor. Halbuki Sürüm Yönetimi Müşteriyi, Analizi, Tasarımı, Kodlamayı, Test'i ve Deploymentı da içine alan daha kompleks ve uzun bir süreç.

Bu yüzden birkaç blog ile Sürüm Yönetimini anlatmamız mümkün değil. Bunun yerine niyeim işin teoriğine pek girmeden, büyüklüğü ve türü ne olursa olsun her türlü yazılım projelerinde kullanabileceğiniz Süreç Yönetiminin pratiklerinden ve püf noktalarında bahsetmek. Birazdan bahsedeceğim konular daha evvel uyguladığımız ve büyük faydasını gördüğümüz pratiklerdir. Vereceğim örnekler her ne kadar Java uygulamalarına ait olsa da benzer mantıkla diğer tüm programlama dillerine de uyarlanabilir.

Bu konuyla ilk defa haşır-neşir olacakların, birazdan çok bahsi geçecek bazı araçlar ve metodolojiler hakkında altyapı oluşturmaları gerekiyor ki Süreç Yönetimi pratiklerini anlamaları ve kendi projelerinde uygulamaları kolay olsun. Bu yüzden lütfen öncelikle aşağıdaki linklere bir göz atalım:

• What is Release Management ?
• What is Apache Ant ?
• What is Continuous Integration ?
• What is Cruise Control ?
• What is Version Control ?
• What is Bug & Issue Tracking ?

Sürüm Numarası

Sürüm Yönetiminin temel yapı taşı Sürüm Numarasıdır. Bu yüzden bir projeye başlamadan evvel Sürüm Numarası'nın hangi formatta olacağını, bu numarayı nasıl (manual/automatic) üreteceğimizi, farklı ortamlar (Development, Test, Production, vs.) için nasıl farklılaştıracağımız belirlememiz gerekiyor.

Eğer çok sık (2-3 günde bir) sürüm/deployment yapılan bir projenin Sürüm Yönetimini yapacaksanız Sürüm Numarası'nı olabildiğince detaylı bilgi içerecek şekilde tasarlayın. Eğer sürümleriniz arasında uzun süreler var ise Sürüm Numarasının çok detaylı olmasına gerek yok.

Ben genelde kendime Açık Kaynak dünyasını örnek aldığım için bu konuda da yaklaşık 2-3 ayda bir sürüm çıkaran JBoss'u örnek vereceğim:

JBoss Product Version Conventions

Product versions follow this format X.YY.ZZ.Q* (i.e. 1.2.3.GA, 1.2.3.CR1, 1.2.3.Alpha1-20060205091502)

X signifies major version related to production release. This is a number.

YY signifies minor version with minor feature changes or additions (use of even numbers is preferred...3.0, 3.2, 3.4, etc.). This is a number.

ZZ signifies patches and bug fixes. Minor features that do not introduce backward compatibility issues are ok. This is a number.

Q* is an alpha-numeric qualifier. The prefix of the qualifier needs to match the qualifier conventions listed below to ensure that versions can be compared consistently in terms of version ordering.

Major versions are usually developed in multiple iterations. Each iteration concludes with an intermediate version release. Intermediate versions are annotated with appropriate suffixes. This shows the progression of release versions. A given release may not have all stages of releases shown here.

Yukarıdaki örnekte görüldüğü gibi genelde Sürüm Numaralarında 3 veya 4 basamaklı "." işareti ile biribirinden ayrılmış numaralar kullanılır. Bu numaralar her zaman, atlama yapmadan sırayla arttırılır. X genelde projeniz büyük yapısal veya fonksiyonel değişiklik var ise arttırılır. YY ise genelde production ortamına planlı yeni özelliklerin alındığı sürümlerde arttırılır. ZZ genelde test veya prod ortamlarında alınan bugfix ve improvement'lar için arttırılır. Q ise Build Number diye tabir edilen özellikle development ortamları gibi çok sık çıkarılan sürümleri biribirinden ayırmak için kullanılan bir numaradır.

Bu bilgiler ışığında projelerinizin büyüklüğüne ve sürüm çıkarma sıklığına göre kullanabileceğiniz bazı numaralandırma formatları şunlar:

• [Project_Name]_X.YY.ZZ --> TestProject_2.1.2
• [Project_Name]_X.YY.ZZ_[Date] --> TestProject_2.1.2_15022006
• [Project_Name]_X.YY.ZZ_[Date]_[Time] --> TestProject_2.1.2_15022006_1300
• [Project_Name]_X.YY.ZZ_[Date]_[Time]_[Build Number] --> TestProject_2.1.2_15022006_1300_[114]
• [Project_Name]_X.YY.ZZ_[Date]_[Time]_[Environment]_[Build Number] --> TestProject_2.1.2_[Test]_15022006_1300_[114]

Sürüm Numarası formatına karar verdiğimize göre bu sürüm numarasını nerelerde kullanacağımıza da karar vermemiz gerekiyor. Edindiğim tecrübeler ışığında söyleyebilirim ki "Biz Sürüm Yönetimi yapıyoruz" diyebilmeniz için aşağıdaki 3 ortama Sürüm Numaralarını senkronize bir şekilde girmeniz gerekiyor.

• Runtime (Version.class)
• Version Control Tool (Label, Version, Tag, etc.)
• Issue & Bug Tracking Tool (Version)

Runtime (Version.class)

Sürüm Yönetimi yaptığını düşünen organizasyonların yaptığı en büyük hatalardan biri de, versiyon bilgisini deploy ettirdikleri kodların içine bir yere kaydetmemeleridir. İster bir class içerisinde, isterse bir property dosyası içerisinde olsun Sürüm Numarası mutlaka derlediğiniz paketin içinde bulunmalıdır. Peki bunun bize ne yararı olur:

• Deployment hatalarının önceden tespiti. Eğer derlediğiniz uygulamaları adminler tarafından manual olarak yapılıyorsa, yanlış paketin kopyalanması, cache'in temizlenmemesi, vs. gibi hataları paketinizin içindeki Sürüm Bilgisi sayesinde hemen farkedebilirsiniz.
• Tespit edilen bugların sürüm bazında raporlanması. Test elemanları buldukları hataları Issue Tracking Tool 'unuza girerken, hatanın ortaya çıktığı sürüm numarasını bu bilgi sayesinde tespit edeceklerdir. Hangi sürümde ne kadar hatanın yakalandığı bilgisi Sürüm Yöneteminin en önemli çıktılarından birisidir.

Sürüm Bilgisi genelde ya jar dosyaları içerisindeki MANIFEST dosyalarında, ya property dosyalarında ya da sembolik bir java dosyası içerisinde saklanır. Ben genelde Version.class isminde bir java dosyasında saklamayı tercih ediyorum. Sürüm bilgisini uygulamaların içerisine 2 yöntemden biri kullanarak yerleştirilebilir.

a) Manuel olarak Konfigürasyon Yöneticinizden veya bir developer'dan her sürüm çıkışı öncesi, önceden yayınladığınız Sürüm Numarasını formatını sizin belirlediğiniz bir Version.class'ı içerisine güncellemesini isteyebilirsiniz. Bu yöntem hataya, unutkanlığa çok açık olduğu için benim çok tercih ettiğim bir yöntem değildir. Fakat 2-3 haftada bir gibi uzun aralıklarla sürüm çıkartıyorsanız bu işi manual yapmakta hiç bir sakınca yok.

Örnek bir Version.class

package com.blogspot.mustafatan.testproject;

public class Version {
private static String version = "TestProject_2.1.2_15022006";

public static String getVersion() {
return version;
}
}

b) Otomatik olarak Apache Ant 'ı kullanarak hem uygulamanızı derleyip, hem de bu sırada sürüm numarası oluşturup derlediğiniz paket içerisine yerleştirebilirsiniz. Bu sayede kullanıcı hatalarından kaynaklanabilecek versiyonlama hatalarını engelleyebilir, hem de çok daha detaylı bilgi içeren bir sürüm numarası üretebilirsiniz. Bu işlem için Ant'ın Copy, Javac, BuildNumber, Replace gibi meşhur task'larından bol bol yararlanabilirsiniz.

Örnek Ant Task'ları:

<buildnumber file="buildNumbers/TestProject.number"/>

<tstamp>
<format property="BUILD_TIME" pattern="ddMMyyyy-HHmm" locale="en"/>
</tstamp>

<property name="build.version" value="TestProject_${release.number}_${BUILD_TIME}_Development_${build.number}"/>

Sürüm numaralarını bir şekilde oluşturduğumuza göre geriye bir tek bu numaranın son kullanıcının kolayca ulaşabileceği veya görebileceği şekilde ekranlarda gösterilmesi kalıyor. Örneğin Internet Explorer menüsünde Help -> About Internet Explorer sekmesine tıkladığınızda Browser' ınızın hangi versiyonda olduğunu rahatlıkla görebilirsiniz. Benzer şekilde siz de uygulamanızın sürüm numarasını, ana menüde kullanıcılarınızın rahatça görebileceği bir yerde gösterebilirsiniz.

Devamı için: Sürüm Yönetimi Pratikleri - II

Videos about JIRA

Beni yakından tanıyanlar ya da yazılarımı düzenli takip edenler JIRA 'yı ve Confluence 'u ne kadar sevdiğimi ve bu ürünlerin geliştiren Atlassian firmasına ne kadar hayranlık duyduğumu iyi bilirler. Zaman zaman arkadaşlarım bana "Ne var bu kadar bu elemanlarda" diye soruyorlar.

Vakit ayırıp aşağıdaki 2-3 dakikalık youtube video'larını izlerseniz hiç JIRA veya Confluence kullanmamış olsanız bile bana hak vereceksiniz.

A look at award winning company Atlassian
Ali Moore speaks with Michael Cannon-Brookes
Atlassian Software Systems
A Day with Confluence
Mission: Atlassian
Mike Cannon-Brookes

Top 20 most popular Open Source programs in 2006

Yeni bir yıla başladığımızda birileri mutlaka geçen yılın "en" leri ile ilgili listeler yayınlıyor. Aşağıda açık kaynak uygulamalar ile ilgili bir liste daha mevcut. Gerçekten içlerinde benim de ilk defa duyduklarım mevcut. Umarım size de bir faydası olur:

Those were the top most popular open source software in 2006 and some of them will stay popular for the years to come. (File Sharing not included). If you’d like to see some other popular open source software, you can visit OpenSourceWindows.org.

1. 7-Zip - file compression + 7Zip Portable
2. Abiword - create word documents + Abi Portable
3. Audacity - sound editing and effects + Audacity Portable
4. Blender 3D - 3D modeling and animation + Blender Portable
5. ClamWin - antivirus and antispyware scanner + ClamWin Portable
6. Eraser - erases your data securely + Eraser Portable
7. FileZilla - ftp client + FileZilla Portable
8. Firefox - browser + Firefox Portable
9. Gaim - instant messenger + Gaim Portable
10. Ganttproject - scheduling , resource management, calendaring
11. Gimp - GimpShop - image manipulation + Gimp Portable
12. Media Portal - media center
13. NVU - html editor + NVU Portable
14. OpenOffice.org - office suite + Open Office.org Portable
15. PDFCreator - create PDF files
16. RSSOwl - rss reader
17. TaskSwitchXP - advanced task management utility
18. Thunderbird - e-mail client + Thunderbird Portable
19. VLC Media Player - media player + VLC Portable
20. WebHTTrack - web site copier

Kaynak : http://www.carolsvault.com/top-20-most-popular-open-source-programs-in-2006/

Open Source Catalogue 2007

Optaros geçenlerde 140.000 bin açık kaynak uygulama içerisinden, kurumsal ve ticari anlamda kullanılabilecek 260 tanesini seçip müthiş bir rapor hazırlamış. Ben açıkçası bu kataloğun uzunu yıllar open-source ürünlerin seçiminde kaynak olarak kullanılacağını düşünüyorum. Aşağıda rapor hakkında özet bilgi bulabilirsiniz. Open-source ürünleri hala çoluk çocuk işi olarak görenlere ithaf edilmiştir :)

Katalog'te yer alan uygulamalar şu kriterlere göre değerlendirilmiş:

• Functionality
• Community
• Maturity
• Trend
• ER-Rating
• Version
• Description
• License
• Support
  

“ER” therefore stands for “Enterprise Readiness” and describes how capable an open source with the needs and requirements of midsize and large enterprises and organizations.


© Copyright 2007. Some Rights Reserved. This work is licensed under a Creative Commons Attribution 2.5 License

Bu uygulamalar da aşağıdaki başlıklarda katagorize edilmiş:

Operating Systems and Infrastructure

• Operating Systems (Server & Client)
• Graphical User Interfaces (Client)
• Communication Infrastructure
• Security
• Web Servers
• Systems Management and Operations
• Miscellaneous

Application Development and Infrastructure

• Databases and file systems
• Application servers
• Portal servers
• Programming languages
• Frameworks
• Components for application development
• Development and test environments
• Business process and workflow management
• Web services
• Middleware and enterprise integration
• SOA (Service Oriented Architecture)
• Rules engines
• ETL, data management and transformation
• Search machines

Infrastructure Solutions

• Collaboration/groupware/communication
• Enterprise Content Management (Document Management, Web Content Management)
• Identity & Access Management
• VOIP (Voice over IP) and Telephony

Business Applications

• CRM, ERP and eCommerce
• Analytics, Reporting and Datawarehousing
• Knowledge Management and eLearning
• Office and client side business solutions

Raporun tamamını ister ücretsiz üye olarak optaros.com 'dan, ya da bu linkten Optaros_Open_Source_Catalog_2007_v1_1 direk indirebilirsiniz.

İyi okumalar.