Giriş

Bilgisayar yazılım mühendisliğinde revizyon kontrolü, kaynak koddaki değişiklikleri izleyen ve bunlar üzerinde kontrol sağlayan her türlü uygulamadır. Bu, geliştiricilerin en çok ihtiyaç duyduğu şeylerden biridir. Çünkü geliştirilmekte olan herhangi bir yazılım projesinde çok fazla değişiklik olacaktır. Projedeki bu değişikliklerin sürekli olarak izlenmesinin sayısız avantajı vardır. Bu avantajlar, yazılım geliştirici sayısı yüksek olan ekiplerde daha net görülmekle birlikte, bireysel çalışmalar için de sayısız avantaj sağlamaktadır. Tüm avantajları tek bir cümlede özetlemek istersek, üzerinde çalıştığınız dosyalarda yapılan değişiklikleri kaybetmeden ekibin her zaman uyum içinde olmasını sağlar.

Yazılım geliştirme projelerinin sayısı arttıkça, yazılım geliştiriciler kod kaybı gibi sorunları önlemek için versiyon kontrol uygulamaları geliştirme ihtiyacı da duydular. İlk olarak 1970’lerin başında ortaya çıkan yerel tabanlı uygulamalar, SCSS (Source Code Control System) ve RCS (Revision Control System) vb. Sonra 1970’lerin sonuna doğru istemci sunucu (client server) uygulamalarına dönüştüler; Panvalet, Software Change Manager vb. O günlerde alternatiflerin sayısı da hızla artıyordu. Ancak bu konuda asıl farkı yaratan en büyük gelişme, 2000’lerin başında dağıtık (distributed) teknolojiye geçiş oldu. Geliştiricinin herhangi bir ağa ihtiyaç duymadan oldukça hızlı çalışmasını sağlayan bu teknoloji çok popüler oldu. Mimarinin en bilinen ve en yaygın üyesi olan, özellikle açık kaynaklı projeler geliştiren kişiler tarafından tercih edilen ise Git’tir. Hayatımızı neredeyse değiştirdiğini söyleyebileceğim Git, etrafında devasa bir ekosistem de yarattı.

git

Giriş aşamasındaki teorik bilgilerden sonra bugünkü konumuza dönelim. Git’in harika bir ekosistem yarattığından bahsetmiştik. Bu ekosistemin en büyük üyeleri, Git’te Repository (Depo) olarak adlandırdığımız kod setlerini ücretsiz olarak barındırmayı ve yönetmeyi sağlayan araçlardır. Bu araçların ana merkezi olarak tanımlanan GitHub, açık kaynaklı geliştiricilerin adeta evi haline geldi. Ancak kurumsal şirketlerde uygulama geliştiren yazılım geliştiriciler için, bazı durumlarda kendi sunucularında çalışabilecekleri şirket içi (on premise) çözümler gerekmektedir. Bu ihtiyacın farkında olan geliştiriciler de bu konu üzerinde çalışmış ve kendilerinin ve diğer geliştiricilerin ihtiyaçlarına yönelik çözümler sunmuşlardır. Bu çözümler de açık kaynaklı çözümler ve lisanslı çözümler olarak ikiye ayrılmaktadır.

Bu makalede bu açık kaynaklı ve lisanslı ürünler arasından TFS, GitLab ve Gerrit’i inceleyeceğiz. Farklı ihtiyaçlar doğrultusunda geliştirilen bu ürünlerin kullanımı, çalışma mantığı ve yetenekleri hakkında bilgi sahibi olacağız. Son olarak aralarındaki farkları yorumlayacağız.

TFS

Tanım:

TFS, Team Foundation Server’dır ve bir Versiyon Kontrol Sistemi (VCS), bir iş takipçisi (Jira gibi) ve aynı zamanda bir uygulama yaşam döngüsü yönetimi aracının birleşimidir. TFS kendi versiyon kontrol sistemi üzerinde çalışıyordu, ayrıca bir süredir Git’i de destekliyor. Bu sayede proje yönetimi, hata takibi ve versiyon yönetimi tek bir uygulama çatısı altında buluşuyor. Microsoft’un uzun yıllardır üzerinde çalıştığı ve sürekli yeni sürümlerini duyurduğu TFS, çeşitli özelliklere göre belirlenen bir ücret karşılığında satılmaktadır. Buna kurumsal şirketler için hepsi bir arada (all in one) bir çözüm diyebiliriz.

