Hürriyet’te “On Air!” — Kamera Arkası
Herkese merhaba,
Oldum olası kamera arkası hikayelerini çok severim. Hayranlıkla izlediğim bir filmin çekim aşamasında, sahne aralarında, kulislerde geçen sohbetleri, kullanılan teknik ve teknolojileri izlemekten müthiş keyif duyuyorum. Bazen kendimi o insanların yerine koyuyor, o mekanın bir köşesine yerleştiriyor ve o anı yaşamaya çalışıyorum. “Sinema” denilen sanata tabii ki bir izleyiciyim. Bununla birlikte bizim işimizin de bir sanat olduğu konusunda ortaya konan savlara inancım oldukça güçlü. Bizler de bir prodüksiyon ortaya koyuyoruz, çizimler yapıyor, senaryolar yazıyoruz. Bunları da ete kemiğe büründürüp ziyaretçilerimizle buluşturuyoruz. Peki, bizim hayatımızın kamera — monitör — arkasında — önünde — neler oluyor? Merak eden sevgili dostlar için kısaca aktarmak istedim. Bu hikayenin bir senaryosu yok, umarım bir noktaya bağlayabilirim :)
Sevgili dostum Mehmet Ali Erdin, geçtiğimiz günlerde teknik ve doyurucu bir yazı ile Hürriyet’in yayına çıkış süreçlerini özetledi. DevOps, Continuous Integration (CI), Continuous Delivery (CD) gibi kavramlar; TeamCity, Octopus, Bitbucket gibi araçlar hayatımıza gireli çok uzun süre olmadı aslına bakarsanız (düşündüm de çok kısa da olmamış aslında :)). Bizler de teknik bilgi ve becerilerimizi dokümanlarla beslemekle birlikte aslında hepimizin yaptığı gibi sahada deneyimliyor ve perçinliyoruz. İşte bizim kamera arkamız da tam bu sahnede başlıyor aslında.
İstek: Manşet Yanı 4'lü Haber Kutusu Geliştirmesi
Bu bölüme yine bir referansla başlamak kötü olmaz diye düşünüyorum. 2016'nın en çok okunan Türkçe Medium yazılarında yer alan ve Kemal Ogün Işık tarafından kaleme alınan “50 Milyon Ziyaretçili Web Sitesini Nasıl Sıfırdan Yazdık?” yazısında hurriyet.com.tr projesinde kullanılan teknolojilerden detaylıca bahsediliyor, bu yazıyı henüz okumadıysanız şiddetle tavsiye ederim. Bizler de bu proje üzerinde geliştirmelerimizi yürütüyoruz ve günün birinde başlıkta belirttiğim şekilde bir istek tarafımıza ulaşıyor. Peki siz bu kutudaki haberleri görürken biz hangi süreçlerden geçiyoruz?
JIRA’da açılan işi üstlen ve süreci ilerlet
Ürün ekibimizden gelen talep ve analiz ekibimizin çalışması sonucu işin detayları şekilleniyor ve bizler bu işi JIRA’daki “Ready For Development” kolonundan sürükleyip “To-Do” kolonuna bırakıyoruz. Let the game begin!
Branch oluştur ve geliştirmeye başla
Geliştirmeye başlamadan önce “To-Do” -> “In Progress” durum değişikliğini JIRA üzerinde yapıyoruz. Hemen ardından ise geliştirme ortamına dönüyor, development branch’imizden yeni bir branch oluşturuyoruz. Bu branch isimlerimiz genellikle [PROJE-KISA-ADI]-[IS-NO] şeklinde oluyor. Tabii ki bunun bir geliştirme mi yoksa bir düzeltme mi olduğunu da dikkat çekiyoruz. Örneğin; feature/ABC-1234 ya da hotfix/ABC-987 gibi.
Bu noktada hemen belirtmekte fayda var diye düşünüyorum. Bizim işimizin en önemli tarafı “iletişim”. Her ne kadar robotik ürünler ortaya koysak da bu ürünlerin gelişimi esnasında “yüz yüze iletişim”e büyük önem veriyoruz. Takıldığımız noktalarda ürün ekibimizden, analiz ekibimizden ya da yazılım ekibimizdeki diğer arkadaşlarımızdan yardım/fikir paylaşımı taleplerimiz oluyor ki böylece süreci doğru bir şekilde noktalayabiliyoruz.
Geliştirmeni tamamla, test ortamını hazır et
Lokal ortamımızda geliştirmelerimizi sürdürüyor ve “development-test”lerimizi gerçekleştiriyoruz. Bu süreçte de kod kalitemizi ölçümlemek, yükseltmek ve standartlarımızı korumak için StyleCop ve ReSharper ürünlerini kullanmayı tercih ettik. Böylece tüm ekip tarafından bilinen ve takip edilen kod standartları dokümanımıza uygun (%100 çok iddialı tabii ki ancak hedefe çok yakın diyebiliriz) kodlama gerçekleştirebiliyoruz.
Geliştirmemizin bittiğine ve test ekibimiz tarafından “functional-test”e uygun olgunluğa ulaştığını düşündüğümüzde ise test sitesini hazırlamak için “TeamCity” ürününü kullanıyoruz. Bu ürün yardımıyla repository’imize göndermiş olduğumuz geliştirme; otomatik olarak ürün tarafından çekiliyor, derleniyor, bir takım otomasyon testlerinden geçiriliyor, bazı shell script’ler çalıştırılıyor ve sitenin deploy edilebilmesi için “Octopus” adlı ürünümüze gönderiliyor. Bu ürün yardımıyla da ilgili branch’e özel test sitemiz, geliştirme ve test ekibinin hizmetine sunuluyor. Böylece farklı bir branch’te yapılan geliştirmeler o anki teste müdahil olamıyor, konsantrasyon tek bir noktada rahatlıkta toplanabiliyor.
Testten gelen bulguları çöz ve geliştirmeyi sonlandır
Test ekibimizden gelen bulguları çözüyor, gerekli ise bir takım iyileştirmeler yapıyoruz. Bir önceki adımlar hızlıca tekrarlanıyor ve onay aldıktan sonra UAT sürecinin başlaması için genel test ortamımıza entegrasyona başlıyoruz.
Geliştirme branch’imizi, “development” branch’imize merge ediyoruz. Böylece diğer onaylı tüm geliştirmelerle birlikte kendi geliştirmemiz de T anında canlı yayına çıkabilir halde bekliyor.
Canlıya çıkış
Aslında burası kamera arkamızın en keyifli ve bir o kadar stresli tarafı. Evet, tüm geliştirmeler, kendilerine ait test siteleri üzerinden test edildi ve onaylandı. Toplu test ortamımızdan yapılan UAT testlerinden de geçti. Normal şartlar altında herhangi bir sorun olmaması gerekiyor. Genellikle olmuyor da. Ancak zaman zaman bazı geliştirmelerin diğerlerini ezdiğini ya da tüm use-case’lerin test edilemediği ve canlı ortamda bu case’lerin canlanabileceği durumlar oluşabiliyor.
Bu süreçte öncelikle yetkili geliştirici arkadaşlarımız “development” branch’inden “master” branch’ine merge işlemini gerçekleştiriyor. Ardından sistem ekibimizin uzman ellerinden “kırmızı buton”a basmasını talep ediyoruz :)
Octopus tarafından yönetilen bu süreçte öncelikle X adet sunucuya dağıtım sırasıyla gerçekleşiyor. Bu sırada herhangi bir kesinti olmaması için “Load-Balancing” işlemi için kullandığımız ürünün arkasından, dağıtım yapılan sunucuyu geçici olarak çıkartıyor, dağıtım bittikten sonra tekrar ekliyor ve sıradaki sunucuyu devreden çıkartıyoruz.
Kısa bir süre ekranlarımızdan herhangi bir aksaklık olup olmadığını gözlemliyoruz. Çünkü o sırada bazı kullanıcılarımız yeni versiyona ulaşırken bazıları hala bir önceki versiyonu görüyor. Böylece olası bir hata durumunda X kadar sunucuyu hızlı bir şekilde bir önceki versiyona döndürebiliyoruz.
Mutlu Son
Bu süre içerisinde bir sorun gözlemlemez isek (sistem&yazılım ekibi ortak yapımı) kalan X kadar sunucuya da dağıtım işlemini gerçekleştiriyor ve deployment sürecimizi sonlandırıyoruz.
Tahmin edersiniz ki tüm bu süreçler %100 sorunsuz bir şekilde gerçekleşmiyor. Bazı sorunlarımıza hızlıca çözüm bulup uyguluyor, bazen ise bu süreci durdurabiliyoruz. Bunu da yine daha önce vurguladığım “yüz yüze iletişim” ile yürütmeyi tercih ediyoruz. Samimi ve içten bir ekip olmanın birinci koşulunun da bu olduğuna inanıyoruz.
Bu yazıyı kaleme almaya karar vermemin sebebi ise, bu süreçleri yeni yeni yaşamaya başlayan ya da yaşamaya karar veren ekiplere küçük de olsa ışık tutmaya çalışmam idi. Umarım herhangi bir cümlede ya da paragrafta “Aha! Anı” yaratabilmişimdir.
Yazımı sonlandırırken (sanırım sonuca bağlayabildim :)) samimiyetimizi ve eksiklerimizi/fazlalarımızı yansıtan — buradan ifade edebileceğim kadarıyla — bazı diyaloglarımızı sizlerle paylaşmak isterim. Aşağıdakiler gibi onlarca keyifli anıyı biriktirmekten de çok mutlu olduğumu itiraf etmeliyim.
Bir başka yazıda tekrar görüşmek dileğiyle…
NOT: Bu diyaloglardaki hiçbir kişi ve cümle hayal ürünü değildir.
— — — — — — — — — — — — — — — — —
X: Abi css’ler ezilmiş galiba, ok’lar yerine Facebook logosu geliyor!
Y: Olsun, belki yeni bir iş ortaklığını kapısını açmış oluruz.
Kısa bir süre sonra…
Y: Pilot’taki 1.0.0.1 versiyonunu canlıya alabilir miyiz? Sebep: Hot-Fix
— — — — — — — — — — — — — — — — —
X: ABC-1234 geliştirmesini pilot’ta kontrol edebilir miyiz?
Y: Geliştirme pilot’ta görünmüyor.
X: (A kişisine seslenir) ABC-1234 geliştirmesi pilot’ta görünmüyor.
A: Abi imkansız, testte onaylandı.
Kısa bir süre sonra…
A: Development brach’ine merge etmememişim, hemen hallediyorum.
