Merhaba,
Bugün yazdığım bu yazımı universitede okuyan ve yeni mezun genç arkadaşlarıma armağan ediyorum. Benden bu konuda yazmamı çok istediler. Umarım faydalı bulursunuz.
Hergün CI/CD ve/veya DevOps ifadelerini o kadar duyuyor ve o kadar kullanıyoruz ki? Nedir bu iki gizemli kavramın arkasındaki gerçek mana? CI/CD (Continuous Integration/Continuous Delivery), uygulama geliştirme aşamalarımıza otomasyonu ekleyerek uygulamalarımızı müşterilerimize gereken sıklıkta teslim etme yöntemidir. CI/CD’yi türkçe olarak, “sürekli entegrasyon”, “sürekli teslimat” ve “sürekli dağıtım” olarak ifade edebiliriz. CI/CD’yi, aslında yeni kodu entegre ederken geliştirme ve operasyon ekiplerinin yaşayacağı sorunlara çözüm olabilmek adına uygulanan bir süreç olarak tanımlayabiliriz.
CI/CD, bir uygulamanın yaşam döngüsü boyunca, devam eden bir otomasyonu ve sürekli izlemeyi tarifler. Nedir bu uygulama yaşam döngüsü? Bir uygulamanın yaşam döngüsünde, entegrasyon, test, teslimat ve dağıtım aşamaları vardır.
CI/CD içinde yer alan, CI, yani sürekli entegrasyon (continuous Integration), geliştiriciler için otomasyon sürecini anlatır. Yani başarılı bir CI’dan bahsedebilmek için, uygulamaya eklenen her yeni kod değişikliklerinin, düzenli olarak, inşa edilmesi/oluşturulması (build), test edilmesi ve paylaşımlı bir havuzda (repository) tutulması gerekir. Bir uygulamanın aynı anda geliştirme aşamasında olan birbiriyle çelişebilecek bileşenlerinin ouşturabileceği sorunlara karşı bir çözüm olarak geliştirilmiştir.
CI/CD içinde yer alan CD, yani sürekli teslimat (continuous delivery), geliştiricinin uygulamaya eklediği her değişikliğin otomatik olarak hata testlerinin yapılması ve GitHub gibi bir havuza yüklenmesini ifade eder. Operasyon ekibi de, bu havuzdan kodun üretim ortamına dağıtımını yapar. Geliştirme ve iş ekipleri arasındaki görünürlülüğü ve iletişimi geliştirmeyi amaçlayan bir süreçtir. Bu sayede, yeni kodu dağıtmak için minimum çaba sarf edilir.
Diğer bir CD daha var, sürekli dağıtım (continuous deployment), geliştiricinin değişikliklerini, ortak havuzdan üretime otomatik olarak sürümlenmesini/yayınlanmasını anlatır. Yani artık müşterilerin kullanacağı kararlı bir sürüm olarak değişiklikler işlenmiş olur. CD, özellikle, uygulama teslimatını yavaşlatan manuel süreçler nedeniyle zamanı kalmayan operasyon ekip problemlerinin çözümüne odaklanır.
Aslında anlattıklarımızın özet bir görselini, Şekil 1.’de görebiliriz.
Şekil 1. CI/CD Ardışık Düzeni.
CI’de “build, test ve merge” işlemleri var, CD’de havuza otomatik sürüm çıkıyoruz, ikinci CD’de ise üretim ortamına otomatik dağıtım yapıyoruz. “Build”, uygulamanın derlendiği aşamadır. “Test”, kodun test edildiği aşamadır. Buradaki otomasyon hem zamandan hem de emekten tasarruf sağlamaktadır.
CI’in biraz daha detayına inmek istiyorum. Malum, modern uygulamalar için, aynı uygulamanın farklı özelliklerini aynı anda yazan farklı geliştiriciler vardır. Nihayi hedef, tüm bu farklı özellikler bir araya getirildiğinde sağlıklı çalışan bir uygulamaya sahip olabilmektir. Diğer taraftan, eğer yalıtılmış olarak bir geliştirici çalışıyorsa, uygulamada yaptığı bir değişiklik, diğer geliştiricilerin yaptığı değişikliklerle çelişebilir, çakışabilir. Eğer geliştirme ekibi, bulut tabanlı veya on-prem tek bir IDE üzerinde çalışmak yerine, her geliştirici kendi yerel entegre geliştirme ortamını (IDE) kullanıyorsa, elbette bu sorun daha da karmaşık hale gelecektir. Düşünsenize, sık aralıklı olmayan bir düzen dahilinde, hadi kodları bir araya getiriyoruz, birleştiriyoruz dediğimiz süreçte ortaya çıkan iş, sıkıcı, manuel ve zaman alıcı olacaktır. Böyle bir süreç, gereksiz bir şekilde pek çok hataya açık olacaktır. Oysa, CI ile, geliştiriciler günlük olarak, ortak bir havuzda kodlarını birleştirir, uygulama otomatik olarak oluşturulur, değişikliklerin uygulamayı bozmadığından emin olmak için farklı düzeylerde birim ve entegrasyon testleri çalıştırılır. Bu sayede, uygulamayı oluşturan tüm modüller, test edilebilir en ince birimlerine kadar test edilmiş olur. Eğer otomatik test süreci, mevcut kod ile yeni kod arasında bir çelişki keşfederse, CI süreci sayesinde, hatalar hızlı bir şekilde düzeltilir.
CI’da uygulamayı inşa etmeyi otomatikleştirdik, birim ve entegrasyon testlerini otomotize bir şekilde yaptık, CD’de, doğrulanmış kodumuzu ortak havuzumuzda artık otomatik olarak sürümlüyoruz/yayınlıyoruz. Dolayısıyla, etkili bir CD için, uygulama yaşam döngüsü için zaten planlanmış bir CI’ın yerleşik bir şekilde çalışır olmasını sağlamamız gerekir. CD yani sürekli teslimin amacı, bir anlamda, üretim ortamına dağıtmak için her daim hazır olan bir kod tabanına sahip olmaktır diyebiliriz. Sürekli teslimde, kod değişikliklerinin birleştirilmesinden “üretime hazır yapıların” teslimine kadar her aşama, test ve kod yayınlama otomasyonunu içerir. Bu sürecin sonunda, operasyon ekibi, uygulamayı üretime hızlı ve kolay bir şekilde dağıtabilir.
İyi tasarlanmış bir CI/CD ardışık sürecinin son aşaması sürekli dağıtımdır, ikinci CD. Sürekli teslimat, üretime hazır bir yapının bir kod deposuna yayınlanmasını otomatikleştirirken, sürekli dağıtım, bir uygulamanın üretim ortamına yayınlanmasını/dağıtılmasını otomatikleştirir. Sürekli dağıtım, iyi tasarlanmış test otomasyonunu gerektirir. Pratikte, sürekli dağıtım, bir geliştiricinin bir bulut uygulamasında yaptığı değişikliğin yazıldıktan sonra dakikalar içinde yayınlanabileceği anlamına gelir. Bu, sürekli olarak kullanıcı geri bildirimi almayı ve kullanıcıyı sürece dahil etmeyi çok daha kolay hale getirir. CI/CD birlikte ele alındığında, bu ardışık süreçler, bir uygulamanın dağıtımını daha az riskli hale getirir. Böylece, uygulamalardaki değişiklikleri bir kerede değil, küçük parçalar halinde yayınlayabiliriz. Bununla birlikte, CI/CD hattındaki çeşitli test ve yayın aşamalarını tanımlamak için otomatik testlerin yazılması gerekeceğinden, sağlıklı bir CI/CD tasarımı, beraberinde ön çalışma yapılmasını da gerekli kılar.
Umarım, sürekli entegrasyon, sürekli teslimat ve sürekli dağıtım, biraz daha anlaşılır olmuştur. Iyi güzel, kavramsal olarak biraz olsun anladık, fakat hangi araçlarla biz bu süreçleri, bu işlem hattını oluşturacağız?
CI/CD araçları, bir ekibin geliştirme, dağıtım ve test süreçlerini otomatikleştirmesine yardımcı olur. Bazı araçlar özellikle sürekli entegrasyon (CI) tarafını ele alırken, bazıları geliştirme ve dağıtımı (CD) yönetir, bazıları ise sürekli test ihtiyacı için uzmanlaşır.
CI/CD için en iyi bilinen açık kaynak araçlarından biri otomasyon sunucusu Jenkins’dir. Jenkins, basit bir CI sunucusundan eksiksiz bir CD hub’ına kadar her şeyi işlemek için tasarlanmıştır. Elbette ekipler, çeşitli satıcılardan temin edilebilen CI/CD araçlarını da değerlendirmek isteyebilir. Büyük genel bulut sağlayıcılarının tümü, GitLab, CircleCI, Travis CI, Atlassian Bamboo ve daha pek çoğu CI/CD çözümleri sunmaktadır.
Gördüğünüz gibi yazıda en çok geçen kelimeler, otomasyon, otomatize, otomatikleştirme. Bu noktada DevOps’un hayatımıza neden bu kadar çok girdiğini anlıyoruz. DevOps otomasyonu, düzenli güncellemelerin üretimdeki uygulamalara daha hızlı dağıtılabilmesi için operasyon ve geliştirme ekipleri arasındaki geri bildirim döngülerini kolaylaştıran süreçlere, manuel süreçleri minimuma indirgeyecek şekilde, görevleri otomatik gerçekleştiren teknolojinin eklenmesidir.
DevOps, bir kültürdür. Otomasyon ve platform tasarımına yönelik bir yaklaşımdır. Öyle ki, hızlı, yüksek kalitede hizmet sunabilmeye ve verimli iş değeri oluşturabilmeye bir cevap olarak gelişmiştir. DevOps geliştirme ve operasyon ekibi üyelerini tek bir DevOps ekibinde bir araya getirir. Bu güçlü tek ekip, fikirleri ve projeleri, geliştirme aşamasından üretim aşamasına daha hızlı ve verimli bir şekilde taşır. DevOps, geleneksel manuel yönetim stratejilerine kıyasla kodda daha sık değişiklik yapılmasını ve daha dinamik altyapı kullanımını da beraberinde getirir.
Otomasyon ise, görevleri daha az insan yardımı ile gerçekleştirmek için teknolojinin kullanılmasını tanımlar. Otomasyon, süreçleri hızlandırmanıza ve ortamları ölçeklendirmenize ve ayrıca sürekli entegrasyon, sürekli teslim ve sürekli dağıtım (CI/CD) iş akışları oluşturmanıza yardımcı olur. BT otomasyonu, iş otomasyonu, robotik süreç otomasyonu, endüstriyel otomasyon, yapay zeka, makine öğrenimi ve derin öğrenme dahil olmak üzere birçok otomasyon türü vardır.
Ek olarak, DevOps için temel oluşturan herhangi bir araç, CI/CD sürecinin bir parçasıdır. Örneğin konfigürasyon otomasyonu araçları (Ansible, Chef ve Puppet gibi), konteyner çalışma zamanları (Docker, rkt ve cri-o gibi). Konteyner düzenleme araçları örneğin Kubernetes, bir CI/CD aracı değildir fakat birçok CI/CD iş akışında bulunur. Neden? CI/CD, OpenShift Konteyner Platformu için popüler kullanım durumlarından biridir.
OpenShift, tam bir dağıtım işlem hattı oluşturmak için uçtan uca bir çözüm sunar. Kutudan hazır çıkan işlem hattı aracılığıyla kod ve yapılandırma değişikliklerini yönetmek için gerekli olan otomasyonu sağlar. Tekton, bulutta CI/CD işlem hatlarını hızla oluşturmak için bir yapı sağlayan açık kaynaklı bir projedir. Tekton, birden çok bulut sağlayıcısı veya hibrit ortam arasında devreye almayı kolaylaştırmaktadır. Tekton, Jenkins, Jenkins X, Skaffold, Knative ve Red Hat OpenShift ile çok uyumlu çalışır. OpenShift, konteyner olarak çalışan ve isteğe bağlı olarak ölçeklenebilen işlem hatlarını tanımlamak için standart Tekton CRD’leri (custom resource definition) kullanır. Konteynerleştirme bildiğiniz gibi yazılım geliştirmedeki en son trenddir. Konteynerler, yazılımınızın ortamdan bağımsız olmasını sağlarken, aynı zamanda, genellikle “yerel bulut” olarak adlandırılan, ortamlar arasında da tutarlı davranış sergilerler. OpenShift, bulut tabanlı uygulamaların dağıtımını ve operasyonlarını geniş ölçekte otomatikleştiren açık kaynaklı bir bulut platformudur. CI/CD iş akışları ve yerel bulut sistemlerinin birkaç ortak hedefi vardır: her ikisi de geliştirme hızını artırmaya, yazılım kalitesini optimize etmeye ve çalışabilirliğini korumaya çalışır. CI/CD, kodun geliştirildiği andan üretimde yayınlandığı noktaya kadar birçok adımı otomatikleştirir. Benzer şekilde OpenShift, çeşitli altyapı ortamlarında konteyner dağıtımlarını otomatikleştirir ve verimli kaynak kullanımını sağlar. Bu nedenle, kuruluşların Kubernetes platformundan yararlanan CI/CD ardışık düzenleri kurması doğal olarak mantıklıdır.
Bugün yazımda, CI/CD işlem hattının ne anlama geldiğini aktarmaya çalıştım. CI/CD sürecinde DevOps’un rolü, neden CI/CD süreçlerinin/ardışık düzenlerinin artık Kubernetes temelli teknolojilerle yapılandırıldığını genel olarak anlatmaya çalıştım. Umarım bir nebze de olsa akıllardaki soru işaretlerini giderebilmişimdir.
Sarav Asiye Yiğit – 31 Ekim 2021 Pazar
Kaynakça:
https://www.redhat.com/en/topics/devops/what-cicd-pipeline
https://www.redhat.com/en/topics/devops/what-is-ci-cd
https://www.redhat.com/en/engage/ansible-pipelines-whitepaper-s-202012162024
https://www.redhat.com/en/topics/automation/what-is-devops-automation
https://cloud.redhat.com/blog/cicd-with-openshift
https://www.redhat.com/en/technologies/cloud-computing/openshift/ci-cd
https://ubuntu.com/blog/kubernetes-ci-cd-pipelines-what-why-and-how
Leave A Comment