MarcoPolo: Gitlab-Jira Otomasyon Serüveni

Dilara Can
hepsiburadatech
Published in
4 min readOct 26, 2022

Change Management

Değişim yönetimi, bir kuruluşun hedeflerinin, süreçlerinin veya teknolojilerinin geçişi veya dönüşümü ile ilgilenmeye yönelik sistematik bir yaklaşımdır.

Değişiklik yönetimi, proje yönetiminde önemli bir rol oynar çünkü her değişiklik talebinin proje üzerindeki etkisi açısından değerlendirilmesi gerekir. Proje yöneticileri veya değişiklik kontrolünden sorumlu üst düzey yöneticiler, projenin bir alanındaki değişikliğin diğer alanları nasıl etkileyebileceğini ve bu değişikliğin bir bütün olarak proje üzerinde ne gibi etkileri olabileceğini incelemelidir.

Hepsiburada içerisinde de bir Change Management yaklaşımı benimsenmeliydi. Bunun sonucunda Marco ve Polo projeleri doğmuş oldu.

Neden Bu Süreçlere ve Projelere İhtiyaç Duyduldu?

Hepsiburada bünyesinde yüzlerce yazılım projesi var ve bu projeler günde yüzlerce release çıkıyor. Bu durumda şu soruların yanıtı büyük önem taşıyordu:

Bu release’ler kimler tarafından başlatılıyor? Testleri nasıl yapılıyor ve hangi bulgulara rastlanıyor?

Hangi ekipler bu release’den etkileniyor?

Release’i kimlerin onaylaması gerekiyor? Release’i kimler onaylamış?

Bu sorular ve bunlar gibi doğabilecek diğer tüm sorunların çözümü ve güvenli bir yönetim için Change Management sürecinin başlaması gerekiyordu.

😇

Change Management Sürecinin Beyni MarcoPolo 🧠

MarcoPolo projesi, en basit tanımıyla Gitlab ve Jira arasındaki entegrasyonu kontrollü bir şekilde sağlar. MarcoPolo, Gitlab üzerinde bir merge request oluşturduğumuzda bunu Change Management süreçlerine uygun ve sistematik bir şekilde gerçekleştirir.

Aslında bu proje iki ayrı microservice olarak karşımıza çıkıyor. Gitlab ve Jira üzerinden gelen webhookları karşılayan ve işleyerek Kafka üzerine mesaj bırakan Marco, Kafka üzerindeki mesajları dinleyip yorumlayarak Gitlab ve Jira üzerinde aksiyon alan Polo projeleri.

Neden iki ayrı microservice olarak yazma ihtiyacı duyduk

Gitlab ve Jira üzerinden gelen webhooklarda Kafka üzerinde oluşacak mesajların doğru şekilde oluşması, hata oranını azaltarak veri kaybını önleme ve ihtiyaç duyulan durumlarda kolayca scale edebilme gibi durumlardan kaynaklı iki ayrı microservice olarak bu süreci yönettik.

MarcoPolo Architecture

Marco

Marco projesinin temel amacı Gitlab ve Jira üzerinden webhook ile gelen verileri Polo projesinin kullanabileceği duruma getirip bunu servis etmektir.

Marco projesini iki adet endpoint’e sahip bir microservice olarak tasarladık. Birinci endpoint Gitlab üzerinden gelen verileri karşılarken, ikinci endpoint Jira üzerinden gelen verileri karşılamaktadır.

Gitlab’den Gelen İsteklerin İşlenmesi

Gitlab’de merge request açıldığında, Gitlab, webhook ile Marco’yu tetikler. Marco ilk olarak bu merge request’in hangi branch üzerinden açıldığını kontrol eder. Branch kontrolü yapılmasının sebebi sadece production branch’i üzerinde işlem yapılması gerekliliğidir. Yani proje içerisinde bulunan diğer brachler’den gelen istekleri Marco görmezden gelir. Bu aşamadan sonra merge request standard(feature) mı yoksa bir hot-fix (urgent) için mi açılmış bunun kontrolünü yapmaktadır. Bu kontrolüde açılan merge request’in kaynak branch ismini kontrol ederek anlar.

