Bizim gözümüzden açık kaynak...

Yaklaşık bir hafta süren Mersin-Ankara tatilimden yeni döndüm, gayet güzel geçen bir aile ziyaretleri silsilesinden sonra insan açıkçası kendini pek bir toplamış olarak buluyor... Annenin yemekleri, kayınvalidenin börekleri ve sonu gelmez tek yönlü kalori alışverişi... En nihayetinde ayağımın tozuyla toplulukta ne var ne yok diye RSS'lerimi karıştırırken daha önceleri de canımı sıkan ve yeniden aklıma gelen bir konu oldu ve birkaç kelimeyi bu konu ile ilgili olarak yazma ihtiyacı hissettim.. Açık kaynak uygulamalara nasıl bakıyoruz?...

Açık Kaynak mı? Muhakkak bedavadır alalım...

Başlamadan önce Açık Kaynağın ne olduğunu/olmadığını anlamamız gerekiyor. Birincisi açık kaynak bedava olmaktan öte özgürlük ile daha çok bağdaşır.Yani kod geliştirirken, dağıtırken veya kullanırken özgür olabilmek açık kaynağın getirdiği fırsatlardır. Bunun getirdiği bir sürü avantaj vardır ki, bunlar için ayrı ayrı bir sürü yazı yazılmıştır. Yani bu yazıyı okumaya devam etmeden önce kafanızdaki açık kaynak=bedava eşitliğini bir süreliğine bırakmanız veya kafanızda biraz gerilere itelemeniz gerekiyor.

Hayır!! Açık Kaynak bu şirketin kapısından içeri adım atmayacak!! Bu kadar...

Zaman zaman etrafımızda, çalıştığımız yerde görürüz, Açık kaynak öcüymüş gibi bir tavır sergilenir.Bu tavır genellikle büyük ölçekli, kurumsal şirketlerde gösterilir. Ve en temelde iki sebebi (ya da öyle olduğu söylenir) vardır. İlki, güvenlik açıklarından dem vurulur.. İkincisi, destek ve dokümantasyon olmadığından yakınılır.

Öncelikle güvenlikten bahsedelim. Güvenlik açığı heryerde olabilir. Sisteminin mükemmel işlediğini düşünen bankalarda dahi güvenlik açıkları vardır. Her programda olduğu gibi açık kaynak uygulamalarda da güvenlik açıkları vardır. Ama uygulamada geliştirme/kullanma olarak katılımcı sayısı (ki bu açık kaynak topluluğu oluyor) fazla ise güvenlik açıkları zaman içerisinde bulunmuş ve düzeltilmiş/düzeltiliyordur. Eğer bundan yana çok şüphe duyuluyorsa kodlar nasıl olsa elimizde bakabiliriz değil mi? Bu noktada sanki kapalı kaynak kodlar biraz daha güvensiz gibi duruyor (içeride ne olup bittiğini bilmememiz açısından).

Destek ve dokümantasyona gelirsek, açık kaynak uygulamalar ölçeklerine bağlı olarak ücret karşılığında destek ve dokümantasyon sağlarlar. Tabi açık kaynağı bedava olarak niteleyip, ardından "nereden çıktı bu masraf" dersek afallarız tabi... Yukarıda da belirttiğim gibi açık kaynak her zaman bedava anlamına gelmez. JBoss lisans ücreti ödemezsiniz, ama JBoss ON için CPU başına bir lisans ücreti ödemek zorundasınızdır...

Nasıl yani açık kaynak hiç mi para kazanmıyor?

Açık kaynak uygulamalar Microsoft'un aksine lisans ücreti talep etmezler, bunun yerine dokümantasyon ve destek, zaman zaman da yardımcı entegre modüller asıl para getiren kısımlardır. Bununla ilgili Matt Asay'in Open Road'daki "Why Microsoft fears open source more than other proprietary vendors do" yazısı lisanslama ve dokümantasyon/destek arasındaki farkı ve bununla ilgili Microsoft ve Açık Kaynak arasındaki görüş farklılıklarını çok güzel anlatmış. Bir göz atmakta fayda var.

Eee iyiymiş bu açık kaynak

