CI/CD İçin Sunucu Ortamı Hazırlama (Jenkins ile)

Modern yazılım geliştirme süreçleri, hız ve verimlilik üzerine kuruludur. Bu süreçlerin bel kemiğini oluşturan CI/CD (Sürekli Entegrasyon ve Sürekli Dağıtım/Teslimat), otomasyon sayesinde geliştiricilerin kod değişikliklerini hızlı ve güvenilir bir şekilde kullanıcılara ulaştırmasını sağlar. Bu otomasyonun merkezinde ise genellikle Jenkins gibi güçlü araçlar yer alır. Jenkins, açık kaynak kodlu bir otomasyon sunucusudur ve yazılımın derlenmesinden test edilmesine, paketlenmesinden dağıtımına kadar tüm yaşam döngüsünü otomatikleştirmek için kullanılır. Doğru yapılandırılmış bir Jenkins sunucusu, geliştirme ekiplerinin zaman alan manuel işlemleri ortadan kaldırarak daha yaratıcı ve önemli görevlere odaklanmasına olanak tanır. Bu makalede, CI/CD süreçleri için sağlam bir temel oluşturacak şekilde bir sunucu ortamının nasıl hazırlanacağını ve Jenkins’in bu ortama nasıl kurulup yapılandırılacağını adım adım ele alacağız.

CI/CD ve Jenkins’e Giriş

Yazılım geliştirme dünyasında rekabet avantajı elde etmek, kaliteli kodu mümkün olan en kısa sürede son kullanıcıya ulaştırmaktan geçer. CI/CD metodolojisi, bu hedefe ulaşmayı sağlayan modern bir yaklaşımdır. Bu bölüm, CI/CD’nin temel taşlarını ve bu süreçlerde Jenkins’in neden kilit bir rol oynadığını açıklamaktadır.

Sürekli Entegrasyon (Continuous Integration – CI) Nedir?

Sürekli Entegrasyon, birden fazla geliştiricinin üzerinde çalıştığı bir projede, kod değişikliklerinin düzenli olarak merkezi bir depoda (repository) birleştirilmesi ve otomatik olarak derlenip test edilmesi sürecidir. Her bir geliştirici, yaptığı değişikliği ana kod tabanına entegre ettiğinde, bir otomasyon aracı bu değişikliği algılar, projeyi derler ve önceden tanımlanmış test senaryolarını çalıştırır. Bu yaklaşımın temel amacı, entegrasyon sorunlarını erken aşamada tespit etmek ve çözmektir. Böylece, projenin ilerleyen aşamalarında ortaya çıkabilecek büyük ve karmaşık birleştirme (merge) problemlerinin önüne geçilir ve kod kalitesi sürekli olarak yüksek tutulur.

Sürekli Dağıtım/Teslimat (Continuous Delivery/Deployment – CD) Nedir?

Sürekli Teslimat (Continuous Delivery), CI sürecini bir adım öteye taşıyarak, başarılı bir şekilde test edilen kod değişikliklerinin otomatik olarak bir “üretim benzeri” (staging) ortama dağıtılmasını sağlar. Bu aşamada kod, son kullanıcıya sunulmaya tamamen hazırdır. Dağıtım kararı ise genellikle manuel bir onayla verilir. Sürekli Dağıtım (Continuous Deployment) ise bu süreci daha da otomatikleştirir. Başarılı olan her kod değişikliği, herhangi bir manuel müdahaleye gerek kalmadan doğrudan üretim (production) ortamına, yani son kullanıcıya ulaştırılır. Bu iki pratik arasındaki temel fark, üretim ortamına geçişin manuel bir tetiklemeyle mi yoksa tamamen otomatik olarak mı yapıldığıdır. Her ikisi de yazılım teslimat sürecini hızlandırır ve riski azaltır.

Jenkins Nedir ve CI/CD Süreçlerindeki Rolü

Jenkins, Java tabanlı, açık kaynak kodlu ve oldukça popüler bir otomasyon sunucusudur. Geniş eklenti (plugin) ekosistemi sayesinde, yazılım geliştirme yaşam döngüsündeki hemen her görevi otomatikleştirebilir. CI/CD süreçlerinde Jenkins, merkezi bir orkestratör görevi görür. Kod deposundaki değişiklikleri izler, CI sürecini tetikler (derleme, test), başarılı olursa CD sürecini başlatır (paketleme, dağıtım) ve sonuçlar hakkında ekibe bildirimler gönderir. Esnek yapısı, farklı programlama dilleri, test framework’leri ve dağıtım ortamları ile kolayca entegre olabilmesini sağlar. Bu nedenle Jenkins, CI/CD pipeline’larını (iş akışlarını) oluşturmak ve yönetmek için endüstri standardı haline gelmiş araçlardan biridir.

Otomasyonun Yazılım Geliştirme Sürecine Katkıları

Otomasyon, CI/CD’nin temel taşıdır ve yazılım geliştirme sürecine devrim niteliğinde katkılar sunar. Manuel olarak yapılan tekrarlayıcı görevlerin (derleme, test çalıştırma, sunucuya dosya kopyalama vb.) makinelere devredilmesi, insan hatası riskini minimize eder. Bu sayede süreçler daha tutarlı, güvenilir ve hızlı hale gelir. Geliştiriciler, zamanlarını kodlama ve problem çözme gibi daha yaratıcı işlere ayırabilirler. Otomasyon, geri bildirim döngüsünü de önemli ölçüde kısaltır; bir kod değişikliğinin neden olduğu bir hata, dakikalar içinde tespit edilebilir. Bu da daha hızlı problem çözümü, daha yüksek yazılım kalitesi ve sonuç olarak daha fazla müşteri memnuniyeti anlamına gelir.

