<

CI/CD Hattı Kurmak: Küçük Ekipler İçin Pratik Rehber

Geçen yıl tanıştığımız bir firma, sektöründe gayet başarılıydı; yazılımları para kazanıyordu. Yayın süreçleri ise şuydu: geliştirici, değişen dosyaları FTP ile sunucuya atıyordu. Hangi dosyanın hangi sürümde olduğu sorusunun cevabı, o gün deploy yapan kişinin hafızasıydı. Bir cuma akşamı yanlış klasöre atılan tek bir dosya, hafta sonunu üç kişiye zehir etti — bizimle o pazartesi tanıştılar.

Şunu net söyleyeyim: "deploy" kelimesi ekibinizde hâlâ gerginlik yaratıyorsa, sorununuz cesaret eksikliği değil, otomasyon eksikliğidir. Ve bu eksikliği gidermek, sanıldığından çok daha kolay. CI/CD kavramının etrafındaki jargon bulutu — pipeline'lar, artifact'ler, ortam matrisleri — küçük ekipleri korkutuyor; oysa işin çekirdeği bir günde kurulabilecek kadar yalın.

Asgari uygulanabilir hat: üç aşama yeter

Büyük şirketlerin kırk aşamalı pipeline şemalarını unutun; küçük ekip için üç aşama işin yüzde doksanını halleder.

Birinci aşama, her push'ta otomatik build ve test: bağımlılıklar kurulur, linter koşar, testler döner. Işık kırmızıysa merge yok — bu kural pazarlıksız. İkinci aşama, staging'e otomatik çıkış: ana dala giren her değişiklik, üretimin kopyası bir ortama kendiliğinden deploy olur ve göz kontrolü orada yapılır. "Bende çalışıyordu" cümlesini ekip sözlüğünden silen adım budur. Üçüncü aşama, üretime tek tık: onaylanan sürüm etiketlenir ve tek komutla ya da tek tuşla yayına gider. Kimse sunucuya elle dosya atmaz, atamaz.

