Çevik Pratikler’den Biri, Sürekli Entegrasyon Nedir?

Bu yazı serisinde Çevik Pratikler’den biri, “Sürekli Entegrasyon nedir”, “Sürekli Entegrasyon Pratikleri nelerdir”, “Sürekli Entegrasyon faydaları nelerdir” konularına değineceğim. Sürekli Entegrasyon, terimi 1990’lı yıllarda ilk defa Kent Beck tarafından kullanılmıştır. Kent Beck, eXtreme Programming’in yaratıcısı ve Çevik Yazılım Geliştirme Bildirisi’ni imzalayan 17 kişiden biridir.

Sürekli Entegrasyon, bir yazılım geliştirme pratiğidir. Yazılım geliştiriciler yazdıkları kodu ortak bir alana yükler. Böylece herkesin yazdığı kod ortak alanda derlenir ve çalışan ürün elde edilir. Bir yazılım geliştirici yeni bir işlevsellik geliştireceği zaman ortak alanda bulunan kodu kendi bilgisayarına çeker ve kod üzerinde çalışmaya başlar. Yazılım geliştirici işlevselliği geliştirdikten sonra yazdığı kodu ortak alana yükler. Teoride yapılan işlem bu kadar kolay gibi görünse de gerçek hayatta işler bu kadar kolay değildir. Büyük ölçekli yazılımlar geliştirmek karmaşıktır. Bu karmaşıklığı aşarken yüksek kaliteli ürün oluşturabilmek için disiplin ve koordinasyon gereklidir. Sürekli Entegrasyonla gerekli disiplin ve koordinasyonun sağlanabilmesi için bazı aktiviteler belirlemiştir. Bu aktiviteleri, Martin Fowler, Sürekli Entegrasyon hakkında yazdığı makalede belirtmiş ve bu aktiviteler yazılım dünyası içinde büyük kabul görmüştür.

Sürekli Entegrasyon Pratikleri

1. Bir Tane Kod Kaynağı

Bir ürün geliştirebilmek için bir yazılım projesinde birçok dosya bulunur. Bu dosyalar, Kaynak Kontrol(Source Control) denilen sistemler içinde tutulur. Eskiden yazılım geliştiricinin kendi bilgisayarında, paylaşımlı klasörlerde ya da sürücülerde tutulan dosyalar bulunurdu. Bu pratik birçok  karmaşıklığa yol açıyordu. Birçok kişinin dahil olduğu projelerde Kaynak Kontrol sistemlerini kullanmak oldukça fayda sağlar. Kaynak kontrol sistemleri için maliyet söz konusu değildir. Çünkü açık kaynak kodlu birçok uygulama bulunmaktadır. Projeyle ilgili bütün dosyalar kaynak kontrol siteminde tutulabilir. Bu dosyalara test scriptleri, properties dosyaları, veri tabanı şemaları, yükleme scriptleri, IDE konfigürasyon dosyaları dahildir. Üzerinde hiç yazılım geliştirilmemiş bir bilgisayar Kaynak Kontrol sistemine bağlanıp ilgili dosyaları aldığında artık bu bilgisayar üzerinde kod yazılabilir durumda olmalıdır. Burayı vurgulamak istiyorum, ne yazık ki bugüne kadar çalıştığım projelerde bu şansa sahip olamadım.
Sıkça yapılan hataların en büyüğü şudur: Kaynak Kontrol yazılımları bir proje için birden fazla branch oluşturmanıza izin verir. Bu kullanışlı fakat çokta gerekli olmayan bir özelliktir. Genellikle yanlış kullanılır ve soruna yol açar. Elbet, deneyler için bir branch açıp bunun üstünde çalışılabilir fakat deneyler için açılan bu branch zamanla ana branch oluyorsa sıkıntı var demektir. Bir tane kod kaynağınız olmalı ve herkes bunun üzerinde çalışmalıdır.

2. Otomatize Edilmiş Derleme

Kodlar, bir tane kod kaynağında çalışır duruma geldikten sonra yapılması gereken işlem bu kodların otomatize edilmiş bir şekilde derlenmesidir. Otomatize edilmiş derlemelerin içinde entegrasyon testleri ve birim testleri otomatik olarak çalışmalıdır. Otomatize edilmiş derleme için farklı yazılım dillerinin, farklı platformların, farklı toplulukların farklı uygulamaları mevcuttur.