Sunucu Ortamı İçin Ön Hazırlıklar ve Gereksinimler

Jenkins’in verimli ve kesintisiz çalışabilmesi için üzerine kurulacağı sunucu ortamının doğru yapılandırılması kritik öneme sahiptir. Performans sorunları yaşamamak ve gelecekteki ihtiyaçları karşılayabilmek adına donanım, işletim sistemi ve temel yazılımların dikkatlice seçilmesi gerekir. Bu bölüm, ideal bir Jenkins sunucu ortamı için yapılması gereken ön hazırlıkları detaylandırmaktadır.

Donanım Özelliklerinin Belirlenmesi (CPU, RAM, Disk)

Jenkins sunucusunun donanım gereksinimleri, üzerinde çalışacak iş (job) sayısı, bu işlerin karmaşıklığı ve aynı anda çalışacak pipeline sayısı gibi faktörlere bağlıdır. Genel bir başlangıç noktası olarak aşağıdaki özellikler önerilebilir:

• CPU: Küçük ve orta ölçekli projeler için 2-4 vCPU yeterli olabilir. Ancak aynı anda çok sayıda derleme veya test işlemi yapılacaksa, 8 vCPU veya daha fazlası gerekebilir.
• RAM: Jenkins’in kendisi ve çalıştırdığı süreçler için bellek hayati önem taşır. Minimum 4 GB RAM önerilir, ancak orta ve büyük ölçekli ortamlar için 8 GB ile 16 GB arası veya daha fazlası idealdir. Özellikle Docker gibi konteyner teknolojileri kullanılacaksa RAM ihtiyacı artacaktır.
• Disk: Jenkins, iş geçmişlerini, artifact’leri (çıktı dosyaları) ve çalışma alanlarını diskte saklar. Bu nedenle hızlı bir disk (SSD) performansı önemli ölçüde artırır. Başlangıç için en az 50 GB disk alanı önerilir, ancak projelerin büyüklüğüne ve artifact saklama politikalarına göre bu ihtiyaç yüzlerce GB’ı bulabilir.

İşletim Sistemi Seçimi ve Kurulumu (Ubuntu/CentOS Önerileri)

Jenkins, Java’nın çalıştığı hemen her işletim sisteminde çalışabilir. Ancak sunucu ortamlarında kararlılıkları, geniş topluluk destekleri ve paket yönetim kolaylıkları nedeniyle Linux dağıtımları sıklıkla tercih edilir. Özellikle Ubuntu Server ve CentOS (veya Rocky Linux/AlmaLinux gibi türevleri), Jenkins kurulumu için en popüler ve iyi belgelenmiş seçeneklerdir. Her iki işletim sistemi de Jenkins için resmi paket depoları sunarak kurulum ve güncellemeleri oldukça basit hale getirir. Seçim, genellikle sistem yöneticisinin aşinalığına ve kurumsal standartlara bağlıdır.

Gerekli Temel Yazılımların Kurulumu

Jenkins’in çalışabilmesi ve CI/CD görevlerini yerine getirebilmesi için bazı temel yazılımların sunucuda önceden kurulu olması gerekir. Bu yazılımlar, pipeline’ların temel yapı taşlarını oluşturur.

Java Development Kit (JDK)

Jenkins, bir Java uygulaması olduğu için çalışmak üzere bir Java Runtime Environment (JRE) veya Java Development Kit (JDK) gerektirir. Jenkins’in farklı sürümleri, belirli Java sürümlerini zorunlu kılabilir. Genellikle, en son LTS (Long-Term Support) sürümlerinden olan Java 11 veya Java 17’nin kurulması tavsiye edilir. Kurulum, işletim sisteminin paket yöneticisi (apt veya yum) kullanılarak kolayca yapılabilir.

Git Versiyon Kontrol Sistemi

CI/CD süreçlerinin neredeyse tamamı, bir versiyon kontrol sistemindeki kod değişikliklerini temel alır. Git, bu alanda endüstri standardıdır. Jenkins’in kod deposundan (repository) kaynak kodu çekebilmesi (checkout) için Git’in sunucuda kurulu olması zorunludur. Ayrıca, pipeline’lar içinde Git komutlarını çalıştırmak için de gereklidir. Git kurulumu da yine paket yöneticileri aracılığıyla basit bir komutla gerçekleştirilebilir.

Docker ve Docker Compose

Modern CI/CD süreçleri, büyük ölçüde konteyner teknolojilerinden faydalanır. Docker, uygulamaları ve bağımlılıklarını izole konteynerler içinde derlemeye, test etmeye ve dağıtmaya olanak tanır. Bu, “benim makinemde çalışıyordu” sorununu ortadan kaldırır ve tutarlı ortamlar sağlar. Jenkins pipeline’ları içinde Docker imajları oluşturmak, çalıştırmak ve yönetmek için Jenkins sunucusuna Docker Engine’in kurulması şiddetle tavsiye edilir. Docker Compose ise çoklu konteyner uygulamalarını yönetmeyi kolaylaştıran bir araçtır ve karmaşık test ortamları kurmak için kullanılabilir.

Güvenlik Duvarı (Firewall) ve Port Yapılandırması

Sunucu güvenliği, hazırlık aşamasının en önemli adımlarından biridir. Bir güvenlik duvarı (firewall), sunucuya gelen ve giden ağ trafiğini kontrol ederek yetkisiz erişimleri engeller. Jenkins için en az iki temel portun dış dünyaya açılması gerekir:

• 8080/TCP: Jenkins web arayüzünün varsayılan portudur. Kullanıcıların Jenkins’e tarayıcı üzerinden erişmesi için bu porta izin verilmelidir. Güvenlik nedeniyle bu port, bir reverse proxy (Nginx, Apache vb.) arkasında 80 veya 443 portuna yönlendirilebilir.
• 22/TCP (SSH): Sunucuya uzaktan yönetim için erişim sağlamak amacıyla SSH portunun açık olması gerekir. Güvenliği artırmak için bu porta sadece belirli IP adreslerinden erişim izni verilmesi önerilir.

Ayrıca, Jenkins agent’larının (slave) master sunucuya bağlanması için ek portların (genellikle JNLP için 50000/TCP) yapılandırılması gerekebilir.

Jenkins’in Kurulumu ve İlk Yapılandırması

Sunucu ortamı hazırlandıktan sonraki adım, Jenkins’i kurmak ve temel ayarlarını yapmaktır. Bu aşama, Jenkins’in güvenli ve işlevsel bir şekilde çalışmasını sağlamak için kritik öneme sahiptir. Kurulum için birden fazla yöntem bulunsa da her biri farklı avantajlar sunar. İlk yapılandırma sihirbazı ise Jenkins’i kullanıma hazır hale getiren temel adımları içerir.

Jenkins Kurulum Yöntemleri

Jenkins’i kurmanın birkaç yolu vardır. En yaygın kullanılan iki yöntem, paket yöneticisi ve Docker konteyneridir. Seçim, mevcut altyapınıza ve yönetim tercihlerinize bağlıdır.

Paket Yöneticisi Kullanarak Kurulum (apt, yum)

Bu yöntem, en geleneksel ve basit kurulum yöntemlerinden biridir. Ubuntu için `apt`, CentOS için `yum` gibi işletim sistemine özgü paket yöneticileri kullanılır. Bu yaklaşımın avantajları şunlardır:

• Kolay Kurulum ve Güncelleme: Jenkins’i bir servis olarak sisteme kurar ve basit komutlarla (`apt-get upgrade jenkins` gibi) güncellenmesini sağlar.
• Sistem Entegrasyonu: Jenkins, sistem başlangıcında otomatik olarak çalışan bir servis (`systemd` servisi) olarak yapılandırılır.
• Basit Yönetim: Servisi başlatmak, durdurmak ve durumunu kontrol etmek standart Linux komutlarıyla yapılır.

Kurulum için öncelikle Jenkins’in resmi paket deposunun sisteme eklenmesi, ardından paket yöneticisi aracılığıyla kurulumun yapılması gerekir.

Docker Konteyneri Olarak Çalıştırma

Jenkins’i bir Docker konteyneri olarak çalıştırmak, modern ve esnek bir yaklaşımdır. Docker, Jenkins’i ve tüm bağımlılıklarını izole bir ortamda çalıştırarak ana sunucu işletim sisteminden ayırır. Avantajları:

• Taşınabilirlik: Docker imajı sayesinde Jenkins ortamı, Docker’ın çalıştığı herhangi bir sunucuya kolayca taşınabilir.
• İzolasyon: Jenkins’in kullandığı Java sürümü veya diğer kütüphaneler, ana sunucudaki diğer uygulamalarla çakışmaz.
• Kolay Sürüm Yönetimi: Farklı Jenkins sürümlerini denemek veya geri almak, sadece ilgili Docker imajını çalıştırmak kadar basittir.

Jenkins’in resmi Docker imajı (`jenkins/jenkins:lts`) kullanılarak tek bir komutla Jenkins konteyneri başlatılabilir. Verilerin kalıcı olması için Jenkins home dizininin bir Docker volume’ü olarak ayarlanması önemlidir.

İlk Kurulum Sihirbazının Tamamlanması

Jenkins ilk kez başlatıldığında, tarayıcı üzerinden `http://sunucu_ip:8088` adresine gidildiğinde bir kurulum sihirbazı kullanıcıyı karşılar. Bu sihirbaz, temel güvenlik ve eklenti ayarlarını yapmanızı sağlar.

Yönetici Parolasının Alınması

Güvenlik amacıyla, sihirbazın ilk adımı sizden bir başlangıç yönetici parolası girmenizi ister. Bu parola, Jenkins’in sunucuda belirttiği bir dosya içinde (`/var/lib/jenkins/secrets/initialAdminPassword` gibi) bulunur. Bu dosyayı `cat` komutuyla okuyarak parolayı alıp web arayüzündeki ilgili alana yapıştırmanız gerekir. Bu adım, sadece yetkili kullanıcının kurulumu yapabildiğinden emin olmak içindir.

Temel Eklentilerin (Plugins) Yüklenmesi

Parolayı girdikten sonra Jenkins, size iki seçenek sunar: “Install suggested plugins” (Önerilen eklentileri yükle) ve “Select plugins to install” (Yüklenecek eklentileri seç). Yeni başlayanlar için genellikle önerilen eklentileri yüklemek en iyi seçenektir. Bu seçenek; Pipeline, Git, SSH, e-posta bildirimi gibi CI/CD süreçleri için gerekli olan temel eklentileri otomatik olarak kurar. Deneyimli kullanıcılar ise ihtiyaçlarına göre özel bir eklenti seti seçebilirler.

İlk Yönetici Hesabının Oluşturulması

Eklentiler yüklendikten sonra, Jenkins’i yönetmek için kullanılacak ilk yönetici hesabını oluşturmanız istenir. Kullanıcı adı, parola, tam ad ve e-posta adresi gibi bilgileri girerek kendi yönetici hesabınızı oluşturursunuz. Bu adımdan sonra, başlangıçtaki geçici parola yerine bu yeni hesapla Jenkins’e giriş yapacaksınız.

Jenkins Global Sistem Ayarları (Manage Jenkins)

