Sürekli Entegrasyon Pratikleri - I

Sürekli Entegrasyon Pratikleri - Bölüm 1

Sürekli entegrasyon kurallarını uygulayarak bir sürüm sistemi kurdu iseniz, unutmayın bu sistem dikkatle hazırlanması, yönetilmesi ve takip edilmesi gereken bir sistemdir. Daha önce bu konu ile ilgili olarak Hudson ve Ant konuları ile ilgili yazılar yazdım.. Bunların hepsi deneyimler üzerine dayanan yazılardı.



Son zamanlarda bu tür yazılar yazmaya, yeni araçları incelemeye çok fırsat bulamadım. Ama Continuous Integration: Improving Software Quality and Reducing Risk kitabını satın aldım, ve müsait olduğum zamanlarda bu kitabı okumaya ve mümkün mertebe uygulamaya çalıştım... Uygulamaya çalışma işlemini ise, uygulamak istediğim maddeleri post-it'lere yazıp, uygulayabildiklerimi bu listeden çıkarmak şeklinde yapabildim...

Belli bir sayıda post-it'i uyguladığımda ise bunları yorumlarımla birlikte burada paylaşmaya karar verdim. Bu ilk yazımda dört tane pratikten bahsedeceğim.


Pratik I - Veritabanı işlemlerini ANT JOB'ı haline getirmek

Sürekli entegrasyon sistemi içerisinde aynı zamanda Veritabanı yapılarının da taşınması söz konusudur. Yani yeni bir sürüm ile birlikte yeni kodlar, yeni veritabanı yapıları ve veriler de taşınır. Bu konuyu daha önce, hassasiyet gerektiren bir konu olmasından dolayı manuel yapıyordum. Tabi manuelden kastım, bir SQL Editor ile çalıştırmak değil tabi, komut satırından çalıştırma yöntemi ile, bir tür otomasyon vardı ama yine de manuel sayılırdı... Daha sonra farkettim ki, bu işlem hem yönetmesi zor, hem geriye dönük herhangi bir log tutulmayan bir işlem haline dönüşüyor... Tekrar edilmesinde yaşanan zorluklar ve modüler olmaması da cabası.. Hem bu işlemi manuel yapma sebebim lokasyon farklılığından dolayı idi ve bu engelin de ortadan kalktığını düşünürsek zaten bu tür bir çevirimin zamanı gelmişti...

Tabi, bu durumda sürüm esnasında manuel işlemleri de minimize etmiş oldum. Yani kısacası bu işlemi ant job'ı ile yapmak ve bunu bir de Hudson'a eklemek ileride bize çok büyük avantaj getirecek...

Pratik II - Developer'ları Sürekli Entegrasyon Konusunda Eğitmek (veya Bilgilendirmek)

Yaşadığımız en büyük sıkıntı, daha doğrusu en can sıkıcı konu, developer'ın "sürekli entegrasyon" konusuna olan uzaklığı idi.. Eğer developer, sistemi ne kadar az bilirse, o kadar sorun ile karşılaşır ve/veya soruna yol açar... Dolayısıyla, developer'ı eğitmek sorunları en aza indirebilmenin en kolay yollarından birisidir. Peki nasıl yapılır?

• Birim içi konferans ve eğitimlerle
• Dokümantasyon ile

Konferans veya eğitim, hem uzman olmadığım hem de zaman darlığımızın olması nedeniyle tercih edemediğimiz bir seçenek oldu. Bunun yerine Confluence üzerinde (daha önce Twiki ile hazırladığım dokümantasyonu buraya taşıyarak) bir know-how oluşturmaya çalıştım. Özellikle, ana sayfama Sürekli Entegrasyon Sistemi ile İyi Geçinmenin 7 Altın Kuralı diye de bir yazı ekledim. Continuous Integration kitabından bir bölümün çeviri ve yorumlarının olduğu bir yazı oldu.. Developer'lara en azından bu şekilde bir bilgi aktarımı yapmanın gerekli olduğuna inanıyorum...

Pratik III - Deploy edilen Artifact'ları depolamak

İlk etapta kulağa saçma gelecek, "yaa nasıl olsa sürüm scriptlerim var, subversion üzerinde gerekli ayarlamaları yapip sürümü yeniden çıkarırım" diyebilirsiniz, yapabilirsiniz de... Ama bir kere yaptıktan sonra bir daha konuşalım olur mu?.. İnanın acı verici boyutlara gelebileceği için söylüyorum... En azından benim yönettiğim sistemde bu tür bir işi yapmak bir hayli acı verici.. Projenin tek bir jar, veya war'dan oluşmadığını belirtmekte fayda var... Tabi her proje bu şekilde olacak diye bir kaide yok.. Ama işin içinde 10'dan fazla JAR, bpm dosyalari, ön yüz dosyalari (EBML), EAR, veritabanı vs. varsa, bu tür bir işlem o kadar da kolay olmuyor...

Neyse, uzun lafın kısası, bütün bu deploy edilen artifactları, deployment işleminden hemen önce ayrı klasörlerde tutarak, olası bir geri dönme işleminde nasıl davranacağımızı, ya da o sürümde neleri deploy ettiğimizi daha rahat görebiliyoruz.. Hele bu depolama işlemini yaptığımız klasörleri sürüm numarası ile isimlendirirsek, o zaman sistemin keyfine bakmaya başlayabiliriz...

Pratik IV - JAR, EAR ve Konfigürasyon dosyalarının SVN üzerinde tutulması

En sık karşılaştığım sorulardan bir tanesi "PROD ortamında JAR'ımın hangi versiyonu var?" sorusudur heralde.. Her ne kadar Developer'ın bunu öğrenmek için 343 ayrı yöntemi olsa da, sanırım bu işi sorumlu birisine sormak daha eğlenceli oluyor. Ya da "PROD ortamındaki EAR'ı alabilir miyiz?" sorusu karşısında birkaç saniye durup da "Allright, I'm on it" demektense, bu istenilen JAR, EAR ve konfigürasyon dosyalarını her ortam için ayrı ayrı SVN'e koymak, hem sistemin yedeğinin alınması, hem de bu tür durumlarda Developer'ın "self-servis" yapabilmesi açısından çok faydalı olabilir..

SonSöz

Bayılıyorum son söz yazmaya ama bu sefer herhangi bir son söz yok, çünkü bu yazı devam edecek...