Mekanizma:

Birlikte çalışan birden fazla geliştiriciniz olduğunda, kararlı (stable) sürümler yayınlamanız gerektiğinde ve sürüm yayınlarken geliştirmeye devam etmek istediğinizde; Sürekli Dağıtım (Continuous Deployment) senaryosuna geçişin temelidir. Ayrıca “resmi” kodun en iyi uygulama kılavuzlarınızın en azından bazılarına uymasını sağlamanın mükemmel bir yoludur. Pull Request (Çekme İsteği) kullanımı TFS’e yerleşik olarak gelir. Yerleşik araç ile sürekli entegrasyon (continuous integration) sürecinizi kolayca kurabilirsiniz.

Pull Request

Pull request’ler, sunucudan değişikliklerinizi (commit’lerinizi) hedef bir dal (branch) ile birleştirmesini (merge etmesini) açıkça istediğiniz bir mekanizmadır. Daha sonra birleştirme koşulları için kurallar ve ayrıca alınabilecek bir dizi otomatik adım ayarlayabilirsiniz. Pull request, aynı zamanda kod incelemesi (code review) talep edebileceğiniz öğedir. Bu da otomatikleştirilebilir.

Yani bir pull request birden fazla amaca hizmet eder. Resmi kodun daha temiz kalmasını sağlar, kod incelemelerine olanak tanır, resmi kod tabanına girmeden önce yazdıklarınızın başarıyla derlendiğinden (builds green) emin olur.

Gerrit

Tanım:

Gerrit, kod incelemesi için kullanılan web tabanlı bir araçtır. En önemli özellikleri, kod incelemelerini hızlı ve basit bir görev haline getiren yan yana fark görüntüleme (side by side difference viewing) ve satır içi yorum yapmadır (inline commenting). Git versiyon kontrol sistemi ile birlikte kullanılır. Gerrit, incelemeler yapıldıktan sonra yetkili katkıda bulunanların Değişiklikleri (Changes) Git deposuyla birleştirmesine izin verir. Katkıda bulunanlar çok az çabayla kodlarını inceletebilir ve değişikliklerini sistemden hızlıca geçirebilirler.

Mekanizma:

Gerrit kullanımının iki aşaması vardır: İlk olarak, katkıda bulunan kişi değişiklikleri Git ile Gerrit’e yükler ve ikinci olarak, iş arkadaşları inceleme yapmak için web tarayıcısını kullanır. İnceleme süreci aşağıdaki adımları içerir:

• Değişiklikleri İnceleme (Review Changes)
• Yorumları yayınlama (Publish comments)
• Değişiklikleri onaylama veya iptal etme (Approve or abandon Changes)

Git, bir commit’i mükemmel olana kadar sürekli güncellemek için bir mekanizma sağlar: bir kod değişikliğini yeniden yapmak (yeniden kaydetmek) için git commit --amend komutunu kullanın. Bir commit’i bu şekilde güncelledikten sonra, dalınız (branch) yeni commit’i işaret eder. Ancak, eski (kusurlu) revizyon kaybolmaz. git reflog aracılığıyla bulunabilir.

Gerrit, kavramsal bir değişikliği commit mesajındaki bir alt bilgi (footer) ile tanımlar. Her commit mesajı alt bilgisi, tüm taslaklar arasında bir değişikliği benzersiz şekilde tanımlayan bir Change-Id mesaj kancası (message hook) içerir.

Örneğin: Change-Id: I9e29f5469142cc7fce9e90b0b09f5d2186ff0990

Böylece, commit’ler amende edildikçe (güncellendikçe) Change-Id aynı kalırsa, Gerrit her yeni versiyonun aynı kavramsal değişikliğe atıfta bulunduğunu tespit eder. Gerrit web arayüzü versiyonları gruplandırır, böylece incelemeciler kod incelemesi sırasında değişikliğinizin nasıl geliştiğini görebilirler.

Gerrit’in ana farklarından biri, inceleme sürecinin geliştiricinin commit’i ile başlamasıdır. Sadece incelenmiş ve onaylanmış commit’ler origin’de yer alabilir. Ayrıca, TFS ve GitLab tüm DevOps süreci için çözümler sunarken; Gerrit yalnızca kod incelemesi içeren bir Git hizmeti sunar.