Büyük bir derleme zaman alır. Bunun için derleme aracınızın bir önce gerçekleştirdiğiniz derleme ile şu anda gerçekleştireceğiniz derleme arasındaki farkları bulması, bu değişiklikler ile ilgili bağımlılıkları bulması ve sadece bunları derlemesi iyi bir özelliktir. Yapılan ufak bir değişiklikten sonra uzun bir derleme süresini beklemek doğru değildir. İyi derleyiciler bu tarz işlemlerle başa çıkabilir durumdadır fakat başa çıkamayanlarda bulunmaktadır. Bir yazılım geliştirici kendi bilgisayarında kullandığı yazılım dilinin IDE’sine bağlı olan derleme sistemini kullanabilir fakat onlarca yazılım geliştiricinin kodunun aynı anda derlenmesi için bir ana bilgisayar üzerinde bahsettiğim platformlardan biri kullanılmalıdır.

3. Derlemeyi Kendi Kendini Test Eder Yapın

Hataları hızlıca ve verimli bir şekilde yakalamanın yolu derleme sürecine otomatize edilmiş testlerin eklenmesidir. Kendini test eden bir derleme yapısı oluşturduktan sonra basit bir komut ile derlemeyi başlatabilmelisiniz. Eğer yazdığınız testlerde herhangi birinde sorun yaşanır ve başarısız olursa derlemede başarısız olacaktır. Derleme aracınız hatanın kaynaklandığı yer hakkında bilgi veriyor olmalıdır. Böylece hatayı kolayca bulabilecek ve sorunlu bir sürümü son kullanıcıya ulaştırmadan sorunu düzeltebileceksiniz. Bu test alt yapısını oluşturabilmek için herhangi bir bütçe ayrılmasına gerek yoktur. Bu işlemi layıkıyla yerine getirebilecek birçok açık kaynak ürün bulunmaktadır.

4. Herkes Geliştirdiği Kodu Her Gün Entegre Eder

Entegrasyon iletişimdir. Entegrasyon, bir yazılım geliştiricinin değişiklikler yaptığına dair diğer yazılım geliştiricilere bilgi vermesidir.

Bir yazılım geliştiricinin kodunu kaynak kod ile entegre edebilmesinin ilk koşulu, kodunun kaynak sistemle entegre bir şekilde derlenebilmesidir. Bunun için ilk önce kendi makinesinde gerekli derleme işlemini gerçekleştirir ve başarılı olduktan sonra kaynak kod ile kendi kodlarını birleştirir. Daha sonra ise kendi kodlarını ana branch’e gönderir. Bu işlemi sık gerçekleştiren iki yazılım geliştirici eğer bir çakışma yaşıyorsa, geliştirdikleri konu üzerinde daha fazla çalışmadan çakışmayı çözmeleri gerekir. Yazılım geliştiricilerin işlerini ufak parçalara bölmeleri çakışma sayısını en aza indirir. İşleri ufak parçalara bölmenin diğer bir faydasıysa projede ilerlemenin görünür olmasını sağlamasıdır. Projede ilerliyor olmak yazılım geliştiricinin motivasyonunu yükseltir.

5. Yazılım Geliştiriciler Tarafından Gönderilen Her Kod Entegrasyon Makinesi Üzerinde Derlenmelidir

Geliştirilen kodun her gün ana branch’te derlenir ve kod üzerindeki testler çalıştırılır. Böylece ana branch sağlıklı bir şekilde yaşar. Yazılım geliştiriciler geliştirdikleri kodu ana branch’e göndermeden önce kendi bilgisayarlarında derleme işlemini gerçekleştirmeyebilirler ve testlerden geçmemiş bu kodu ana branch’e gönderebilirler. Diğer bir sorun ise bir yazılım geliştiricinin bilgisayarı ile bir başka yazılım geliştiricinin bilgisayarı aynı olmayabilir. Gündelik hayat içinde farklı sorunlar yaşanabilir. Sonuç olarak entegrasyon makinesi üzerinde düzenli derlemeler yapılmalıdır. Sadece entegrasyon makinesi üzerinde yapılan derlemeler başarılı olduktan sonra yazılım geliştiriciler kodlarını ana branch’e göndermelidir. Yazılım geliştirici ana branch üzerinde bir derleme başlattığında bundan o sorumludur ve bu derleme bitene kadar iş yerinden ayrılmamalıdır.

Sürekli Entegrasyon makinesi ana branch’i sürekli olarak izler. Ana branch’e her kod gönderilişinde Sürekli Entegrasyon makinesi yeni kodu alır ve bir build başlatır sonrasında ise kodu ana branch’e gönderen kişiyi build’in başarılı ya da başarısız olduğuna dair bilgilendirir. Birçok organizasyon düzenli olarak build’ler gerçekleştirir. Her gece ya da haftanın belirli bir gününde düzenli olarak bu işlemi gerçekleştirilir.

Bir hata ana branch’te ne kadar uzun süre kalırsa bulması o kadar zorlaşır. Sürekli Entegrasyon ile mümkün olduğunca kısa sürelerle yapılan entegrasyonlar ile ana branch’teki hatalar tespit edilmelidir ki çözülmeleri kolay olsun.

Serinin diğer yazısına buradan erişebilirsiniz.