Hot-fix olarak açılan merge request hemen “marcopolo” Gitlab User tarafından approve edilir ve ardından Polo’nun consume edeceği mesaj Kafka’daki urgent topic’ine bırakılır. Hot-fix olarak açılan merge request’lerin direkt approve edilmesinin nedeni hızlı şekilde deployment yapılması gereken bir durumda deploy yapacak ekibin işini hızlandırmaktır. Approve işleminden sonra merge request, merge edilebilir duruma gelir.

Geri kalan merge request istekleri için ise servis gerekli verileri işleyerek standard olan Kafka topic’ini Polo projesinin consume etmesi için besler. Tüm gelen merge request içerikleri kurduğumuz Postgresql database’ine kaydedilir. Bu şekilde bir kere işlenen merge request istekleri herhangi bir merge request güncellemesi durumunda Gitlab tarafından tekrar servisimize gönderildiğinde bunu anlarız ve bu veriyi tekrar işlemeyiz.

Jira Üzerinden Gelen İsteklerin İşlenmesi

Polo projesi tarafından açılan Jira task’ları, sonuçlandırılmaları durumunda yani statü olarak “Done” veya “Reject” statüsüne getirildiğinde, Jira tarafından Marco projesine bir istek gider bu isteği Marco işleyip Polo’nun consume etmesi için Kafka’daki jira-close topic’ine iletir.

Polo

Marco’nun kuyruklara gönderdiği mesajlar alınıp işlenmeli, gelen bilgilere göre Jira ve Gitlab tarafında aksiyonlar alınmalıdır. Jira ve Gitlab arasında gerekli entegrasyon sağlanmalı ki, developerlar gerekli aksiyonları hızlıca ve üretken şekilde alsın. İşte burada Polo sahne almaktadır.

Polo standard, urgent ve jira-close olarak 3’e ayrılan Kafka topic’lerinden gelen mesajları alarak Jira veya Gitlab ile iletişim kurup rest api’ler aracılığıyla gerekli aksiyonları almaktır.

Polo, pure Python ile hazırlanmış bir microservice’tir ve 3 farklı thread çalıştırır. Bu thread’lerin her biri Kafka üzerindeki bir topic’i dinlemektedir ve gelen mesajları uygun aksiyonlara yönlendirmektedir.

Polo Architecture

Standard veya urgent topic’lerinden mesaj geldiğinde Polo Gitlab üzerinde bir merge request açıldığını algılar ve bu merge request’le ilgili bir Jira task’ının açılması için Jira’ya gerekli bilgileri gönderir. Ayrıca Confluence üzerinde bir PIR kaydı açılır ve bu kayıt ilgili Jira kaydına linklenir. Jira üzerinde ilgili task’ın açılması ile Gitlab tarafındaki merge request üzerine ilgili Jira task’ının linki yorum olarak bırakılır ki developerlar kolayca task’lara erişebilsinler.

Jira-close topic’inden bir mesaj geldiğinde ise Polo Jira task’larından birinin kapatıldığını anlar ve gelen Jira task’ının status bilgisine göre bu Jira task’ı hangi merge request için açıldıysa Gitlab üzerinde bunu onaylar veya kapatır. Gelen bilgi reject ise merge request kapatılır , done ise merge request onaylanır ve böylece developerlar için merge butonu aktifleşir.

Beklenmedik durumlarda Kafka’daki mesaj kaybını önlemek için bir retry topic’imiz mevcut. Mesajı consume edip işleme anında bir hata meydana gelirse, main topic’teki mesajı retry topic’ine bırakıyoruz. Bu topic için geliştirilen logic, main topic’teki akış şeklinde işletilir. Böylece gelen mesajların beklenmeyen hata durumlarında kaybolmasının önüne geçilmiş olur.

Teşekkür

Marcopolo projesini DevX ekibi olarak birlikte hayata geçirdiğimiz ve bu makale üzerinde emekleri olan Oğuz Çakır ve Burak Çayır arkadaşlarıma teşekkür ediyorum.

--

--