GitLab

Tanım:

GitLab, GitLab Inc. tarafından geliştirilen, açık kaynaklı bir lisans kullanan; wiki, iş takibi (issue tracking) ve CI/CD hattı (pipeline) özellikleri sunan Git depo yöneticisi barındıran, web tabanlı bir DevOps yaşam döngüsü aracıdır.

Kod başlangıçta Ruby ile yazılmış, daha sonra bazı bölümleri Go ile yeniden yazılmıştır; ilk olarak yazılım geliştirme konusunda ekibiyle iş birliği yapmak için bir kaynak kod yönetim çözümü olarak ortaya çıkmıştır. Daha sonra yazılım geliştirme yaşam döngüsünü kapsayan entegre bir çözüme ve ardından tüm DevOps yaşam döngüsüne evrilmiştir. Güncel teknoloji yığını Go, Ruby on Rails ve Vue.js’i içermektedir.

GitLab’i Github gibi çevrimiçi bir Git deposu olarak kullanabilirsiniz. Dahası, sunucunuza kurabilir ve şirket içi (on premise) çözüm olarak kullanabilirsiniz. Ek olarak, GitLab CI Runner’ı sunucunuza kurarak kullanırsanız, tüm sürekli entegrasyon yaşam döngüsünü kolayca tamamlayabilirsiniz.

Mekanizma:

GitLab’in akışı Merge Request’ler (Birleştirme İstekleri) ile çalışır. Merge Request kulağa tanıdık geliyor, biliyorum. Merge Request ve Pull Request, git depolarını yönetmeyi sağlayan farklı ürünlerin aynı özelliğidir. GitLab bu konuyu şu cümlelerle açıklamaktadır: “Merge veya pull request’ler bir git yönetim uygulamasında oluşturulur ve atanan kişiden iki dalı birleştirmesini ister. GitHub ve Bitbucket gibi araçlar, ilk manuel eylem özellik dalını çekmek (pull) olacağından pull request adını seçer. GitLab ve Gitorious gibi araçlar ise, atanan kişiden talep edilen nihai eylem bu olduğundan merge request adını seçer. Bu makalede bunlardan merge request olarak bahsedeceğiz.”

Hangisini Seçeceksiniz?

Hangisini seçeceğinize karar verirken kesinlikle ihtiyaçlarınızı göz önünde bulundurmalısınız. Çünkü ihtiyaçlarınız, aracın yararlı olup olmadığına karar vermenizi sağlayacaktır.

Örneğin, incelemelerin merge request yerine her commit üzerinde olmasını istiyorsanız, kullanmanız gereken araç Gerrit olacaktır. Ancak Gerrit’in konfigürasyonu ve öğrenme eğrisi işinizi biraz zorlaştırabilir çünkü aşina olmadığınız Git komutları işin içine dahil olur.

Eğer inceleme sizin için birleştirme (merge) sırasında daha uygunsa ve sürüm hazırlama sürecinde çok zamana ihtiyacınız varsa ve bunları tek bir araçtan kolayca yönetmek istiyorsanız GitLab’i kullanabilirsiniz. Ancak tamamen bulut yapısı üzerinde çalışan bir sistem olduğunu ve çalıştığınız şirketin politikalarını da unutmamanız gerekir. Örneğin, Türkiye’deki bankalar kodlar da dahil olmak üzere bulut yapısında hiçbir veri tutmazlar. Bu durumda GitLab’in şirket içi (on premise) çözümü tercih edilebilir.

TFS, Microsoft’un lisanslı ürünü olduğu için küçük ve büyümekte olan ekipler için uygun değildir. Çünkü her lisans için ödeme yapmanız gerekir. Ancak Microsoft lisanslarına sahip kurumsal bir şirkette çalışıyorsanız, tüm projeyi yönetmek için TFS güzel bir seçim olacaktır. TFS ile çevik panolar (agile boards), Git depoları ve kullanımı kolay DevOps aracını kullanabilirsiniz.

Özetlemek gerekirse, ihtiyaçlarınıza karar vermelisiniz. Tüm şirketler için geçerli olan tek bir harika çözüm yoktur. Herkes ihtiyacına göre en iyisini seçmelidir.

Yazar: Efecan Tekin

Tags