Küçük ekiplerde CI/CD: her commit'i canlıya atmadan önce

CI/CD bir araç listesi değil; her değişikliğin canlıya nasıl, kim tarafından ve hangi kontrollerden geçerek gideceğinin yazılı cevabıdır. Bu yazıda 3–20 kişilik ekipler için abartısız bir hat öneriyoruz: test + derleme otomatik, canlıya çıkış bilinçli, geri alma yolu net.

Küçük ekiplerde sık görülen iki uç var: ya her şey elle (FTP, panikten SSH, “benim makinemde çalışıyordu”), ya da kurumsal bir pipeline kopyası (onlarca job, kimsenin okumadığı YAML, kırık yeşil tikler).

TW Bilişim olarak yazılım ve DevOps işlerinde gördüğümüz tablo: küçük ekibin ihtiyacı genelde “her mikroserviste ayrı release train” değil; tekrarlanabilir bir derleme, birkaç otomatik kontrol ve canlıya çıkanın kim olduğu netliği.

Bu rehber, kendi ürününü veya müşteri için özel yazılımı işleten ekipler içindir. Araç adları örnek (GitHub Actions, GitLab CI, benzeri); önemli olan düzen.

Önce “canlıya ne çıkıyor?” — üç tanım

Pipeline yazmadan önce küçük bir sözleşme yeter:

1. Kaynak: hangi dal / etiket canlıya aday? (main, release/*, semver tag…)
2. Kanıt: canlıya çıkmadan önce hangi kontroller zorunlu? (test, lint, tip kontrolü, güvenlik taraması — hepsi birden değil, seçilmiş set)
3. İnsan: prod deploy’u kim onaylar veya kim tetikler? (otomatik mi, manuel onay mı?)

Bu üç madde net değilse ekstra job eklemek karmaşa üretir. CI/CD, riski görünür kılmak içindir; yeşil tik koleksiyonu için değil.

CI ve CD’yi ayırın

Pratik ayrım:

1. CI (sürekli entegrasyon): her PR / her push’ta — derle, test et, mümkünse aynı artefaktı üret.
2. CD (sürekli teslim / dağıtım): o artefaktı staging veya prod’a taşı — çoğu küçük ekipte staging otomatik, prod manuel veya korumalı dal ile.

İkisi aynı YAML dosyasında olabilir; zihinsel olarak ayrı tutmak, “her commit prod’a” baskısını azaltır. Özellikle tek kişilik veya 2–3 kişilik ekiplerde prod’u tamamen otomatik yapmak genelde erken bir adımdır.

Minimum CI seti (abartmadan)

İlk ay için çoğu ürün şu kadarla idare eder:

Adım	Ne işe yarar	Not
Bağımlılık kurulumu (kilitli)	Tekrarlanabilir derleme	package-lock / poetry.lock / go.sum commit’te
Lint / format kontrolü	Stil tartışmasını PR’dan çıkarır	Kırıcı değilse uyarı → hata geçişi kademeli
Birim / duman testleri	Regresyonun erken yakalanması	“%100 coverage” hedefi değil; kritik yollar
Derleme / tip kontrolü	“Benim makinemde” farkını kapatır	Prod ile aynı major runtime sürümü
Artefakt üretimi	Aynı binary/image deploy edilir	“CI’da bir kez derle, her ortamda onu kullan”

İlk günden SAST + container tarama + e2e + performans bench hepsini zorunlu kılmak, yeşil tikleri kırık bırakır ve ekip pipeline’ı baypas etmeyi öğrenir.

Deploy: staging otomatik, prod bilinçli

Sade bir model:

• PR → CI: merge öncesi zorunlu kontroller
• main merge → staging: otomatik deploy (mümkünse)
• Prod: etiket / manuel workflow / korumalı ortam onayı

Prod’a çıkan her sürüm için bilinen bir kimlik olsun: commit SHA, image tag veya semver. “Hangi commit canlıda?” sorusu 30 saniyede cevaplanabilmeli.

Geri alma (rollback) planı deploy planının parçasıdır: bir önceki artefaktı yeniden yayınlamak, migrate geri almak veya feature flag kapatmak — hangisi sizin stack’inize uyuyorsa, yazılmış olsun.

Sırlar ve ortam değişkenleri

Pipeline’a gömülü şifre, chat’e yapıştırılmış token, repo’da .env commit’i — küçük ekiplerde hâlâ sık.

Pratik kurallar:

• Secret’lar CI/CD secret store veya bulut secret manager’da
• Staging ve prod secret’ları ayrı
• Log ve hata mesajlarında secret sızdırılmaz
• Dönen anahtar (rotation) için sahip ve takvim bilinçli — abartılı prosedür değil, en azından “kim değiştirebilir” netliği

CI log’u herkese açıksa, debug çıktısında env dump yapmak prod sızıntısına giden kısa yoldur.

Branch ve PR düzeni: küçük ekibe göre

Kurumsal “gitflow + 4 onay” çoğu KOBİ ürününde yavaşlatır. Daha sade seçenekler:

• Kısa ömürlü feature branch + PR
• main korumalı: CI yeşil olmadan merge yok
• Kritik dosyalar (infra, auth, fatura) için ekstra göz (CODEOWNERS veya basit kural)

Amaç bürokrasi değil; tek kişinin yanlışlıkla prod’u kırıp kimsenin fark etmemesini zorlaştırmak.

Maliyet ve bakım

Ücretsiz CI dakikaları bitince sürpriz fatura veya kuyruk gecikmesi gelir. Bilinçli sınırlar:

• Cache kullan (bağımlılık / Docker layer)
• Gereksiz matrix (her OS × her Node sürümü) erteleyin
• Haftalık kırık job temizliği: “hep skip edilen” adımları silin

Sahipsiz pipeline, sahipsiz dashboard gibidir: bir süre yeşil kalır, sonra kimse dokunmaz.

Pratik checklist

Madde	Net mi?	Not
Canlıya aday dal / etiket yazılı	☐	Tek kaynak
PR’da zorunlu CI (test + derleme)	☐	Baypas yolu yok veya loglanır
Staging otomatik deploy	☐	Mümkünse
Prod tetikleyici + onay modeli	☐	Kim / nasıl
Sürüm kimliği (SHA / tag)	☐	Canlıda görünür
Rollback yolu yazılı	☐	Bir paragraf yeter
Secret’lar repo dışında	☐	Ortamlar ayrı
Haftalık 15 dk: kırık / gereksiz job	☐	Bakım

SSS

Her commit prod’a çıkmalı mı? Hayır. CI her değişiklikte çalışsın; CD’nin prod basamağı çoğu küçük ekipte bilinçli tetiklenir. “Sürekli teslim” ile “sürekli prod’a basmak” aynı şey değildir.

Docker şart mı? Hayır. Tekrarlanabilir artefakt önemli — jar, binary, static export veya image. Container faydalıysa kullanın; zorunluluk değil.

E2E testleri CI’da mı? Kritik mutlu yol için evet, ama kırılgan UI testleriyle tüm pipeline’ı bloke etmeyin. Önce birim + duman; e2e’yi kademeli ekleyin.

Monorepo’da her push her paketi mi derlemeli? Mümkünse etkilenen paketleri seçin (path filter). Aksi halde CI süresi ve fatura şişer; ekip job’ları atlamaya başlar.

TW Bilişim bu konuda ne yapıyor? Mevcut repo ve host’a uygun, abartısız CI/CD hattı kuruyoruz: az zorunlu kontrol, net prod kapısı, sürdürülebilir bakım. Amaç gösterişli bir pipeline vitrini değil; ekibinizin gerçekten güvendiği bir çıkış yolu bırakmak.

Sonuç

Sırayı basit tutun: canlıya ne çıkıyor → CI ile kanıt → staging’de doğrula → prod’a bilinçli çık → geri alma yolu hazır. Bu sıra netse araç seçimi (Actions, GitLab, başka) ikincil kalır.

Repo ve deploy sürecinizi birlikte sadeleştirmek isterseniz: iletişim veya [email protected].