Kurulum sihirbazı bittikten sonra, Jenkins’in daha detaylı ayarlarını yapmak için “Manage Jenkins” (Jenkins’i Yönet) bölümüne gidilir. Burası, Jenkins’in merkezi kontrol panelidir.

Global Araçların Yapılandırılması (JDK, Git, Maven vb.)

“Global Tool Configuration” bölümü, Jenkins’in pipeline’larda kullanacağı temel araçların yollarını ve sürümlerini tanımladığınız yerdir. Örneğin, sistemde birden fazla JDK sürümü kuruluysa, projelere özel olarak hangisinin kullanılacağını buradan belirleyebilirsiniz. Aynı şekilde, Git, Maven, Gradle, Node.js gibi derleme ve geliştirme araçlarının yollarını da burada yapılandırabilirsiniz. Bu sayede, Jenkinsfile içinde bu araçlara sadece isimleriyle referans vermek yeterli olur.

E-posta ve Bildirim Ayarlarının Yapılması

CI/CD süreçlerinde geri bildirim hayati önem taşır. Jenkins’in pipeline sonuçları (başarılı, başarısız vb.) hakkında ekibe bildirim gönderebilmesi için e-posta sunucu ayarlarının yapılması gerekir. “Configure System” altında bulunan “E-mail Notification” bölümünde, SMTP sunucu adresi, port, kullanıcı adı ve parola gibi bilgiler girilir. Bu ayarlar yapıldıktan sonra, projelerde e-posta bildirimleri kolayca aktif hale getirilebilir.

Güvenlik Ayarlarının Gözden Geçirilmesi

“Configure Global Security” bölümü, Jenkins’in güvenlik altyapısını yönettiğiniz yerdir. Burada, kimlerin Jenkins’e erişebileceği, kullanıcıların yetkileri, CSRF koruması gibi kritik ayarlar bulunur. Varsayılan olarak, giriş yapmış kullanıcıların her şeyi yapmasına izin verilir. Ancak kurumsal ortamlarda, rol tabanlı yetkilendirme (Role-based Authorization Strategy eklentisi ile) gibi daha granüler güvenlik modellerinin yapılandırılması şiddetle tavsiye edilir.

Jenkins Temel Bileşenleri ve Kavramları

Jenkins’i etkili bir şekilde kullanabilmek için temel mimarisini ve kavramlarını anlamak önemlidir. Projeler (Jobs), pipeline’lar, eklentiler ve agent’lar, Jenkins ekosisteminin temel yapı taşlarıdır. Bu bileşenlerin her biri, CI/CD süreçlerinizi esnek ve ölçeklenebilir bir şekilde yönetmenize olanak tanır.

Jenkins Proje (Job) Türleri

Jenkins’te otomatize edilecek her bir görev veya iş akışı bir “Proje” (veya “Job”) olarak tanımlanır. Jenkins, farklı ihtiyaçlara yönelik çeşitli proje türleri sunar. En yaygın kullanılanlar şunlardır:

Freestyle Project

Freestyle, en temel ve klasik Jenkins proje türüdür. Web arayüzü üzerinden adım adım yapılandırılır. Kaynak kod yönetimi, derleme tetikleyicileri, derleme adımları (örneğin, shell script veya Windows batch komutları çalıştırma) ve derleme sonrası eylemler (raporlama, bildirim gönderme vb.) gibi seçenekleri formlar aracılığıyla belirlersiniz. Küçük ve basit otomasyon görevleri için hızlı bir başlangıç sunsa da karmaşık iş akışları için yönetimi zorlaşabilir ve “Pipeline as Code” felsefesine uymaz.

Pipeline

Pipeline, modern Jenkins kullanımının merkezinde yer alır. CI/CD iş akışının tamamını kod olarak tanımlamanıza olanak tanır. Bu kod, genellikle `Jenkinsfile` adı verilen bir metin dosyasında tutulur ve projenin kaynak koduyla birlikte versiyonlanır. Bu “Pipeline as Code” yaklaşımı, iş akışının dayanıklı, tekrarlanabilir, versiyonlanabilir ve birden fazla geliştirici tarafından ortaklaşa düzenlenebilir olmasını sağlar. Karmaşık süreçleri, koşullu adımları ve paralel işlemleri kolayca yönetmek için idealdir.

Multi-branch Pipeline

Multi-branch Pipeline, özellikle Git gibi modern versiyon kontrol sistemleri ile çalışan ekipler için tasarlanmıştır. Belirtilen bir kod deposundaki (repository) tüm dalları (branches) otomatik olarak tarar ve içinde bir `Jenkinsfile` bulunan her dal için otomatik olarak bir pipeline projesi oluşturur. Bu, özellikle “feature branch” (özellik dalı) geliştirme modelini benimseyen ekipler için büyük kolaylık sağlar. Yeni bir dal oluşturulduğunda Jenkins bunu algılar ve o dal için CI sürecini otomatik başlatır. Dal silindiğinde ise ilgili Jenkins projesini temizler.

Jenkins Pipeline ve Jenkinsfile

Jenkins Pipeline, bir dizi eklenti üzerine inşa edilmiş olup Sürekli Teslimat (Continuous Delivery) pipeline’larının uygulanmasını ve entegrasyonunu destekler. Pipeline’ın tanımı `Jenkinsfile` içinde yapılır.

Pipeline Nedir?

Pipeline, bir yazılımın versiyon kontrolünden son kullanıcıya ulaşana kadar geçirdiği tüm süreçleri (derleme, test etme, dağıtma vb.) modelleyen bir iş akışıdır. Jenkins’te pipeline, bu süreçleri tanımlayan bir dizi adımdan oluşur ve bu adımların nasıl ve ne zaman çalışacağını belirler. Bir pipeline, basit bir CI sürecinden, çok aşamalı ve karmaşık bir CD sürecine kadar her şeyi içerebilir.

