Kazanimlar:
- CI/CD kavramını, pipeline anatomisini (trigger, job, step, runner, artifact) ve GitHub Actions ile GitLab CI arasındaki farkları kavrayıp yapay zekaya doğru bağlamla pipeline ürettirebilme
- Yapay zekanın ürettiği pipeline'da secret referanslarını, izinleri ve çağrılan bileşenlerin varlığını denetleyip güvenli hale getirebilme
- Secret'ları düz metin yazmama, en az yetki verme ve deploy'u CI'dan ayırıp kontrollü kılma ilkelerini uygulayabilme
Modern yazılımın kalbi, kodun bir geliştiricinin bilgisayarından çıkıp güvenle müşteriye ulaşana kadar geçtiği otomatik borudur. Bu boruya CI/CD denir. CI (Continuous Integration — sürekli entegrasyon), her kod değişikliğinin otomatik olarak derlenip test edilmesidir; amacı, bir hatayı geliştirici daha klavyeden kalkmadan yakalamaktır. CD (Continuous Delivery/Deployment — sürekli teslim/dağıtım), test edilmiş kodun otomatik olarak yayına hazırlanması, hatta yayına alınmasıdır. Bir CI/CD pipeline (boru hattı), bu adımları sırayla tanımlayan bir yapılandırma dosyasıdır — genellikle YAML (insan tarafından okunabilir bir yapılandırma metni biçimi) ile yazılır.
Bu YAML dosyalarını elle yazmak sıkıcı, ayrıntılı ve hataya açıktır; girinti (indentation) bir boşluk kayarsa tüm pipeline kırılır. İşte YZ burada devreye girer: doğru bağlamla, çalışan bir taslağı saniyeler içinde üretir. Ama üretilen her adımın ne yaptığını anlamak ve doğrulamak sizin işinizdir — çünkü bu boru, kodunuzu prod'a taşıyan borudur.
CI/CD pipeline'ının anatomisi
Her pipeline birkaç temel kavramdan oluşur. Bunları bilmeden YZ çıktısını denetleyemezsiniz:
- Trigger (tetikleyici): Pipeline'ı ne başlatır? Genellikle bir dala push, bir pull request (birleştirme isteği) veya bir zaman planı.
- Job (iş): Bir dizi adımı çalıştıran mantıksal birim; örneğin "test", "build", "deploy".
- Step (adım): Bir job içindeki tek bir komut veya eylem.
- Runner (koşucu): Job'ların üzerinde çalıştığı sanal makine veya konteyner.
- Artifact (yapı ürünü): Bir job'un ürettiği ve sonraki job'ların kullandığı çıktı (örneğin derlenmiş bir dosya).
- Secret: Pipeline'ın kullandığı ama depoda düz metin olarak durmaması gereken gizli bilgi.
GitHub Actions bu tanımı .github/workflows/*.yml dosyalarında tutar; birim workflow → job → step hiyerarşisidir. GitLab CI ise .gitlab-ci.yml dosyasında stage → job yapısını kullanır. YZ her iki sözdizimini de bilir, ama hangisini istediğinizi açıkça söylemelisiniz.
İpucu: YZ'den pipeline isterken her zaman şunu belirtin: platform (GitHub Actions mı GitLab CI mı), dil/çatı (Node, .NET, Python…), tetikleyici, ve deploy edilip edilmeyeceği. Bu dört bilgi çıktının işe yararlığını ikiye katlar.
Adım adım: YZ ile bir pipeline tasarlamak
- Hedefi netleştir. "main'e push'ta testleri koş, imaj build et, ama sadece tag atıldığında deploy et" gibi.
- İskeleti ürettir. YZ'den temel workflow'u iste.
- Adımları okuyup anla. Her run ve uses satırının ne yaptığını doğrula.
- Secret referanslarını denetle. Secret'lar ${{ secrets.NAME }} ile mi çağrılıyor, yoksa koda mı gömülmüş?
- Yerelde/CI'da dene. Küçük bir test deposunda çalıştır, kırmızı-yeşil (fail-pass) davranışını gör.
- Kademeli genişlet. Önce sadece CI (test), sonra build, en son deploy ekle.
Güvenlik: pipeline'da secret ve izin
CI/CD, secret'ların en çok sızdığı yerlerden biridir. Üç altın kural:
- Secret'ları asla YAML'a düz metin yazmayın. Platformun secret deposunu (GitHub Secrets, GitLab CI/CD Variables) kullanıp ${{ secrets.X }} ile çağırın.
- En az yetki (least privilege). Pipeline'a verdiğiniz token yalnızca gerektiği kadar yetkiye sahip olsun. GitHub Actions'ta permissions: bloğuyla bunu daraltın.
- Log'a secret basmayın. echo $TOKEN gibi satırlar secret'ı log'da açık eder. Platformlar maskeler ama siz de dikkat edin.
Dikkat: YZ, kolaylık olsun diye örnek pipeline'lara bazen password: 123456 gibi gömülü değerler veya aşırı geniş permissions: write-all koyar. Bunu her zaman düzeltin: secret referansa çevirin, izni daraltın.
Karşılaştırma tablosu
Kavram
GitHub Actions
GitLab CI
Yapılandırma dosyası
.github/workflows/*.yml
.gitlab-ci.yml
Yapı birimi
workflow → job → step
stage → job
Tetikleyici
on:
rules: / only:
Secret çağırma
${{ secrets.NAME }}
$NAME (CI/CD Variables)
Hazır bileşen
uses: action@v4
include: / template
Koşucu
runs-on:
tags:
Üç mini vaka
Vaka 1 — 6 saat 40 dakikaya indi. Bir ekip, elle yaptıkları test-build-deploy sürecini otomatikleştirmek istedi ama kimse YAML'a hakim değildi. YZ'ye "Node.js projesi, GitHub Actions, main'e push'ta npm test ve npm build, sadece v* tag'inde deploy" diye tarif ettiler. YZ 40 satırlık çalışan bir iskelet üretti; ekip her adımı doğrulayıp 40 dakikada canlıya aldı. Elle yazsalar bir günlük işti.
Vaka 2 — Doğrulama bir güvenlik açığını yakaladı. Bir mühendis YZ'den deploy workflow'u istedi. Çıktıda permissions: write-all vardı — yani token depoya, paketlere, her şeye yazabiliyordu. Mühendis bunu fark edip permissions: { contents: read, packages: write } ile daralttı. Bu, ele geçirilmiş bir bağımlılığın tüm depoyu değiştirme riskini ortadan kaldırdı.
Vaka 3 — Halüsinasyon action. Bir ekip YZ'nin önerdiği uses: actions/deploy-to-aws@v3 satırını çalıştırdı; böyle bir resmi action yoktu, YZ adı uydurmuştu. Pipeline "action bulunamadı" ile patladı. Ders: uses: ile çağrılan her bileşenin gerçekten var olduğunu Marketplace'te doğrulayın.
Dört kopyalanabilir şablon
1) Temel CI workflow'u:
GitHub Actions için bir CI workflow yaz. Proje: [DİL/ÇATI].Tetikleyici: main dalına push ve pull request. Adımlar:bağımlılıkları kur, testleri koş, lint çalıştır. Deploy YOK.Runner ubuntu-latest. Secret gerekmiyor. YAML'ı açıklamalı ver.
2) Deploy'lu CD workflow'u (güvenli):
[PLATFORM] için deploy workflow'u yaz. Yalnızca 'v*' tag'indeçalışsın. Hedef: [ORTAM/BULUT]. Kurallar:- Secret'ları ASLA düz metin yazma, ${{ secrets.X }} ile çağır.- permissions bloğunu en az yetkiyle daralt.- Deploy öncesi manuel onay adımı (environment protection) ekle.Her adımı yorumla.
3) Var olan pipeline'ı açıklat:
Aşağıdaki [PLATFORM] pipeline'ını satır satır açıkla: her job neyapıyor, hangi sırayla çalışıyor, hangi secret'ı kullanıyor veen riskli 2 noktası ne? Sonunda 3 iyileştirme öner.Pipeline: [YAML İÇERİĞİ]
4) Pipeline'ı hızlandır:
Şu CI pipeline'ı yavaş çalışıyor (süre: [X dk]). Cache kullanımı,paralel job'lar ve gereksiz adımlar açısından incele. Somut,uygulanabilir 5 hızlandırma önerisi ver ve her birinin tahminietkisini yaz. Pipeline: [YAML]
Zayıf prompt / Güçlü prompt
Zayıf: "GitHub Actions workflow'u yaz."
Sonuç: hangi dil, hangi tetikleyici, deploy var mı belirsiz; YZ genel bir Node örneği verir, muhtemelen sizin projenize uymaz ve secret'ı hardcode edebilir.
Güçlü: "GitHub Actions workflow'u yaz. Python 3.12 projesi, pull request ve main push'ta pytest + ruff koşsun; deploy YOK; bağımlılıkları pip cache ile hızlandır; hiçbir secret gerekmiyor. YAML'ı yorumlarla ver."
Fark: ikinci istem dili, tetikleyiciyi, kapsamı (deploy yok), performans beklentisini ve güvenlik kısıtını verir. Çıktı doğrudan çalışır.
Sık yapılan hatalar
- Secret'ı YAML'a gömmek. Düz metin parola/token en yaygın CI güvenlik açığıdır.
- Aşırı geniş izin. write-all yerine gereken minimum izni verin.
- Var olmayan action/template'e güvenmek. YZ'nin uydurduğu uses: satırlarını Marketplace'te doğrulayın.
- Deploy'u CI ile karıştırmak. Test her push'ta koşabilir ama deploy kontrollü ve onaylı olmalı.
- Cache kullanmamak. Her koşuda bağımlılıkları sıfırdan kurmak pipeline'ı dakikalarca yavaşlatır.
- İlk workflow'u doğrudan ana depoda denemek. Önce bir test deposunda çalıştırın.
Özetle
CI/CD pipeline'ları, kodu güvenle prod'a taşıyan otomatik borudur ve YAML ile tanımlanır. YZ, GitHub Actions ve GitLab CI için çalışan taslakları hızla üretir — ama platformu, dili, tetikleyiciyi ve deploy kapsamını net vermeniz gerekir. Güvenlikte üç kural şaşmaz: secret'ları referansla çağır, en az yetkiyi ver, log'a secret basma. Her uses:/include: bileşeninin gerçekten var olduğunu ve her adımın ne yaptığını doğrulamak sizin sorumluluğunuzdur.
Uygulama görevi
Basit bir örnek proje seçin (kendi dilinizde bir "hello world" bile olur). YZ'den yukarıdaki "Temel CI workflow'u" şablonuyla bir workflow ürettirin. Sonra: (1) her adımın ne yaptığını kendi cümlelerinizle yazın; (2) hiçbir secret'ın gömülü olmadığını ve izinlerin dar olduğunu doğrulayın; (3) mümkünse bir test deposunda çalıştırıp kırmızı-yeşil davranışını gözlemleyin.
Kontrol listesi
- [ ] İstememe platform, dil/çatı, tetikleyici ve deploy kapsamını ekledim.
- [ ] Üretilen YAML'daki her job ve step'in ne yaptığını anladım.
- [ ] Hiçbir secret düz metin değil; hepsi ${{ secrets.X }} / CI değişkeni.
- [ ] İzinleri (permissions) en az yetkiye daralttım.
- [ ] Çağrılan tüm action/template'lerin gerçekten var olduğunu doğruladım.
- [ ] Deploy adımını onay/koruma ile kontrollü hale getirdim.