CI/CD, kod değişikliğinden canlıya almaya kadar tekrarlayan işleri otomatikleştiren bir çalışma biçimidir. Bu rehberde KOBİ ekiplerinin kurumsal seremoni olmadan sade bir hat kurmasını, test ve dağıtım adımlarını netleştiriyoruz.
CI CD nedir sorusu, yazılımını sık güncelleyen KOBİ ekiplerinde gittikçe daha sık soruluyor. Manuel derleme, test ve sunucuya dosya atma süreci hata riski taşır; aynı adımları her seferinde tekrarlamak da zaman kaybettirir. Sürekli entegrasyon ve sürekli dağıtım (CI/CD), kod deposuna her anlamlı değişiklik geldiğinde derleme, test ve yayınlama adımlarını otomatikleştirir. Bu rehberde kurumsal DevOps seremonilerine boğulmadan, küçük ekiplerin sade bir hat kurmasını anlatıyoruz.
Amaç araç yığını şişirmek değil; “kod birleşti, test geçti, doğru ortama gitti” zincirini güvenilir ve tekrarlanabilir hale getirmektir. KepezWeb gibi yazılım ve dijital çözüm ekipleri de projelerde bu sade hattı, ekip ölçeğine göre kurmayı tercih eder.
CI/CD nedir ve ne işe yarar?
CI/CD nedir diye bakıldığında iki tamamlayıcı pratik bir araya gelir: Continuous Integration (sürekli entegrasyon) ve Continuous Delivery/Deployment (sürekli teslim veya sürekli dağıtım). CI, geliştiricilerin sık sık ortak bir ana hatta kod birleştirmesini ve her birleştirmede otomatik derleme ile testlerin çalışmasını ifade eder. CD tarafı ise testlerden geçen sürümün hazır bir paket haline gelmesini ve isteğe bağlı veya otomatik olarak hedef ortama çıkmasını kapsar.
KOBİ ölçeğinde asıl kazanç “daha fazla araç” değil, insan hatasını azaltan tutarlılıktır. Aynı komutların herkesin bilgisayarında farklı çalışması, “bende çalışıyor” tartışmaları ve canlıda unutulan bir adım gibi sorunlar bu hatla görünür hale gelir.
CI ile CD arasındaki fark
CI, değişikliklerin bir arada tutulmasını ve kalite kapılarının erken çalışmasını sağlar. Tipik CI adımları şunlardır:
- Bağımlılıkların kurulması
- Derleme veya paket oluşturma
- Birim ve mümkünse entegrasyon testleri
- Kod biçimi, lint veya basit statik kontroller
CD ise “hazır paket”i bir sonraki ortama taşır. Continuous Delivery’de paket her zaman yayına hazırdır; canlıya alma kararı ekipte kalır. Continuous Deployment’te ise onaylı ana hat değişiklikleri otomatik olarak canlıya gidebilir. Küçük ekiplerde çoğu zaman önce Delivery ile başlamak daha güvenlidir: otomasyon kurulsun, canlı anahtarı ise bilinçli basılsın.
| Yaklaşım | Ne otomatik? | Canlıya alma | KOBİ için not |
|---|---|---|---|
| Yalnız CI | Derleme ve test | Manuel | İlk adım için uygundur |
| CI + Continuous Delivery | Paket hazırlama, staging’e çıkış | Onaylı manuel | Çoğu küçük ekip için dengeli seçenek |
| CI + Continuous Deployment | Canlıya kadar tüm zincir | Otomatik | İyi test ve geri alma planı şarttır |
KOBİ yazılımında otomatik dağıtım neden işe yarar?
Kurumsal bir DevOps ekibi olmadan da otomatik dağıtımın değeri nettir. Her yayın öncesi “hangi dosya kopyalanacak, hangi ortam değişkeni güncellenecek, migrasyon çalıştı mı?” listesini hatırlamaya çalışmak kırılgandır. Hat kurulduğunda bu liste kod ve yapılandırma dosyasına taşınır; yeni bir ekip üyesi de aynı yolu izler.
Küçük ekiplerde sprint temposu ve demo disiplini zaten kritiktir. Sade bir CI/CD hattı, Agile yazılım geliştirme döngüsünde “biten işi gösterme” adımını daha güvenilir hale getirir: demo’ya giden sürüm, kişisel bilgisayardaki rastgele bir klasörden değil, izlenebilir bir derlemeden gelir.
Ayrıca rol netliği artar. Kim pipeline’ı bozarsa kim düzeltir, kim canlı anahtarını basar gibi sorular netleşince iletişim maliyeti düşer. Bu ayrım, yazılım projesi rollerini sade tutmak isteyen ekipler için pratik bir çerçeve sunar.
Kurumsal seremoni olmadan sade hat: ön koşullar
Otomatik dağıtım kurmadan önce birkaç temel taş yerinde olmalıdır. Bunlar lüks değil, hattın güvenilir çalışması için asgari şartlardır.
- Tek kaynak kod deposu: Ana hat (main/master) ve kısa ömürlü özellik dalları net olsun.
- Tekrarlanabilir kurulum komutları: Yerelde ve sunucuda aynı paket yöneticisi, aynı kilit dosyası mantığı kullanılsın.
- Ortam ayrımı: En azından geliştirme/test ve canlı için ayrı yapılandırma; gizli anahtarlar kodda olmasın.
- Geri alma bilinci: “Bir önceki çalışan sürüme nasıl döneriz?” sorusunun cevabı yazılı olsun.
- Minimal test seti: Her şeyi kapsamasa da kritik iş kurallarını koruyan birkaç otomatik test.
Bu ön koşullar yoksa araç seçmek sorunu çözmez; sadece hatayı daha hızlı üretir. KepezWeb tarafında özel yazılım işlerinde de önce “ne otomatikleştirilecek, ne manuel kalacak” sınırı çizilir; sonra pipeline iskeleti kurulur.
Küçük ekiplerde CI/CD kurulum adımları
Aşağıdaki yol, tek sunucu veya az sayıda ortamı olan KOBİ uygulamaları için sade bir başlangıçtır. Araç isimleri örnek niteliğindedir; önemli olan adım sırasıdır.
1. Depo ve dal stratejisini sadeleştirin
Uzun yaşayan dallar birleştirme riskini büyütür. Ana hat her zaman yayın adayı gibi düşünülsün. Özellik işi bittiğinde küçük pull request’lerle birleştirin. Zorunlu incelemeyi ekip büyüklüğüne göre ayarlayın: iki kişilik ekiplerde bile “ikinci göz” kısa bir kontrol listesiyle işe yarar.
2. Pipeline’ı tetikleyici olaylara bağlayın
Her push’ta veya pull request açıldığında CI çalışsın. Canlı dağıtımı ise yalnızca ana hat birleştirmesinde veya etiket (tag) oluşturulduğunda tetikleyin. Böylece deneme dalları canlıyı bozmaz.
3. Derleme adımını tek komuta indirin
Uygulama diliniz ne olursa olsun (örneğin PHP, Node, .NET veya Java), “bağımlılık kur → derle/paketle → artefakt üret” akışını betikleştirin. Pipeline bu betiği çalıştırmalıdır; sunucuda elle tıklanan adımlar kalmamalıdır.
4. Test kapısını gerçekçi tutun
İlk günden yüzde yüz kapsam hedeflemeyin. Önce ödeme, giriş, stok düşümü veya kritik form gibi işi durduran senaryoları otomatikleştirin. Testler kırılgansa ekip pipeline’ı atlamaya başlar; o noktada otomasyon fiilen ölür.
5. Ortam değişkenlerini ve sırları ayırın
Veritabanı parolası, API anahtarı ve SMTP bilgileri depoda olmamalıdır. Bunları pipeline ve sunucu tarafındaki gizli alanlarda tutun. Staging ile canlı aynı sırları paylaşmasın.
6. Dağıtımı adımlara bölün
Basit bir Continuous Delivery akışı şöyle görünebilir:
- CI başarılı olsun
- Paket veya imaj oluşsun
- Staging’e çıksın
- Kısa duman testi (smoke test) yapılsın
- Onay sonrası canlıya alınsın
Dosya kopyalama, container imajı çekme veya platforma sürüm yükleme yöntemi projenize göre değişir; kritik olan dağıtımın da kod gibi sürüm kontrolünde yaşamasıdır.
7. Veritabanı değişikliklerini unutmayın
Uygulama kodu güncellenirken şema migrasyonları elle kalırsa canlıda sürprizler artar. Migrasyonları da pipeline veya kontrollü bir yayın betiğinin parçası yapın. Geriye dönük uyumlu değişiklikler (önce ekle, sonra doldur, sonra kaldır) küçük ekiplerde riski düşürür.
Araç seçiminde KOBİ’ye uygun sadelik
Popüler seçenekler arasında depo ile bütünleşik çözümler öne çıkar: GitHub Actions, GitLab CI, Bitbucket Pipelines veya kendi sunucunuzdaki bir runner. Seçim kriterini “en çok eklenti” değil şu sorular belirlesin:
- Ekip zaten hangi kod barındırma hizmetini kullanıyor?
- Gizli bilgileri güvenli saklayabiliyor muyuz?
- Derleme dakikası ve eşzamanlı iş kotası bütçemize uyuyor mu?
- Hata loglarını herkes okuyabiliyor mu?
Monolit bir web uygulaması için tek dosyalık bir pipeline tanımı çoğu zaman yeterlidir. Mikroservis mimarisi yokken karmaşık orkestrasyon katmanları eklemek bakım yükü yaratır. Özel yazılım geliştiren ekipler, hattı ürünün gerçek yayın ritmine göre büyütür; KepezWeb’in yazılım geliştirme yaklaşımında da önce çalışan minimum hat, sonra ihtiyaç halinde genişleme tercih edilir.
Güvenlik ve kalite kontrollerini abartmadan ekleyin
Otomatik dağıtım hız kazandırırken, kötü bir değişiklik de daha hızlı gidebilir. Bu yüzden pipeline’a birkaç hafif güvenlik ve kalite kapısı koymak mantıklıdır:
- Bağımlılık güvenlik taraması (bilinen zafiyetli paket uyarısı)
- Gizli anahtarın yanlışlıkla commit edilmesini engelleyen basit kontroller
- HTTPS, oturum ve yetki gibi temel uygulama güvenlik maddeleri için yayın öncesi kontrol listesi
Kapsamlı bir güvenlik programı pipeline dosyasına sığmaz; yine de yayın ritmine bağlı kontroller, uygulama güvenliği kontrol listesi ile birlikte düşünüldüğünde riski görünür kılar. Amaç ekibi yavaşlatmak değil, “bilinen bariz hataları canlıya taşımayı” zorlaştırmaktır.
Sık yapılan hatalar ve sade düzeltmeler
Küçük ekiplerde CI/CD girişimleri çoğu zaman şu noktalarda tıkanır:
- Her şeyi ilk günden otomatikleştirmek: Önce derleme + birkaç test + staging. Canlı otomasyonu ikinci dalga olabilir.
- Kırılgan testler: Rastgele zaman aşımı ve sıralı bağımlı testler güveni bitirir. Stabil, hızlı testleri koruyun.
- Yerel ile pipeline farkı: Farklı PHP/Node sürümü veya eksik uzantı “sadece CI’da bozuluyor” üretir. Sürümleri sabitleyin.
- Manuel “acil düzeltme” alışkanlığı: Canlıda doğrudan dosya düzenlemek hattı baypas eder. Acil düzeltme de depodan geçsin.
- Gözlemlenebilirlik eksikliği: Pipeline kırmızıysa kimin neyi düzelteceği belirsizse iş birikir. Basit bir sahiplik kuralı yazın.
Bu hataların ortak kökü, otomasyonu “sihirli kutu” sanmaktır. Aslında CI/CD, ekibin zaten yaptığı adımların yazılı ve tekrarlanabilir halidir.
Sıkça Sorulan Sorular
CI/CD olmadan da yazılım çıkarılır mı?
Evet. Özellikle çok seyrek güncellenen küçük sitelerde manuel süreç sürdürülebilir. Ancak yayın sıklığı arttıkça hata ve zaman kaybı büyür; o noktada sade bir hat kurmak daha az maliyetlidir.
İki kişilik ekip CI/CD kurmalı mı?
Evet, abartmadan. İki kişi bile “birinin unuttuğu adım” riskini taşır. Minimum derleme-test ve kontrollü staging çıkışı çoğu zaman yeterlidir.
Continuous Delivery ile Continuous Deployment arasında hangisini seçmeliyiz?
Test olgunluğunuz ve geri alma planınız zayıfsa Delivery ile başlayın. Canlıya alma onayı ekipte kalsın; otomasyon paketlemeyi ve staging’i üstlensin.
Hangi testler şart?
İşinizi durduran senaryolar. Giriş, ödeme, stok, kritik bildirim veya yasal zorunlu bir akış varsa önce onları otomatikleştirin. Kapsam sonradan genişletilir.
Pipeline bozulursa ne yapmalıyız?
Kırmızı hattı “sonra bakarız” diye bırakmayın. Küçük ekiplerde bozulan pipeline, bozulan derleme veya test kadar önceliklidir; aksi halde ekip tekrar elle çalışmaya döner.
Otomatik dağıtım, doğru kurulduğunda KOBİ yazılımında hız ve sakinlik birlikte gelir: daha az “sunucuda ne vardı?” anı, daha çok izlenebilir sürüm. Kendi ürününüz için sade bir hat tasarlamak, mevcut kod tabanını ve yayın ritminizi birlikte ele almayı gerektirir. İhtiyacınıza uygun yazılım ve dağıtım yaklaşımını netleştirmek isterseniz teklif al sayfasından projenizi kısaca paylaşabilirsiniz; KepezWeb ekibi kapsamı sade adımlarla birlikte değerlendirir.