Açık kaynak trendi özellikle Sun CEO'su Jonathan Schwartz'ın katkıları ve vizyonu ile önce OpenOffice, sonra OpenSolaris ve ardından OpenJDK ile ivme kazandı. Sun'ın bu çabasına yakın zamanda IBM de OpenOffice.org topluluğuna katıldığını açıklayarak bir anlamda destek oldu. Sonra sırası ile birçok geniş ölçekli program trend değiştirip kodlarını açma kararı aldılar. Bunun en son örneği ise VMWare oldu. RedHat Fransız Eğitim Bakanlığı ve İsveç'te büyük ölçekte bir ilaç portali olan Fass.se'nin tüm server'larını (IBM ve Solaris'ten) RedHat Linux'e geçirdi.

Biz ne yapıyoruz peki?

Bu kadar yazıdan sonra etrafımda neler olduğunu bir toparlarsam, sırasıyla aşağıdaki sonuçları çıkarabilirim.

1.Hala açık kaynak bir uygulama gördüğümüzde kalitesiz ve ucube muamelesi yapıyoruz (Ve hatta lisanslı ürünlerin web sayfalarını inceleyip, aynı ürünün açık kaynak bir şekilde yapılamayacağına kendimizi inandırıyoruz)
2.Açık kaynağın bedava olmaktan öte paylaşımcı, sürekli geliştiren ve öğretici bir topluluk olduğunu anlamakta zorlanıyoruz.
3.Biz geliştirdiğimiz uygulamaları sanki dünyada kimse yazamazmış gibi, kodları kapalı ve lisanslı satmaya çalışıyoruz. (Tamam bu biraz fazla oldu, ama öyle)

Yukarıda yazdığım sonuçlar ile kimseyi suçlamıyorum..Sadece dünyanın yöneldiği trendi hala görmemekte ısrar ediyoruz. Benim vurgulamak istediğim nokta bu.

Hmm tabi bunları söyledikten sonra şunları da ekleyeyim, OpenOffice kullanıyorum, Sun Server'lar üzerine Solaris 9 yerine OpenSolaris veya RedHat kuralım diye her fırsatta ısrar ediyorum. Firefox favorim. Eclipse'ten daha iyi bir IDE tanımıyorum. Konfigürasyon Yöneticiliğini yaptığım projenin Kaynak Kodları Subversion'da (Starteam'den geçtik) tutuluyor. Sürüm sistemi Hudson/CruiseControl ve Ant kullanılarak yapılıyor. Vesaire, vesaire, vesaire...

Sistem-Sistemci-Alt Sistem üçgeninde yaşananlar...

Daha önce yazdığım Developer sadece kod mu yazar? adlı yazıda daha önceden kod yazma geçmişimin avantajlarını kullanarak piyasanın istediği, beklediği veya önem verdiği developer modeli ile ilgili tüyolar vermeye çalışmıştım. Ya da en azından benim gözümden faydalı developer nasıl olabiliri anlatmayı denemiştim.

Şimdi ise developer'ların kodlarını gerçek sisteme alırken karşılarına çıkan ve kodları gerçek sisteme çıkana kadar yanlarında yürüyen, daha sonra onlar kodlarını orada bırakıp ayrıldıklarında bu kodların asayişini , sistemle iyi ilişkiler içinde yaşamasını sağlayan, sorun olduğunda bu sorun ile developer'ı ilişkilendirebilen bir grup insandan bahsedelim. Sistem yöneticisi veya sistemci olarak tabir edilen bu insanlar, bir sistemin vazgeçilmezleridir. Developer'lar şöyle olmalı, böyle olmalı diye ahkam kestik ama sistemcilerin de sahip olması gereken bazı özellikler olmalıdır.


Buzdağının suyun altında parçası mı var?...