GitHub Actions ya da GitLab CI ile bu hattın tamamı, ortalama bir projede bir iş gününde ayağa kalkar. (İlk kurulumda vaktin çoğu pipeline'a değil, "testlerimiz meğer temiz ortamda geçmiyormuş" keşfine gider — ki bu da başlı başına değerli bir keşiftir.)

Hattın bir de hız disiplini var, kurulduktan sonra unutulmasın: on dakikayı aşan pipeline'ı kimse beklemez; geliştiriciler ya sonucuna bakmadan devam eder ya da push'ları biriktirmeye başlar — iki davranış da hattın amacını baltalar. Bağımlılık önbelleği, testlerin paralel koşulması ve yavaş entegrasyon testlerinin ayrı bir gece koşusuna alınması, süreyi makul tutmanın bilindik üçlüsü. Pipeline süresi de bir performans metriğidir; izleyin, şişince müdahale edin.

Mobil ağırlıklı çalışan bir ekip olarak bir nüansı da ekleyelim: mobil tarafta "üretime tek tık" hedefinin önünde mağaza onay süreçleri var, bu doğru. Ama hattın geri kalanı aynen geçerli — imzalı paketin otomatik üretilmesi, test kanallarına (TestFlight, iç dağıtım) otomatik dağıtım, sürüm notlarının pipeline'dan düşmesi. Mağazaya gidene kadarki her adım elle yapılıyorsa, oradaki hata payını mağaza onayı değil siz taşıyorsunuz demektir.

Küçük ekiplerin atladığı üç sigorta

Hattı kuran ekiplerin çoğu mutlu mesut deploy'a başlar ve asıl önemli kısmı unutur. Deneyimimizde en pahalıya mal olan üç ihmal şunlar:

  • Geri dönüş planı: Deploy kadar rollback da otomatik olmalı. "Önceki sürüme dön" komutu otuz saniyede çalışmıyorsa hattınız yarımdır; sorun anında panik içinde elle dosya geri kopyalayan ekip, FTP günlerine dönmüş demektir.
  • Migration disiplini: Veritabanı değişiklikleri geriye uyumlu yazılmalı — önce yeni kolonu ekle, kodu geçir, eski kolonu ancak birkaç sürüm sonra kaldır. Bu disiplin yoksa rollback kâğıt üstünde kalır, çünkü eski kod yeni şemayla çalışamaz.
  • Sır yönetimi: Parolalar ve API anahtarları repo'da değil, CI'ın secret deposunda durur. Repo'ya bir kez giren sır, geçmişten silmesi meşakkatli olduğu için sonsuza dek sızmış kabul edilir ve döndürülür.

Üçü de "başımıza gelince öğrendik" kategorisinden. Sizin ekibin bu dersleri ucuza alması mümkün: kurulum gününde bu üç maddeyi hattın parçası yapın, sonradan yamamayın.

Staging'in değeri de üretime ne kadar benzediğiyle ölçülür. Boş veritabanıyla dönen bir staging, yalnızca "uygulama açılıyor mu?" sorusuna cevap verir; asıl hatalar gerçekçi veri hacmiyle ve gerçekçi konfigürasyonla ortaya çıkar. Pratik çözüm, üretim verisinin maskelenmiş (kişisel veriden arındırılmış) bir kopyasını düzenli aralıklarla staging'e taşımak. Bu kurulumun kendisi de otomatikleşmeli — elle tazelenen staging, birkaç ay içinde kimsenin güvenmediği bayat bir ortama dönüşüyor.

Sayılarla getirisi: sıklık artar, arıza azalır

Bu hattı kurduğumuz ekiplerde iki metrik istikrarlı biçimde aynı yöne kırılıyor. Yayın sıklığı haftalıktan günlüğe, bazen günde birkaça çıkıyor; "deploy kaynaklı arıza" kategorisi ise neredeyse sıfırlanıyor. İlk duyuşta çelişki gibi gelir — daha sık yayın, daha çok risk olmalı, değil mi? Tam tersi. Küçük değişiklik küçük risk taşır; sorun çıktığında şüpheli listesinde üç commit vardır, üç yüz değil. Büyük ve seyrek deploy ise her seferinde bir kumar, üstelik geri dönüşü de o oranda karmaşık.

FTP'li firmamızın altı ay sonraki tablosu: günde ortalama iki yayın, son dört ayda deploy kaynaklı sıfır arıza ve cuma günü yayın yapmaktan korkmayan bir ekip. Kurulum maliyeti, o zehir olan tek hafta sonunun maliyetinden azdı.

"Biz iki kişiyiz, bize lüks" itirazını da duyar gibiyim; en çok küçük ekiplerden geliyor ve tam tersi doğru. Büyük ekipte süreç bilgisi kalabalığa dağılır; iki kişilik ekipte deploy ritüeli tek kişinin kafasındadır ve o kişi tatile çıktığında şirketin yayın yeteneği de tatile çıkar. Pipeline, o kafanın içindekini herkesin okuyabildiği bir dosyaya döker. Küçük ekipte otomasyon lüks değil, sigortanın ta kendisi.

Başlama stratejisi olarak da mükemmeliyetçiliğe direnin. Üç aşamanın üçünü aynı hafta kurmak zorunda değilsiniz; sürecinizde en çok canınızı yakan tek adımı seçin ve önce onu otomatikleştirin. Çoğu ekipte bu, "testler her push'ta kendiliğinden koşsun" adımıdır ve tek başına bile yatırımını ilk ay geri öder. Momentum bir kez başlayınca gerisi kendiliğinden geliyor — otomasyonun tadını alan ekip, elle iş yapmaya tahammülünü hızla kaybediyor.

Asıl kazanç psikolojik

En güzel yan etkiyi hiçbir metrik göstermiyor: yayın sıradanlaşınca ekibin çalışma şekli değişiyor. Deploy korkulacak bir olay olmaktan çıkıp musluğu açmak kadar olağan hâle gelince, geliştiriciler büyük ve riskli paketler biriktirmek yerine küçük, güvenli adımlarla ilerlemeye başlıyor. Kod incelemeleri kısalıyor çünkü paketler küçük; hatalar erken yakalanıyor çünkü değişiklikler taze. Otomasyonun satın aldığı şey aslında zaman değil, sükûnet.

Hâlâ elle yayın yapıyorsanız kendinizi kötü hissetmeyin — gördüğümüz kadarıyla epey kalabalık bir kulüptesiniz. Ama ilk adımı ertelemeyin; üç aşamalı hattın ilk aşaması bile tek başına hayat kalitesi farkı yaratıyor. Nereden başlayacağınızı kestiremiyorsanız bize yazın, mevcut sürecinize bakıp bir günlük kurulum planını birlikte çıkaralım.

📅 Yayınlanma:  ·  Yakup Zengin