CI/CD Pipeline Kurarken Öğrendiklerim

Kafein'de 3 farklı ürünün CI/CD süreçlerinden sorumluyken, "pipeline yazmak" ile "güvenilir bir pipeline işletmek" arasındaki farkı acı tecrübelerle öğrendim. Bu yazıda o derslerin bir kısmını paylaşıyorum.

Pipeline Neden Var?

CI/CD'nin amacı basit: kod her push edildiğinde otomatik olarak test edilsin, build edilsin ve (isteğe bağlı olarak) deploy edilsin. Manuel deployment'ların insan hatasına açık olması, CI/CD'yi tercih değil zorunluluk haline getiriyor.

Basit Bir Jenkinsfile

pipeline {
    agent any

    stages {
        stage('Build') {
            steps {
                sh './mvnw clean package'
            }
        }
        stage('Test') {
            steps {
                sh './mvnw test'
            }
        }
        stage('SonarQube Analizi') {
            steps {
                sh './mvnw sonar:sonar'
            }
        }
        stage('Docker Image') {
            steps {
                sh 'docker build -t myapp:${BUILD_NUMBER} .'
            }
        }
        stage('Deploy') {
            when {
                branch 'main'
            }
            steps {
                sh 'kubectl set image deployment/myapp myapp=myapp:${BUILD_NUMBER}'
            }
        }
    }
}

Öğrendiğim Dersler

1. Pipeline'ı da versiyonlayın

Jenkinsfile'ı repo dışında, Jenkins arayüzünde tutmak büyük bir hataydı. Pipeline kodu, uygulama koduyla aynı repoda ve aynı code review sürecinden geçmeli.

2. Hızlı başarısız olsun (fail fast)

En ucuz ve en hızlı adımları (lint, unit test) en başa koyun. Docker image build etmek dakikalar sürebilir — bir syntax hatası için bu kadar beklemeye gerek yok.

3. Secret'ları asla pipeline koduna yazmayın

Jenkins Credentials Store, Vault gibi araçlarla secret yönetimini ayırın:

environment {
    DB_PASSWORD = credentials('db-password')
}

4. Rollback stratejinizi baştan düşünün

Deploy stage'i "ileri" gitmeyi bilir ama bir şeyler ters giderse geri dönüşü de otomatikleştirmek gerekir. Kubernetes'te bu genelde önceki image tag'ine kubectl rollout undo kadar basit olabilir.

5. Pipeline'ı izleyin, sadece "geçti/geçmedi" ile yetinmeyin

Build süreleri uzadıkça pipeline'a kimse güvenmemeye başlar. SonarQube kalite kapıları (quality gates) ve build süresi metrikleri, pipeline sağlığını görünür kılar.

Kapanış

İyi bir CI/CD pipeline'ı, ekibin "deploy etmekten korkmadığı" bir sisteme dönüştüğünde başarılıdır. Bu yazı dizisinde Linux, Docker ve Kubernetes temellerinden CI/CD'ye kadar geldik — hepsi birbirini tamamlayan parçalar.