CI/CD Nedir? DevOps Engineer ne iş yapar?
Merhabalar,
Bu yazımda günümüz yazılım geliştirme süreçlerinin olmazsa olmaz bir parçası haline gelen CI/CD kavramlarından ve bu kavramlarla bağlantılı DevOps alanından bahsedeceğim.
Konuların detaylarına inmeden önce sizden kod yazarken ya da test ederken (bu kişisel ya da şirketiniz yazdığınız bir kod ya da test olabilir) hangi aşamalardan geçtiğinizi bir düşünmenizi isteyeceğim. Kısaca yaptıklarınızı bir gözünüzün önünden geçirebilirseniz yazının devamında anlatacağım konuların tam olarak sizin yazılım geliştirme senaryonuzda nereye denk düştüğünü daha iyi anlayabileceğinizi düşünüyorum.
O halde başlayalım.
Continuous Integration (CI — “Sürekli Entegrasyon”) Nedir?
Codebase üzerinde herhangi bir noktada yaptığımız değişikliklerin belirli senaryolarda (pull/merge request açılması, merge işlemi tamamlandığında vb. ) otomatik olarak çeşitli kalite kontrol süreçlerinden geçmesi işlemine Continuous Integration diyoruz. Burada otomatik kelimesini vurgulamamın özel bir anlamı var elbette.
Yazının başında sizden yazılım geliştirme süreçlerinizi düşünmenizi istemiştim. Muhtemelen ilk aklınıza gelen kısımlardan birisi de “test” konusudur diye düşünüyorum. Kendi bilgisayarınızda test yaparken muhtemelen manüel bir tetikleme (bir komut çalıştırma ya da IDE/Text Editor üzerinde bir butona basma) ile yazdığınız testleri çalıştırıyorsunuz. Bu da doğal olarak bazı durumları gözden kaçırmamıza neden olabiliyor. İşte tam da bu noktada yardımımıza CI araçları koşuyor ve bizim üzerimizdeki bu manüel test yükünü alıp otomatikleştiriyor. Zaten bu yüzden isminin başında “Continuous” (“Sürekli”) var. Ayrıca bu araçlar sayesinde kendi bilgisayarımızda çalıştıramadığımız (farklı işletim sistemi ve işlemci mimarilerindeki test senaryoları gibi) ya da çok zaman alacağı (kullandığımız araçların farklı sürümlerinde de test çalıştırmak gibi) için çalıştırmak istemediğimiz testleri de çalıştırabilir hale geliyoruz.
Elbette ki CI araçları sadece test otomasyonu konusuna yardımcı olmazlar. Aynı zamanda kod kalitesini ölçmek, olası güvenlik zafiyetlerini taramak, performans ölçümleri yapmak gibi senaryoları da CI süreçlerimizin içerisine dahil edebiliyoruz.
Continuous Deployment — (CD — “Sürekli Dağıtım”) Nedir?
Codebase üzerinde belirli noktalarda yapılmış geliştirmelerin, belirli senaryolarda çeşitli sunucu ortamlarına (production, staging, test vb.) otomatik olarak gönderilmesi işlemine Continuous Deployment diyoruz. CD, aslında CI süreçlerinden bağımsız bir yapı değil. Birçok kullanım senaryosunda CI süreçlerinin hemen ardından çeşitli onayların gelmesiyle birlikte CD süreçleri başlar.
Continuous Deployment ve Continuous Delivery çoğunlukla karıştırılan iki benzer kavramdır. Aralarındaki fark ise Continuous Delivery’de sürecin başlayabilmesi için manuel bir tetikleme gelirken, Continuous Deployment belirli kurallara göre otomatik tetiklenen bir süreçtir.
Baştan sona bir CI/CD kullanımını senaryosuna şöyle bir örnek verebiliriz:
- feature/ branch’inde yeni bir özellik geliştirip bunu GitHub’a gönderdiniz. Burada commit ile ilgili CI süreçleri çalışıyor.
- feature branch’ini develop’a göndermek için bir pull request açtığınız. Burada da pull request ile ilgili CI süreçleri (testler, kod kontrolleri vb.) çalışıyor.
- Pull Request ile ilgili CI süreçleri başarılı tamamlandıysa artık pull request’iniz merge edilebilir demektir.
- Merge işlemi yaptığınızda da develop branch’i için CI ve CD süreçleri başlıyor.
- develop branch’i için de CI süreçleri çalışıyor ve hemen ardından CD süreçleri başlıyor. Burada genellikle develop branch’i test ya da staging ortamınıza deploy olur.
- Bu şekilde birkaç özellik daha geliştirdiğiniz ve şu an hepsi develop branch’inde bekliyor.
- develop branch’ini master’a göndermek için bir pull request açtığınız. Yine CI süreçleri çalıştı.
- CI süreçleri başarılı olduktan sonra da merge işlemini gerçekleştirdiniz ve bu da CD süreçlerini tetikledi ve çalışmalarınız production ortamına deploy edildi.
Bu şekilde baştan sona bir CI/CD akışını görmüş olduk.
Popüler CI/CD araçlarından bazılarını şu şekilde listeleyebiliriz:
DevOps Engineer Ne İş Yapar?
Şirket içerisindeki tüm CI/CD süreçlerinin yönetimi, geliştirme ortamlarında ihtiyaç duyulan araçların geliştirilmesi, production ve test sunucularının bakımını ve ayakta kalmasını sağlamak vb. işleri üstlenen kişilere DevOps Engineer diyoruz. Aslında eskilerin daha çok bildiği SysAdmin rolünün günümüzdeki daha farklı bir karşılığı diyebiliriz.
DevOps Engineer’lar, yazılım geliştiriciler tarafından hazırlanmış ve paketlenmiş uygulamaların koşacağı zemini hazırlıyor ve bu zemini sürekli olarak gözlem altında (Monitoring) tutuyorlar. Her ne kadar Monitoring konusu daha genel bir kapsam olan “Observability” adı altında, yeni duymaya başladığımız Site Reliability Engineer rolüne geçmeye başladıysa da henüz birçok organizasyonda monitoring işi de çoğunlukla DevOps takımları tarafından yönetiliyor. SRE ve Observability konularıyla ilgili Google’ın şu web sitesini ziyaret edebilirsiniz. İçerisinde ücretsiz okuyabileceğiniz kitap ve çeşitli eğitim materyalleri mevcut.
DevOps Engineer olmak ya da bu alana geçiş yapmak isteyenler için izlemeniz gereken yol haritası için bu bağlantıyı inceleyebilirsiniz. Fakat özel olarak söylemeden geçemeyeceğim, aslında sadece DevOps Engineer’ın değil de geliştirme yapan hemen herkesin mutlaka GNU/Linux işletim sistemleri hakkında bilgi sahibi olması gerektiğini düşünüyorum. Nedenlerini belki başka bir yazımda açıklarım.
DevOps Kültürü Nedir?
Geliştirme ve DevOps takımlarının sadece kendi alanlarıyla ilgili değil birbirlerinin alanlarıyla ilgili de bilgi sahibi olduğu ve yer yer sorumluluk alabildiği duruma “DevOps Kültürü” diyoruz.
İlk bakışta her ne kadar yazılımın üzerinde çalıştığı sistemin sorumluluğu tamamen DevOps Engineer’da gibi gözükse de aslında öyle değil. Geliştiricinin de, yazılımın çalıştığı sistem hakkında bilgi sahibi olması, kodunu buna göre optimize etmesi (bellek ve cpu kullanımı vb.) gerekir. Aynı şekilde DevOps takımının da geliştiricilerin ihtiyaçlarını doğru analiz etmeli ve sistemi buna göre ayakta tutmalı. İşte bu karşılıklı bilgi ve sorumluluk paylaşımı durumu ancak şirket içerisinde bir “DevOps Kültürü”nün oluşması ile mümkün olabiliyor.
Elbette DevOps yapılanmasının ilk gününden itibaren böyle bir kültürün oluşmasını beklemek doğru olmaz. Zaten “kültür” kelimesinin TDK anlamına baktığınızda da “Tarihsel, toplumsal gelişme süreci içinde yaratılan” ifadesi dikkatinizi çekecektir. Yalnız, kültürün hemen oluşmasını beklemek ne kadar yanlış ise “zamanla kendiliğinden oluşur zaten” demek de bir o kadar yanlış bir davranış olur. “DevOps Kültürü”nün ortaya çıkması için gerekli ortamın hazırlanması ve aksiyonların alınması bu sürecin başlatıcısı ve hızlandırıcısı olacaktır. Bu konuyla ilgili içeride DevOps takımı bulunan büyük şirketlerin blog sayfalarındaki yazıları okumanızı tavsiye ederim ama her şeyden önce kültürün en önemli parçalarından birinin “empati” olduğunu unutmayalım. Takımların birbiriyle empati kurabileceği bir ortamın yaratılması DevOps kültürünün oluşmasının önündeki en büyük engellerden birini kaldırmış olacaktır.
Bir sonraki yazımızda görüşmek üzere,
Esen kalın,