Declarative ve Scripted Pipeline Farkları

Jenkins, pipeline’ları tanımlamak için iki farklı sözdizimi (syntax) sunar: Declarative ve Scripted. Her ikisi de aynı pipeline altyapısını kullanır ancak yazım ve esneklik açısından farklılıklara sahiptir.

Jenkinsfile’ın Temel Yapısı (agent, stages, steps)

Bir Declarative `Jenkinsfile` temel olarak şu bloklardan oluşur:

• pipeline: Tüm pipeline tanımını içeren ana bloktur.
• agent: Pipeline’ın veya belirli bir aşamanın nerede çalışacağını belirtir. `any` (herhangi bir uygun agent), `none` (agent belirtilmez) veya Docker konteyneri gibi belirli bir ortam olabilir.
• stages: Pipeline’ın ana aşamalarını içeren bloktur. Örneğin, “Build”, “Test”, “Deploy” gibi mantıksal bölümlerden oluşur.
• stage: `stages` bloğu içinde yer alan her bir aşamayı tanımlar. Örneğin, `stage(‘Build’)`.
• steps: Bir `stage` içinde çalıştırılacak adımları içerir. Bu adımlar, shell komutları (`sh`), derleme araçları (`mvn`), dosya işlemleri veya diğer Jenkins görevleri olabilir.

Eklentilerin (Plugins) Yönetimi ve Önemi

Jenkins’in gücünün büyük bir kısmı, geniş eklenti ekosisteminden gelir. Eklentiler, Jenkins’in temel işlevselliğini genişleterek yüzlerce farklı araç, teknoloji ve platformla entegre olmasını sağlar. Git, Docker, Kubernetes, Maven, SonarQube, Slack gibi popüler araçlar için eklentiler mevcuttur. Eklentiler, “Manage Jenkins” > “Manage Plugins” menüsünden yönetilir. Buradan mevcut eklentiler güncellenebilir, yeni eklentiler kurulabilir veya kullanılmayanlar kaldırılabilir. Doğru eklenti setini seçmek, CI/CD pipeline’ınızın yeteneklerini doğrudan etkiler.

Jenkins Agent (Node/Slave) Mimarisi

Jenkins, dağıtık bir mimariyi destekler. Bu mimari, bir Master (ana sunucu) ve bir veya daha fazla Agent (düğüm/slave) bileşeninden oluşur. Master, Jenkins’in ana orchestrator’ıdır; projeleri yönetir, pipeline’ları zamanlar ve sonuçları gösterir. Ancak asıl iş yükünü (derleme, test gibi) Agent’lar üstlenir. Bu mimarinin avantajları şunlardır:

• Ölçeklenebilirlik: İş yükü arttığında yeni agent’lar eklenerek sistemin performansı artırılabilir.
• Farklı Ortamlar: Farklı işletim sistemlerine (Windows, macOS, Linux) veya farklı araç setlerine sahip agent’lar oluşturularak çok platformlu projeler desteklenebilir.
• Yük Dengeleme: Master sunucunun üzerindeki yük azalır ve sadece yönetim görevlerine odaklanması sağlanır.

Agent’lar, Master’a SSH veya JNLP (Java Network Launch Protocol) gibi protokoller üzerinden bağlanabilir ve dinamik olarak (örneğin, bulut ortamlarında veya Kubernetes üzerinde) oluşturulabilir.

Örnek Bir CI/CD Pipeline’ı Oluşturma Adımları

Teorik bilgileri pratiğe dökmenin en iyi yolu, basit ama işlevsel bir CI/CD pipeline’ı oluşturmaktır. Bu bölüm, bir projenin kaynak kodunu versiyon kontrol sisteminden alıp derleme, test ve paketleme aşamalarından geçiren temel bir pipeline’ın nasıl oluşturulacağını adım adım anlatmaktadır. Bu süreç, Jenkins’in temel çalışma mantığını anlamak için sağlam bir temel oluşturacaktır.

Versiyon Kontrol Sistemi (GitHub/GitLab) ile Entegrasyon

CI/CD sürecinin başlangıç noktası, kodun bulunduğu merkezi depodur. Jenkins’in bu depodaki değişiklikleri takip edebilmesi ve kodu çekebilmesi için doğru bir entegrasyon yapılması gerekir.

Proje Kodlarının Repoya Yüklenmesi

İlk adım, otomatize etmek istediğiniz uygulamanın kaynak kodlarını GitHub, GitLab veya Bitbucket gibi bir Git deposuna yüklemektir. Bu depo, projenin “tek gerçek kaynağı” (single source of truth) olacaktır. Deponun içinde, projenin nasıl derleneceğini ve test edileceğini bilen bir yapı (örneğin, Maven için `pom.xml`, Node.js için `package.json`) bulunmalıdır.

Jenkins’e Depo (Repository) Adresinin Eklenmesi

Jenkins’te yeni bir “Pipeline” projesi oluşturduktan sonra, yapılandırma sayfasında “Pipeline” bölümüne gelinir. Burada “Definition” olarak “Pipeline script from SCM” (Versiyon Kontrol Sisteminden Pipeline betiği) seçeneği işaretlenir. “SCM” olarak “Git” seçilir ve “Repository URL” alanına projenizin Git depo adresi (örneğin, `https://github.com/kullanici/proje.git`) yapıştırılır.

Erişim İçin Kimlik Bilgilerinin (Credentials) Tanımlanması