Bunların en başında üzerinde uzman olduğu, yönettiği sistemi en kuytu köşesine kadar bilmeli, veya öğrenmeye azimli olmalıdır (yazının bazı yerlerinde bu tür esnemeler olabilir, eğer sadece bilmeli deyip bıraksa idim olmazdı, çünkü hiçbirimiz herşeyi bilmiyoruz, ve daha okuyacak, öğrenecek çok şey var). Sistemin özelliklerini ve yapılabilecekleri bilmek sorunları çözebilmek ve kavrayabilmek adına çok önemlidir. Sistem buzdağı gibi tabir edilebilir, sistemin herkesçe bilinen bazı özellikleri, bazı işlevsellikleri vardır. Sistemci bunları bilmez ise kendini kötü hissetmesi sağlanır!?!?! Ama iş sadece bunları bilmek ile kalmaz. Bu yüzeydeki kısımları bilmesi, sadece günü kurtarmasını sağlar. Ama buzdağının suyun altında kalan kısmını bilir ise kütlenin büyüklüğüne ve yoğunluğuna bakarak, ne tarafa gidebileceğini, ne kadar sürede eriyeceğini veya kaç kişiyi taşıyabileceğini anlayabilir.

Sistem-Alt sistem ilişkisi...

Sistemcinin bilmesi gereken konulardan birisi de yönettiği sistem üzerinde çalışan (üzerinde çalışsın diye programlanmış olan) alt sistemlerin (uygulama sunucusu üzerinde bir uygulama olabilir, oracle üzerindeki SP'ler olabilir, SQL Server üzerinde tablolar olabilir, IBM P575 üzerinde Oracle 10g olabilir, olabilir de olabilir) sistemi üzerinde nasıl çalıştığını, eğer yanlış çalışıyorsa alternatif çalışma yöntemlerinin ne olabileceğini bilmelidir. Örneğin Oracle IBM üzerinde performanssız çalışıyorsa, hem Oracle tarafı; alt sistemini, ana sistem üzerinde çalıştırmak için ince ayar yapar, hem de IBM ana sistemi Oracle alt sisteminin daha performanslı çalışması için ince ayar yapar. Bu profesyonel bir sistem-alt sistem örneğidir. Windows makinenize kurduğunuz Eclipse IDE'sinin çok yavaş çalıştığını düşünürseniz, önce Eclipse IDE'sinin VM ayarlarını artırmayı veya azaltmayı denersiniz, sonra Windows'unuza biraz daha sanal bellek ayırırsınız. Bu çok daha amatör bir sisem-alt sistem örneğidir.

Sonuç olarak, sistem ve alt sistem arasında bir performans kaybı var ise hem sisteme, hem de alt sisteme aynı özenin gösterilmesi lazımdır, ve bu özenin gösterilebilmesi için de sistem yöneticisinin kendi ana sistemini yüzeysel bilginin ötesinde tanıması gerekir.

Bugün olmaz randevum var...

Sistemci olmanın getirdiği en ironik durum ise tüm sorumluluğun size ait olduğu bir sisteme istediğiniz zaman müdahele edemeyecek olmanızdır. Sistemde bir operasyon yapmanız gerekiyorsa, öncelikle bu sistemle uzaktan yakından, az ya da çok ilişkisi olan herkese en müsait zamanın ne olacağını sorup, teyit aldıktan sonra bu işi yapmanız gerekiyor. Bu durumda da operasyonu yapabileceğiniz bir Cumartesi gecesi saat 01:30 için "bugün gelemem, çok önemli bir randevum var, evlenmem gereken birisi ile buluşacağım" diyemezsiniz.

Yedekleme mi? Neyi? Niye?...

Sistemci iseniz yapmanız gereken ilk şey her tür değişiklikten önce sistemin kendinize özgü bir yedeğini almanızdır. Yedek alınmadan yapılan operasyonlar, herhangi bir güvenlik ipi olmadan 400 metre yükseklikte, yağlanmış bir ip üzerinde saatte 20 km hızla koşmaya çalışmaya benzer.. Anlayacağınız, yedek alınmadan yapılan ve başarı ile tamamlanan tüm operasyonlar, meleklerden tarafından korunmuş, ermişler tarafından okunmuştur, ya tamamiyle şans işi, veya dünya dışı varlıkların bir ürünüdür. Abartı bir tarafa, işini bilen sistemciler, daima yedekleme yaparak çalışırlar, hiçbirimiz borsada değiliz, riskin bize kazandıracağı herhangi birşey yok...

Hani Alkış...

Bir sistemin bu kadar çok cefasını çeken, gecesi gündüzü olmayan, ve sistemlerinin alt sistemlerle mürüvvetini görmekten mutluluk duyan sistemcileri hatırlamak... Bununla ilgili olarak System Administrator Appreciation Day sayfası bu tür bir işi görüyor, 9. senesini kutladığımız Sistem Admin'lerini Koruma, Kurtarma ve İyi Bakma günü (bir miktar geçmiş olsa da) hepimize hayırlı uğurlu olsun.

Son Söz..

Sistemci olmak büyük özveri gerektirir. Mesai saati kavramı sistemciler için yapılmamıştır. Aynı zamanda saat gibi tıkır tıkır çalışan bir sisteminiz varsa, sakın böyle bırakmayın, inanın sisteminiz ile ilgili bilmediğiniz daha bir sürü şey var (çok iddialı oldu). Eğer herşeyi bildiğinizi düşünüyorsanız, sizin sisteminizin benzeri daha bir sürü sistem var, dostu/düşmanı iyi tanımak lazım.

Hudson ve JBoss

Hudson kullanım kolaylığı, göze hoş görünebilmesi ve bir çok diğer nedenden dolayı (Hudson ile Sürekli Entegrasyon) açık kaynak topluluğu içerisinde sık kullanılır oldu. Uzun süredir Hudson kullanan JBoss, hudson sayfasında sürümlerini herkesin göreceği hale getirdi. Bu da bir anlamda Hudson'a yapılmış bir jest. Ne de olsa JBoss açık kaynak topluluğu içerisinde gayet iyi bir şöhrete sahip. Bu linke tıklayarak JBoss'un hudson sayfasını görebilirsiniz.

Hudson ile ilgili gelişmeleri Kohsuke Kawaguchi'nin blog'larından bulabilirsiniz.

Confluence içerisinde WYSIWYG Editör sorunu

Geçenlerde düşünüyordum da Blog yazmak ile Wiki sayfası hazırlamak birbirine o kadar yakın gibi görünen iki kavram ki... Zaman zaman bunların içeriklerini birbirine karıştırabiliyoruz. Ben de düşündüm ve bir confluence kurup diğer referanslarımı buraya atmaya karar verdim.

Confluence ile ilgili daha fazla bilgiyi Mustafa Tan'ın "Confluence-I" adlı yazısında bulabilirsiniz.

Biraz download biraz uğraşıdan sonra Confluence hazırdı. Tomcat'i çalıştırdım, ve confluence'a ilk adımımı attım.. Karşıma çıkan adım adım kurulumdan sonra admin hesabı yaratılmış bununla sisteme girilmiş demo bir space üzerinde bulunuyordum. Birkaç gün editledim, karıştırdım, ama bir süre sonra birşeylerin yokluğunu hissetmeye başladım. Sonra farkettim ki WYSIWYG (What You See Is What You Gain) editörüm yoktu, sadece wiki markup language ile editleme yapıyordum. Garip olan buna yabancı olan birinin bunu bir hata olarak görmeyip devam edebileceği ihtimali idi.

Neyse, biraz araştırmadan sonra bununla ilgili bir forum kaydı buldum (okumak için tıklayın). Burada dediğine göre kurulum esnasında oluşan bir problemden dolayı atlassian-bundled-plugins.zip dosyasını açması gereken yere açmıyormuş, hatta bununla ilgili bir de issue varmış (CONF-7750). Tabi bu dosyayı bulmak zor olmadı, çünkü confluence'i download ederken war/ear şeklinde olanı indirmiştim ve unzip ettiğim klasör içerisinde buldum. Bunu alıp Confluence'in data klasöründe bundled-plugins klasörüne açtım (bir hayli jar var) ve tomcat'i restart ettiğimde artık confluence wiki sayfalarımı Ne Görüyorsan Odur editörü ile editliyebiliyordum.

Başka daha garip bir durum ise o kadar jarı bundled-plugin'ine açamadığına göre acaba daha başka neleri göremiyordum.

Apache HTTP Server üzerinde Subversion : can't locate API module structure "dav_svn"

Subversion, CVS'in açık kaynak topluluğunun ihtiyaçlarına artık yetmediği bir zamanda sanki bir anda CVS'in küllerinden doğmuş (biraz abartılı oldu değil mi? Ama güzel oldu) ve açık kaynak topluluğunun yardımına yetişmiştir. Tabi birkaç yerde (Mozilla, OpenSolaris) CVS'ten SVN'e değil de Mercurial'a geçiş olmuşsa da sanırım bir süre daha Subversion dominanat olacak. Neyse, bu şekilde bir toplulukta Subversion'ı her şekilde çalışır hale getirebilmeyi tüm konfigürasyon yöneticilerinin bilmesi gerektiğinden hareketle Subversion'ı birkaç şekilde ayağa kaldırmayı deniyordum.

Svnserve ile herhangi bir sorun yaşamaksızın Subversion'ı hayata geçirdim, sonra sıra Apache üzerinde çalışır hale getirmeye geldi. Bu arada belirteyim ilk önce Subversion 1.4.4 ve Apache Web Server 2.2.4 ile çalışmaya başladım. Adım adım httpd, the Apache HTTP server linkinde istenilenleri yapmaya başladım.

httpd.conf'a gir
LoadModule olarak svn dav zımbırtılarını ekle

Ekledikten sonra devam etmeden önce bir bakmak istedim so dosyalarını yükleyecek mi? Apache server'ı restart ettim ve çat, bahsettiğin so'yu bulamıyorum, yok öyle bir so, bana yalancı mı diyorsun (can't locate API module structure).

Garip geldi, iki üç kere kontrol ettim, dosya orada.. httpd.conf dosyasına eklemem gereken satıra baktım önce LoadModule diye bir keyword, sonra so dosyasını verilecek isim ve sonra so dosyasının yeri. Sonra Subversion'ın Apache ile uyumsuz olup olmayacağı sorusu geldi aklıma, adamlar ön yüzde yazmışlar.

If you plan to install the mod_dav_svn Apache module, note that Apache 2.0 and Apache 2.2 are not binary-compatible. Thus there are two types of Subverison...

Tamam dedim, Apache 2.0 kurdum, denedim cık, aynı hata, Subversion'ı yeniden indirdim onu kurdum. Aynı hata, delirmek üzereyim. Sonra yeniden Apache 2.2 kurdum ve son kez httpd.conf dosyasını açtım, şöyle bir göz atmak için, gözüme birşey takıldı... LoadModule olan tüm kısımlarda benim so ismi dediğim kısım da module ile biterken benimkiler (son iki satır) normal bitiyor.


LoadModule include_module modules/mod_include.so
#LoadModule info_module modules/mod_info.so
LoadModule isapi_module modules/modPublish Post_isapi.so
LoadModule log_config_module modules/mod_log_config.so
LoadModule mime_module modules/mod_mime.so
LoadModule dav_svn modules/mod_dav_svn.so
LoadModule authz_svn modules/mod_authz_svn.so

sonlarına _module yazdım ve restart ettim. Evet ondan sonra çalıştı.

Bu durumda ortaya bir kaç tane yorum ve sonuç çıkıyor.

1. Gözden kaçırdığım bir ayrıntı birkaç saatime mal oldu.
2. Tamam SVN kitabında istenenleri birebir yapsaydım bu hata da olmayacaktı. Ama yaptığımız iş nedeniyle hiçbir zaman yazılanları birebir yapma imkanımız ya da birebir yaptığımızda çalışırsa "hah tamam" diyebilme lüksümüz yok.
3. Hataya baktığımda dav_svn'in bağlı olduğu so dosyasının yerini bulamıyorum diye algılamıştım.
   
4. Eğer bu "_module" postfix'i bu kadar önemli ise bir yerlere "bak bunu yazmayı unutursan Oğuz gibi olursun" denmeli

Sun nohup script

Unix/linux makinelerde çoğu aracı çalıştırmak için shell scriptleri kullanırız. Mesela JBoss'u açmak için run.sh veya CruiseControl'ü çalıştırmak için cruisecontrol.sh, veya kendi yazdığımız ve loglarını takip ettiğimiz shell scriptleri.

Bu scriptleri kullanırken ben en çok nohup komutunu kullanırım gerek arkaplanda çalışsın diye gerekse scriptin outputunu herhangi bir dosyaya almak istediğim için. BigAdmin'deki amcalardan bir tanesi bu işi biraz düzene sokmak adına bir tane nohup.sh yazmış. Automatically Saving Program Output With a nohup Script linkinde belirtilen yöntemleri izleyip nohup.sh ile scriptinizi çalıştırırsanız. /var/ klasörü altında scriptinizin adı ve o günün tarihi ile kombine edilmiş bir log dosyası hazırlayıp saklıyor. İnanın bu tür bir işlem çok faydalı olabiliyor.

Hudson ile Sürekli Entegrasyon

Sürekli Entegrasyon (Continuous Integration) konusu herkesin dikkatlice üzerinde durması gereken hayati bir konudur. Geliştirdiğiniz proje eğer Agile Development tarzında bir proje ise sürekli entegrasyon daha bir önemli hale gelir. Çünkü bulunduğu yer, developer ile client arasında, proje için olmazsa olmaz bir pozisyon olacaktır.

Sürekli entegrasyonu sağlamak adına en çok kullanılan araç CruiseControl'dür... Biz de açıkçası projemizde yaklaşık 3 yıldır CruiseControl kullanıyoruz. Ama bu yazıda size birçok açıdan daha avantajlı, kullanımı kolay başka bir araç olan Hudson'dan bahsedeceğim.

Hudson'ın en göze çarpan ve beni bu yazıyı yazmaya iten özelliği kurulumunun ve hayata geçirilmesinin çok kolay olması. Yani sadece bir web server üzerine deploy etmeniz çalışmaya başlamanız için yeterli. Bu yazıda basitçe hudson'ı Tomcat üzerinde nasıl hayata geçireceğimizi ve yapılabilecek bazı ayarları anlatmaya çalışacağım.

Kurulum

Çalışan bir Tomcat'e (5.0 ve üstü) sahip olduğunuza emin olduktan sonra, hudson'ı bu linke tıklayarak indirmeniz gerekiyor. Aynı Tomcat üzerine birden fazla hudson çalıştırmak isteyebilirsiniz, farklı iş türlerini gruplamak için olabilir, her ne kadar hudson'ın tab sistemi buna benzer bir yapıya sahip olsa da, gruplamanın dışında CI Server'ı restart, redeploy etmeniz gerekebilir. Bu durumda yapmanız gereken iki iş var

• hudson.war dosyasının ismini değiştirmeniz,
• Değiştirdiğiniz war dosyasının web.xml'ini açıp HUDSON_HOME değişkenine bir değer atamanız gerekiyor.

Bu şekilde birden fazla hudson'ı aynı Tomcat üzerinde çalıştırabilirsiniz.

Konfigürasyon ve Püf Noktaları

Eğer hudson'ı kapsamlı bir projede kullanacaksanız, Tomcat üzerine hudson'dan başka bir uygulama deploy etmeyin, böylece Tomcat'in JVM ayarlarını hudson için özel olarak ayarlayabilirsiniz.

Güvenlik : Hudson ile ilgili yapabileceğiniz önemli konfigürasyon ayarlarından bir tanesi de güvenlik ile ilgili olan ayardır. Her ne kadar çok gelişmiş bir güvenlik sistemi olmasa da, hudson'a yapacağınız birkaç ayar ile developer'ların job'ları (Hudson içerisinde iş için kullanılan kavram) sadece görebilme ya da konfigüre edebilme yetkisine sahip olabilmesini sağlayabilirsiniz. Bunun için sırasıyla

• Tomcat üzerinde hudson'ı yönetebilmesini istediğiniz kullanıcıları tanımlayın ve bunları "admin" rolü ile bağlayın
• Son olarak hudson'ın web sayfasını kullanarak Manage Hudson >> System Configuration linkini kullanın ve Enable Security kısmını tikleyin.
  

Hudson default olarak güvenlik opsiyonu açık bir şekilde gelir (herkes herşeyi yapabilir), yukarıdaki ayarları yaptığınızda sadece sizin hudson rolüne uygun görüp tanımladığınız kullanıcılar job'ları çalıştırabilir/konfigüre edebilir veya hudson'ı konfigüre edebilir, diğerleri sadece job'ların ne durumda olduğunu görebilir. Daha çok bilgi için buraya tıklayın.

Yedekleme : Hudson'ı yedeklemek istiyorsanız yapmanız gereken sadece web.xml içerisinde HUDSON_HOME klasörü için belirlediğiniz klasörü yedeklemektir. HUDSON_HOME>jobs klasörü altında bulunan tüm klasörler birer job'dır, bu job'ları kopyala/yapıştır ile başka hudson'lara aktarabilirsiniz.

Haydi işe koyulalım...

Konfigürasyon ayarlarını kurcaladıktan sonra sıra geldi birşeyler üretmeye. Daha önce de belirttiğim gibi hudson kurulumu ve yönetimi kolay bir sürekli entegrasyon aracı. Bunun en iyi örneğini job tanımlama ve yönetme esnasında görebilirsiniz. Hudson ana sayfasında New Job linkine tıkladığınızda 4 değişik job türü yapabilme ve bir tane de varolan bir job'ı kopyalayabilme opsiyonunu göreceksiniz. Bu job türleri kısaca

Maven2 : Maven2 ile geliştirdiğiniz projelerinizi kolayca entegre edebilirsiniz.
Matrix Build : Aynı sürümü birden fazla ortamda birden fazla parametre ile denemek isterseniz.
External Job Monitoring : Sistemde çalışan cron job'ları da takip edebileceğiniz kullanışlı bir job
Free-Style Software : Ayarlarını istediğiniz gibi değiştirebileceğiniz job tipi, benim üzerinde duracağım job da bu.

Free-Style Software'i seçtiğinizde karşınıza bir sürü ayar çıkacak, bunlardan birkaç tanesini anlatmaya çalışacağım, diğerlerini yanlarında bulunan soru işareti ikonuna tıklayarak siz bulabilirsiniz. Build kısmında shell, windows bat, ant build veya maven build'leri çalıştırabilirsiniz. Ant scriptlerini çalıştırmak için Build kısmında invoke top-level Ant targets'ı seçmeniz ve Targets kısmına ant'a girdiğiniz parametreleri yazmanız gerekiyor (mesela ant -f build_deneme.xml için targets kısmına -f build_deneme.xml yazmanız gerekir) Bunu yaptığınız zaman job'ınız bu scriptinizi çalıştıracak durumda beklemeye başlar. Bundan sonra job'lar kısmında bu projenizi göreceksiniz. Yanında "Schedule a build" ikonu ile birlikte.

Sürekli Sürüm (Gecelik, Saatlik)

Ama asıl önemli olan bunu nasıl zamanlanmış iş olarak ayarlayıp, gecelik sürüm, saatlik sürüm haline getirebileceğinizdir. Hudson burada da işimizi çok kolaylaştırıyor. Build Triggers kısmında Build Periodically kısmına tıkladığımızda önümüze free text bir alan açılıyor (Schedule). Buraya yazacağınız syntax ile birlikte bu job'ı zamanlanmış hale getirebilirsiniz. Yan yana yazılan 5 alan bize zamanlama yapma olanağı verir.

MINUTE(Dakika) HOUR(Saat) DOM(Gün) MONTH(Ay) DOW(Haftanın Günü)

Bu alanlar sırasıyla

Dakika : 0-59
Saat : 0-23
Gün : 1-31
Ay : 1-12
Haftanın Günü : 1-7

Mesela her gece saat 21:00'de çalıştır diyebilirsiniz,

0 21 * * *

veya hem gece saat 21:00'de hem de pazartesi-çarşamba öğleden sonra çalıştır diyebilirsiniz,

0 21 * * *
30 12 * * 1,3

Ya da sadece pazartesi akşam 18:00'de çalıştır diyebilirsiniz.

0 18 * * 1

Bahsettiğim ayarları yaptığınızda artık sürekli sürüm sistemine sahip olmuş oluyorsunuz. Bunun yanında isterseniz sürümü manuel de başlatabilirsiniz.

Bunların yanında hudson'ın bize sunduğu daha bir dolu özellik var. Bunlardan biri de plugin ekleyebilme özelliği. Şu anda JIRA, FindBugs gibi önemli olabilecek pluginlerin yanında irili ufaklı bir sürü plugin var ve geliştiriliyor. Pluginleri bu linkte bulabilirsiniz. Bu pluginlerle birlikte sürüm ve entegrasyon sisteminizi daha güçlü ve daha efektif hale getirebilirsiniz.

Ölçek farketmeksizin; eğer sürüm sisteminizi, bir issue tracking tool'u ve file versioning system ile entegre ederseniz , hatırı sayılır bir sisteme sahip olursunuz.