Eğer Git deponuz özel (private) ise, Jenkins’in bu depoya erişim izni olması gerekir. Jenkins, bu tür hassas bilgileri güvenli bir şekilde saklamak için “Credentials” sistemini kullanır. “Credentials” bölümünden “Add” butonuna tıklayarak yeni bir kimlik bilgisi ekleyebilirsiniz. En yaygın yöntemler şunlardır:

• Username with password: GitHub/GitLab kullanıcı adınız ve parolanız (veya daha güvenli olan Personal Access Token).
• SSH Username with private key: Sunucuda oluşturulan bir SSH anahtarının özel (private) kısmını Jenkins’e, genel (public) kısmını ise GitHub/GitLab hesabınıza ekleyerek parolasız erişim sağlama.

Kimlik bilgisi eklendikten sonra, proje yapılandırmasındaki “Credentials” açılır menüsünden bu bilgiyi seçerek Jenkins’in depoya erişimini sağlarsınız.

Basit Bir Jenkinsfile Yazımı

Pipeline’ın mantığı, projenin kök dizininde bulunan `Jenkinsfile` adlı bir dosyada tanımlanır. Bu dosya, Groovy sözdizimini kullanarak iş akışının aşamalarını belirtir.

Derleme (Build) Aşamasının Oluşturulması

İlk aşama genellikle projenin derlenmesidir. Bu aşama, kaynak kodun çalıştırılabilir veya dağıtılabilir bir formata dönüştürülmesini sağlar. Örneğin, bir Java projesi için bu, Maven veya Gradle kullanılarak `compile` veya `build` komutlarını çalıştırmak anlamına gelir.

Örnek `stage` bloğu:


stage('Build') {
steps {
sh 'mvn compile'
}
}


Test (Test) Aşamasının Eklenmesi

Kodun kalitesini ve doğruluğunu sağlamak için derlemeden sonra otomatik testlerin çalıştırılması kritik öneme sahiptir. Bu aşamada birim (unit) testleri, entegrasyon testleri veya diğer test türleri çalıştırılır. Testler başarısız olursa, pipeline durdurulur ve ekibe bildirim gönderilir.

Örnek `stage` bloğu:


stage('Test') {
steps {
sh 'mvn test'
}
}


Paketleme (Package) Aşamasının Tanımlanması

Testler başarıyla tamamlandıktan sonra, uygulama dağıtıma hazır hale getirilmek üzere paketlenir. Bu, bir Java uygulaması için bir JAR veya WAR dosyası oluşturmak, bir Node.js uygulaması için bağımlılıkları içeren bir zip arşivi hazırlamak veya bir Docker imajı oluşturmak olabilir. Oluşturulan bu pakete “artifact” denir.

Örnek `stage` bloğu:


stage('Package') {
steps {
sh 'mvn package'
archiveArtifacts artifacts: 'target/*.jar', fingerprint: true
}
}


Pipeline’ı Çalıştırma ve Sonuçları İzleme

Pipeline tanımlandıktan ve `Jenkinsfile` depoya eklendikten sonra, iş akışını çalıştırıp sonuçlarını izleyebilirsiniz.

Manuel Tetikleme

Jenkins arayüzünde projenizin sayfasına giderek “Build Now” (Şimdi İnşa Et) butonuna tıklayarak pipeline’ı manuel olarak başlatabilirsiniz. Bu, özellikle `Jenkinsfile` üzerinde değişiklik yaptığınızda veya bir süreci yeniden çalıştırmak istediğinizde kullanışlıdır.

Webhook ile Otomatik Tetikleme

CI/CD’nin gerçek gücü otomasyondan gelir. Pipeline’ın, kod deposuna her yeni bir `commit` yapıldığında otomatik olarak tetiklenmesi için Webhook entegrasyonu kullanılır. GitHub veya GitLab ayarlarından, projenize özel bir Webhook URL’i (`http://JENKINS_URL/github-webhook/`) eklenir. Bu sayede, depoda bir değişiklik olduğunda GitHub/GitLab, Jenkins’e bir bildirim gönderir ve Jenkins ilgili projenin pipeline’ını otomatik olarak başlatır.

Konsol Çıktısı (Console Output) ve Günlüklerin (Logs) Analizi

Çalışan veya tamamlanmış bir pipeline’ın detaylarını görmek için Jenkins arayüzündeki “Build History” (İnşa Geçmişi) bölümünden ilgili çalışmayı seçebilirsiniz. “Console Output” (Konsol Çıktısı) seçeneği, pipeline’ın her adımında çalıştırılan komutların ve bu komutların ürettiği tüm çıktıların canlı olarak veya sonradan incelenmesini sağlar. Bir hata oluştuğunda, sorunun kaynağını bulmak için analiz edilmesi gereken ilk yer burasıdır. Günlükler, hataların ayıklanması (debugging) ve sürecin şeffaflığı için vazgeçilmezdir.

Gelişmiş Entegrasyonlar ve Yetenekler

Temel bir CI/CD pipeline’ı kurduktan sonra, Jenkins’in yeteneklerini daha da genişleterek süreçlerinizi daha verimli, güvenli ve modern hale getirebilirsiniz. Gelişmiş entegrasyonlar, özellikle konteyner tabanlı teknolojiler, kod kalitesi analizi ve artifact yönetimi gibi alanlarda pipeline’ınıza değer katacaktır.

Docker ile Konteyner Tabanlı Süreçler

Docker, uygulamaları ve bağımlılıklarını izole edilmiş, taşınabilir konteynerler içinde paketlemenizi sağlar. Bu, CI/CD süreçlerinde tutarlılık ve tekrarlanabilirlik için devrim niteliğinde bir yaklaşımdır. Jenkins’in Docker ile entegrasyonu, modern yazılım teslimat pijpeline’larının vazgeçilmez bir parçasıdır.

Jenkinsfile İçinde Docker Image Oluşturma

Uygulamanızın bir Docker imajı olarak paketlenmesi, dağıtım sürecini büyük ölçüde basitleştirir. Jenkinsfile içinden, projenizin kök dizininde bulunan bir `Dockerfile` kullanarak kolayca imaj oluşturabilirsiniz. Docker Pipeline eklentisi, bu işlemi yönetmek için `docker.build()` gibi kullanışlı komutlar sunar. Bu adım genellikle “Package” veya ayrı bir “Build Image” aşamasında gerçekleştirilir.

Oluşturulan Image’ı Docker Registry’e Yükleme (Push)

Oluşturulan Docker imajının, dağıtım yapılacak sunucular tarafından erişilebilir olması gerekir. Bu amaçla imaj, Docker Hub, Amazon ECR, Google GCR veya kendi barındırdığınız özel bir Docker Registry gibi bir kayıt defterine yüklenir (push edilir). Jenkinsfile içinde, `docker.withRegistry()` bloğu kullanılarak kimlik bilgileriyle registry’ye bağlanılır ve `image.push()` komutuyla imaj yüklenir. Bu adım, imajın merkezi bir konumda saklanmasını ve versiyonlanmasını sağlar.

Uygulamayı Konteyner Olarak Dağıtma (Deploy)

İmaj registry’ye yüklendikten sonraki son adım, bu imajı kullanarak uygulamayı hedef sunucularda (staging, production vb.) bir konteyner olarak çalıştırmaktır. Bu işlem, genellikle hedef sunucuya SSH ile bağlanıp `docker run` veya `docker-compose up` gibi komutları çalıştırmak suretiyle yapılır. Kubernetes gibi bir konteyner orkestrasyon platformu kullanılıyorsa, Jenkins pipeline’ı `kubectl apply` komutlarıyla dağıtım (deployment) tanımını güncelleyerek bu süreci yönetebilir.

Kod Kalitesi ve Güvenlik Analizi Entegrasyonları (SonarQube vb.)

CI/CD sadece hızı değil, aynı zamanda kaliteyi de artırmalıdır. Otomatik kod analizi araçları, pipeline’ın bir parçası haline getirilerek kod kalitesi ve güvenliği sürekli olarak denetlenebilir. SonarQube, bu alandaki en popüler açık kaynak platformlardan biridir. Jenkins, SonarQube Scanner eklentisi aracılığıyla entegre olur. Pipeline’a bir “Code Analysis” aşaması eklenerek, her derlemede kodun bug’lar, zafiyetler, kod tekrarları ve karmaşıklık gibi metrikler açısından taranması sağlanır. Analiz sonuçları belirli bir kalite eşiğini (Quality Gate) geçemezse, pipeline durdurularak hatalı kodun üretime geçmesi engellenir.

Artifact Yönetimi (Nexus, Artifactory vb.)

CI/CD süreçleri boyunca üretilen çıktılara “artifact” denir. Bunlar, derlenmiş JAR/WAR dosyaları, Docker imajları, NPM paketleri veya herhangi bir ikili (binary) dosya olabilir. Bu artifact’lerin güvenilir, versiyonlanmış ve merkezi bir şekilde saklanması gerekir. Nexus Repository veya JFrog Artifactory gibi artifact yönetim araçları bu amaçla kullanılır. Jenkins, bu araçlarla entegre olarak, pipeline sonunda oluşturulan artifact’leri otomatik olarak bu depolara yükleyebilir. Bu sayede, farklı pipeline’lar veya ekipler arasında artifact paylaşımı kolaylaşır ve her derlemenin çıktısı güvenli bir şekilde arşivlenir. Geriye dönük bir sürüme ihtiyaç duyulduğunda, ilgili artifact bu depodan kolayca çekilebilir.

Güvenlik, Bakım ve En İyi Uygulamalar

Jenkins, bir otomasyon sunucusu olarak şirketinizin en kritik sistemlerine ve verilerine erişim yetkisine sahip olabilir. Bu nedenle, Jenkins ortamının güvenliğini sağlamak, düzenli bakımını yapmak ve en iyi uygulamaları takip etmek hayati önem taşır. Sağlam bir Jenkins altyapısı, sadece verimli değil, aynı zamanda güvenli ve sürdürülebilir olmalıdır.

Kullanıcı Yönetimi ve Rol Tabanlı Yetkilendirme

Varsayılan Jenkins kurulumunda, giriş yapan her kullanıcının tam yönetici yetkileri vardır. Bu, üretim ortamları için kabul edilemez bir güvenlik riskidir. “Configure Global Security” bölümünden “Matrix-based security” veya “Project-based Matrix Authorization Strategy” seçenekleri etkinleştirilmelidir. Daha karmaşık ortamlar için ise “Role-based Authorization Strategy” eklentisi şiddetle tavsiye edilir. Bu eklenti ile farklı roller (örneğin, developer, qa, admin) oluşturabilir ve her role sadece ihtiyaç duydukları yetkileri (proje oluşturma, çalıştırma, yapılandırmayı görme vb.) atayabilirsiniz. Bu, “en az ayrıcalık ilkesi”ni (principle of least privilege) uygulayarak yetkisiz erişim ve hatalı işlem riskini azaltır.

Kimlik Bilgilerinin (Credentials) Güvenli Saklanması

Pipeline’ların veritabanı parolaları, API anahtarları, SSH anahtarları gibi hassas bilgilere ihtiyacı vardır. Bu bilgileri asla `Jenkinsfile` veya proje yapılandırması içinde düz metin olarak saklamayın. Jenkins’in dahili “Credentials” sistemi bu tür bilgileri şifrelenmiş bir şekilde saklamak için tasarlanmıştır. Kimlik bilgileri bir kez eklendikten sonra, pipeline’lar içinde bir değişken olarak kullanılabilir ve bu bilgiler konsol çıktılarında maskelenir. Daha gelişmiş güvenlik ihtiyaçları için HashiCorp Vault gibi harici sır yönetim araçlarıyla entegrasyon sağlayan eklentiler de kullanılabilir.

Jenkins Yedekleme ve Geri Yükleme Stratejileri

Jenkins sunucusunun arızalanması durumunda tüm proje yapılandırmalarını, iş geçmişini ve eklenti ayarlarını kaybetmek felaketle sonuçlanabilir. Bu nedenle düzenli bir yedekleme stratejisi oluşturmak zorunludur. Yedeklenmesi gereken en önemli dizin `JENKINS_HOME` dizinidir. Bu dizin, tüm yapılandırma XML dosyalarını, projeleri, eklentileri ve iş geçmişini içerir. Yedekleme işlemi, `JENKINS_HOME` dizininin periyodik olarak bir arşive (örneğin, tar.gz) sıkıştırılıp güvenli bir konuma (farklı bir sunucu, bulut depolama vb.) kopyalanmasıyla yapılabilir. “ThinBackup” gibi eklentiler de bu süreci otomatikleştirmek için kullanılabilir. Geri yükleme, bu yedeğin yeni bir Jenkins kurulumunda ilgili dizine açılmasıyla gerçekleştirilir.

Jenkins ve Eklentilerin Düzenli Olarak Güncellenmesi

Jenkins ve eklentileri, sürekli olarak geliştirilen ve güncellenen yazılımlardır. Yeni sürümler genellikle performans iyileştirmeleri, yeni özellikler ve en önemlisi güvenlik yamaları içerir. Jenkins yöneticisi, periyodik olarak “Manage Jenkins” sayfasında çıkan güncelleme bildirimlerini kontrol etmelidir. Hem Jenkins çekirdeğini (LTS sürümünü takip etmek önerilir) hem de kurulu olan tüm eklentileri güncel tutmak, bilinen güvenlik zafiyetlerine karşı sisteminizi korumanın en etkili yollarından biridir. Güncelleme yapmadan önce, kritik bir sorun yaşanması ihtimaline karşı sistemin yedeğini almak iyi bir pratiktir.

CI/CD Altyapısı İçin Neden İHS Telekom’u Tercih Etmelisiniz?

Etkili bir CI/CD süreci, arkasında yatan güçlü ve güvenilir sunucu altyapısına doğrudan bağlıdır. Jenkins gibi otomasyon araçlarının performansı, üzerinde çalıştığı sunucunun işlem gücü, ağ bağlantısı ve kesintisizliği ile ölçülür. İHS Telekom, CI/CD altyapınız için ihtiyaç duyduğunuz sağlam temeli sunarak yazılım geliştirme süreçlerinizi bir üst seviyeye taşımanıza yardımcı olur.

Yüksek Performanslı ve Kesintisiz Sunucu Hizmetleri

Derleme ve test süreçleri, CPU ve I/O açısından oldukça yoğun olabilir. İHS Telekom’un sunduğu yüksek performanslı VDS ve fiziksel sunucu çözümleri, en karmaşık pipeline’ların bile hızlı bir şekilde tamamlanmasını sağlar. %99.9’un üzerinde uptime garantisi ile Jenkins sunucunuzun her zaman erişilebilir olacağını bilerek, CI/CD süreçlerinizin kesintiye uğrama endişesi olmadan çalışmasını sağlayabilirsiniz.

İhtiyaca Göre Ölçeklenebilir Sanal Sunucu (VDS/VPS) Seçenekleri

CI/CD ihtiyaçlarınız zamanla değişebilir. Proje sayınız arttıkça veya daha fazla paralel iş çalıştırmanız gerektiğinde sunucu kaynaklarınızı artırmanız gerekebilir. İHS Telekom’un esnek VPS ve VDS paketleri, kaynaklarınızı (CPU, RAM, Disk) ihtiyaç anında kolayca yükseltmenize olanak tanır. Küçük bir ekiple başlayıp büyüdükçe altyapınızı sorunsuzca ölçeklendirebilir, gereksiz maliyetlerden kaçınabilirsiniz.

Güçlü Ağ Altyapısı ve Düşük Gecikme Süreleri

Jenkins’in kod depolarından (GitHub/GitLab) kaynak kodu çekmesi, Docker imajlarını registry’lerden indirmesi ve artifact’leri yüklemesi için hızlı ve stabil bir internet bağlantısı kritiktir. İHS Telekom’un güçlü ve yedekli ağ altyapısı, yüksek bant genişliği ve düşük gecikme süreleri sunarak pipeline’larınızdaki ağa bağlı adımların minimum sürede tamamlanmasını garanti eder. Bu, özellikle büyük projeler ve Docker imajları ile çalışırken süreçlerinizi önemli ölçüde hızlandırır.

7/24 Uzman Teknik Destek ve Danışmanlık Hizmeti

Sunucu ortamının kurulumu ve yönetimi sırasında beklenmedik sorunlarla karşılaşabilirsiniz. İHS Telekom’un 7/24 hizmet veren uzman teknik destek ekibi, altyapınızla ilgili her türlü sorunda size hızlı ve etkili çözümler sunar. Gerekli portların yapılandırılmasından işletim sistemi optimizasyonuna kadar birçok konuda destek alarak, sunucu yönetimi yerine CI/CD süreçlerinizi iyileştirmeye odaklanabilirsiniz.