Geçtiğimiz ay bir müşteri projesinde CI/CD pipeline’ımızı optimize ederken, ekibin bir kısmı daha fazla kontrol için self-hosted runner’lara yönelmek isterken, diğer kısım bakım yükünden kaçıp bulut çözümlerinin entegrasyon kolaylığını savunuyordu. Bu tartışma, aslında pek çok mühendisin kariyer yolculuğunda karşısına çıkan temel bir ikilemi yansıtıyor: self-hosted CI/CD ortamlarında derinlemesine sistem bilgisi edinmek mi, yoksa bulut tabanlı çözümlerle daha hızlı ve geniş ölçekte çalışmayı öğrenmek mi daha değerli? Benim tecrübelerime göre, bu seçimin hem anlık proje verimliliğine hem de uzun vadeli kariyer gelişimine doğrudan etkisi var.
Bu konuda tek bir “doğru” cevap yok, ancak her iki yaklaşımın da kendi içinde barındırdığı fırsatları ve zorlukları anlamak, mühendislik kariyerinizde hangi becerilere yatırım yapmanız gerektiği konusunda size net bir yol haritası sunacaktır. Hem self-hosted ortamların sağladığı derin kontrol avantajlarını hem de bulut çözümlerinin sunduğu operasyonel kolaylıkları ve entegrasyon gücünü detaylıca inceleyelim.
Self-Hosted CI/CD Ortamları Neden Hala Cazip?
Self-hosted CI/CD ortamları, özellikle büyük ve olgun şirketlerde veya çok spesifik gereksinimleri olan projelerde hala önemli bir yer tutuyor. Birkaç yıl önce çalıştığım bir üretim ERP’sinin geliştirme sürecinde, derleme ve test ortamlarının tamamen şirket içi ağda kalması gerektiği bir durum vardı; bu, hassas verilerin dışarı çıkmaması için kritikti. Bu gibi senaryolarda self-hosted çözümler, bize hem veri egemenliği hem de altyapı üzerinde tam kontrol sağlıyor.
Bu yaklaşım, mühendisler için de benzersiz bir öğrenme alanı sunuyor. Kendi sunucularınızda Jenkins, GitLab Runner veya başka bir CI/CD aracı kurduğunuzda, işletim sistemi seviyesinden (Linux kernel tuning, systemd unit’leri), ağ yapılandırmasına (VLAN segmentasyonu, firewall politikaları) ve kaynak yönetimine (cgroup limit’leri, disk I/O optimizasyonu) kadar her katmanı anlamanız gerekiyor. Bu derinlemesine bilgi, sistem mimarisi ve operasyonları alanında kariyer yapmak isteyenler için paha biçilmez bir deneyimdir. Örneğin, bir build’in neden yavaşladığını anlamak için I/O bound mı, CPU bound mı olduğunu tespit etmek, sonra da disk subsystem’ini veya çekirdek ayarlarını optimize etmek, self-hosted bir ortamda sıkça karşılaşılan ve çok şey öğreten bir durumdur.
Ancak bu derinlik, beraberinde ciddi bir bakım yükü de getiriyor. İşletim sistemi güncellemeleri, güvenlik yamaları, bağımlılık çakışmaları ve donanım arızaları gibi konularla sürekli ilgilenmek zorundasınız. Özellikle build sunucularında disk alanının dolması, Docker imajlarının şişmesi veya runner’ların çakışması gibi sorunlarla sıkça karşılaşıyorum. Bu sorunları çözmek her ne kadar öğretici olsa da, geliştirme ekibinin ana işinden zaman çalabiliyor ve operasyonel maliyetleri yükseltebiliyor. Bir üretim ortamında, bu tür aksaklıklar doğrudan deploy sürelerini etkileyip iş kaybına yol açabilir.
Bulut Tabanlı CI/CD Çözümleri Kariyerimize Ne Katıyor?
Bulut tabanlı CI/CD çözümleri (GitHub Actions, GitLab CI/CD Cloud, CircleCI, Travis CI vb.), modern yazılım geliştirme pratiklerinin hızla benimsenmesinde kilit rol oynuyor. Bu platformlar, altyapı yönetimi yükünü üzerinizden alarak geliştiricilerin ve DevOps ekiplerinin doğrudan pipeline mantığına odaklanmasını sağlıyor. Kendi yan ürünlerimin bazıları için, özellikle hızlı prototipleme ve MVP (Minimum Viable Product) aşamalarında, bulut CI/CD’nin sağladığı hız ve kolaylık inanılmaz derecede değerli oldu.
Bulut çözümleri, genellikle birkaç tıklamayla veya basit YAML konfigürasyonlarıyla karmaşık CI/CD iş akışları oluşturmanıza olanak tanır. Bu, özellikle küçük ve orta ölçekli ekipler için ilk yatırım maliyetini ve operasyonel yükü düşürür. Kariyer perspektifinden baktığımızda, bulut CI/CD deneyimi, size modern DevOps kültürünü, Infrastructure as Code (IaC) prensiplerini ve farklı bulut servisleriyle entegrasyon yeteneğini kazandırır. GitHub Actions ile bir depoya push yapıldığında otomatik testlerin koşması, konteyner imajlarının derlenip bir container registry’ye gönderilmesi veya bir bulut ortamına deploy edilmesi gibi senaryoları çok daha hızlı bir şekilde hayata geçirebilirsiniz.
Ancak bulut çözümlerinin de kendi kısıtları var. Esneklik, self-hosted bir ortama göre daha azdır. Bazen çok spesifik bir derleme ortamına veya özel bir donanıma ihtiyacınız olduğunda, bulut sağlayıcının sunduğu kısıtlı seçeneklerle yetinmek zorunda kalabilirsiniz. Ayrıca, maliyetler belirli bir ölçeğin üzerine çıktığında beklenenden daha yüksek olabilir. Özellikle çok sayıda ve uzun süreli build’leriniz varsa, bulut runner’larının dakika başına ücretlendirme modelleri ciddi bir fatura çıkarabilir. Geçenlerde bir mobil uygulamamın CI/CD sürecinde, her commit’te tüm testleri koşturmak, build süresi uzadıkça maliyeti belirgin bir şekilde artırmıştı; bu durumda optimize edilmiş bir cache stratejisi geliştirmek zorunda kaldım.
Kariyer Yolculuğunda Hangi Yol Daha Değerli: Teknik Derinlik mi, Hız mı?
Bu soru, mühendislik kariyerinizde ne tür bir uzmanlık alanı geliştirmek istediğinize bağlı. Self-hosted CI/CD ortamlarıyla çalışmak, size sistemlerin “nasıl çalıştığı” konusunda eşsiz bir derinlik kazandırır. Bu yolda ilerleyen bir mühendis, genellikle Linux sistem yönetimi, ağ mimarisi, güvenlik hardening (fail2ban paternleri, kernel module blacklist), depolama çözümleri (iSCSI, NFS) ve veritabanı optimizasyonu (PostgreSQL connection pool tuning, WAL bloat yönetimi) gibi alanlarda uzmanlaşır. Bu beceriler, özellikle altyapı, SRE (Site Reliability Engineering) veya sistem güvenliği rollerinde çok aranan niteliklerdir. Bir üretim ERP’sinde, performans sorunlarının kök nedenini bulmak için işletim sistemi metriklerinden, ağ paket analizine kadar inebilen birisi olarak, bu derinliğin değerini çok iyi biliyorum.
Öte yandan, bulut tabanlı CI/CD çözümlerine odaklanmak, size modern yazılım geliştirme süreçlerinin “nasıl daha hızlı ve verimli hale getirileceği” konusunda uzmanlık sağlar. Bu yolda ilerleyen bir mühendis, genellikle bulut platformlarının API’leri, serverless mimariler, konteyner orkestrasyonu (Docker Compose, Kubernetes’e hazırlık), Infrastructure as Code araçları (Terraform, CloudFormation) ve observability (metrik, log, trace) konularında yetkinleşir. Bu beceriler, özellikle DevOps mühendisi, bulut mimarı veya hızlı ürün geliştirme ekiplerinde çok değerlidir. Mobil tarafta, Flutter ile native paket entegrasyonu yaparken veya Play Store yayınlama süreçlerini otomatize ederken, bulut CI/CD’nin sunduğu entegrasyon kolaylığı ve hızı benim için belirleyici oluyor.
Bence ideal olan, her iki dünyanın da temel prensiplerine hakim olmaktır. Bir projenin ihtiyacına göre self-hosted bir Jenkins’i ayağa kaldırabilirken, diğer bir projede GitHub Actions ile hızlı bir deploy pipeline’ı tasarlayabilmelisiniz. Bu adaptasyon yeteneği, günümüzün hızla değişen teknoloji dünyasında en değerli becerilerden biridir.
Maliyet Faktörü ve Kariyer Kararları: Kimin Cebinden Çıkıyor?
Maliyet, CI/CD çözümü seçerken her zaman masadaki en önemli faktörlerden biri olmuştur ve bu durum kariyer kararlarımızı da etkiliyor. Self-hosted bir CI/CD sistemi kurmanın başlangıç maliyeti, sunucu donanımı, ağ ekipmanları ve lisanslar (açık kaynak kullanmıyorsanız) gibi kalemleri içerir. Ancak uzun vadede, yüksek hacimli build’ler için operasyonel maliyetler (elektrik, soğutma, bakım) genellikle bulut çözümlerinden daha düşük olabilir. Bir üretim firmasında, mevcut sunucu altyapısının atıl kapasitesini kullanarak CI/CD runner’ları çalıştırmak, bulut faturalarından belirgin bir tasarruf sağlamıştı.
Bulut tabanlı CI/CD çözümleri ise, genellikle kullandıkça öde (pay-as-you-go) modeliyle çalışır. Başlangıç maliyetleri düşüktür, hatta küçük projeler için ücretsiz katmanları bile vardır. Bu, özellikle yeni başlayanlar veya bireysel geliştiriciler için harika bir fırsattır, çünkü yüksek bir yatırım yapmadan modern CI/CD pratiklerini deneyimleyebilirler. Kendi yan ürünlerimden birinin backend’i için, ilk aşamalarda bulut CI/CD’nin ücretsiz katmanları sayesinde ciddi bir maliyet avantajı elde ettim. Ancak ölçek büyüdükçe, build süreleri uzadıkça veya paralel build sayınız arttıkça maliyetler hızla yükselebilir.
Maliyetin kariyer kararlarımıza etkisi ise şöyle:
- Self-hosted tarafında: Maliyet optimizasyonu genellikle donanım seçimi, enerji verimliliği, sistem kaynaklarının verimli kullanımı (cgroup limit’leri, disk depolama stratejileri) ve iş yükü planlaması gibi konuları içerir. Bu alanda uzmanlaşanlar, şirketlere doğrudan operasyonel giderlerden tasarruf ettirebilir ve bu da onların değerini artırır.
- Bulut tarafında: Maliyet optimizasyonu, pipeline’ların verimli yazılması (gereksiz adımlardan kaçınma), cache stratejileri, uygun runner boyutlarının seçimi ve bulut sağlayıcının sunduğu indirim modellerini anlama üzerine kuruludur. Bulut maliyetlerini etkin bir şekilde yönetebilen bir mühendis, modern bulut ortamlarında büyük bir avantaja sahip olur.
Her iki durumda da, maliyet bilinci ve optimizasyon yeteneği, bir mühendisin değerini artıran kritik becerilerdir. Hangi platformu seçerseniz seçin, kaynakları verimli kullanma ve israftan kaçınma prensipleri her zaman geçerlidir.
Güvenlik Perspektifinden CI/CD Seçimleri: Hangi Ortam Daha Öğretici?
CI/CD pipeline’ları, bir yazılımın üretim ortamına ulaşmadan önceki son duraklarından biridir, bu yüzden güvenlik burada hayati önem taşır. Hatalı yapılandırılmış bir CI/CD ortamı, bir güvenlik açığına veya hatta tüm sistemin ele geçirilmesine yol açabilir. Bu alandaki seçimlerimizin kariyerimize güvenlik perspektifinden ne kattığına bakalım.
Self-hosted CI/CD ortamları, size güvenlik üzerinde mutlak kontrol sağlar, ancak bu kontrol aynı zamanda büyük bir sorumluluk demektir. Bir yandan, kendi ağınızda VLAN segmentasyonu yaparak, runner’ları izole ederek ve firewall kuralları belirleyerek sıkı güvenlik politikaları uygulayabilirsiniz. Kernel module’lerin blacklist’e alınması (örneğin, CVE-2026-31431 gibi bir açığı önlemek için algif_aead gibi modüllerin devre dışı bırakılması), dosya bütünlüğü monitoring (auditd) ve fail2ban paternleri ile SSH brute-force saldırılarına karşı korunma gibi konular, self-hosted ortamlarda doğrudan sizin sorumluluğunuzdadır. Bu durum, güvenlik konusunda derinlemesine bilgi edinmek ve pratik hardening becerileri geliştirmek için harika bir fırsattır.
Bulut tabanlı CI/CD çözümleri ise, güvenlik sorumluluğunu bulut sağlayıcı ile paylaşılan sorumluluk modeline (shared responsibility model) göre dağıtır. Sağlayıcı, temel altyapının (fiziksel sunucular, ağ) güvenliğinden sorumluyken, siz kendi kodunuzun, konfigürasyonlarınızın ve pipeline’larınızın güvenliğinden sorumlusunuz. Bu, bulut platformlarının IAM (Identity and Access Management) politikalarını, secret yönetimini, güvenlik gruplarını ve diğer platforma özgü güvenlik özelliklerini öğrenmeniz gerektiği anlamına gelir. Örneğin, GitHub Actions’ta bir secret’ı doğru bir şekilde yönetmek veya yetkilendirme kapsamını minimuma indirmek, bulut güvenliğinin temelini oluşturur. Bu alanda uzmanlaşmak, size modern bulut güvenliği pratiklerini ve bu platformların sunduğu araçları etkili bir şekilde kullanma yeteneği kazandırır.
Benim tecrübelerime göre, her iki ortam da farklı güvenlik becerileri geliştirmenizi sağlar. Self-hosted ortamlar, “low-level” sistem güvenliği ve ağ hardening konularında sizi çok daha yetkin hale getirirken, bulut ortamları “high-level” platform güvenliği, kimlik yönetimi ve otomasyon güvenliği konularında uzmanlaşmanızı sağlar. En iyi kariyer stratejisi, her iki alandaki temel güvenlik prensiplerini anlamak ve projenin gerektirdiği güvenlik seviyesine göre doğru araçları seçebilme yeteneğini geliştirmektir.
Self-Hosted CI/CD Kurulumunda Karşılaştığım Zorluklar ve Çözümleri
Birkaç yıl önce, büyük bir e-ticaret sitesinin iç platformu için self-hosted GitLab Runner’ları kurarken ciddi bir baş ağrısı yaşamıştım. Proje, çok sayıda microservice içeriyordu ve her birinin kendine ait bağımlılıkları vardı. İlk kurulumda, runner’ların aynı sunucu üzerinde farklı projeler için izole bir şekilde çalışmasını sağlamak zor oldu. Özellikle Docker-in-Docker (DinD) senaryolarında, konteynerler arası kaynak çakışmaları ve ağ izolasyonu problemleriyle karşılaştım.
Sorun şuydu: bir projenin build’i, diğer projenin kaynaklarını tüketiyor, bu da build sürelerinin öngörülemez hale gelmesine ve bazen de build’lerin OOM-killed olmasına neden oluyordu. İlk başta cgroup limit’lerini manuel olarak ayarlamaya çalıştım, ancak bu her yeni proje eklendiğinde veya bağımlılıklar değiştiğinde çok zahmetli bir hal alıyordu. Ayrıca, farklı runner’ların aynı Docker cache’ini kullanmaya çalışması da kilitlenmelere yol açıyordu.
Çözüm olarak, öncelikle GitLab Runner konfigürasyonunda concurrent limitlerini ve limit ayarlarını daha dikkatli bir şekilde yapılandırdım. Her bir runner’ın kendi Docker daemon’unu kullanmasını sağlamak yerine, docker:dind servislerini ayrı bir şekilde ayağa kaldırıp, runner’ların bu servislere bağlanmasını sağladım. Ancak asıl çözüm, her microservice için ayrı bir runner tag’i tanımlamak ve her runner sunucusunu belirli bir microservice grubuna atamaktı. Böylece, yoğun kaynak kullanan servisler kendi izole runner’larında çalışabiliyor, diğerleri ise daha hafif runner’ları kullanıyordu.
# /etc/gitlab-runner/config.toml
concurrent = 4 # Aynı anda çalışacak iş sayısı
check_interval = 0
[[runners]]
name = "backend-runner-01"
url = "https://gitlab.example.com/"
token = "YOUR_GITLAB_RUNNER_TOKEN"
executor = "docker"
[runners.docker]
tls_verify = false
image = "docker:latest"
privileged = false # Güvenlik için false tutmaya çalıştım
disable_entrypoint_overwrite = false
oom_kill_disable = false
hostname = ""
# Docker-in-Docker için servisleri tanımlama
services = ["docker:dind"]
volumes = ["/var/run/docker.sock:/var/run/docker.sock", "/cache"]
# Kaynak limitleri
memory = "4g"
cpus = "2"
[runners.cache]
Type = "s3" # Veya başka bir cache backend
Shared = true
[runners.tags]
tags = ["backend", "production"]Bu ayarlamalarla, hem kaynak çakışmalarını azalttım hem de build sürelerini daha öngörülebilir hale getirdim. Bu süreç, bana sadece GitLab Runner’ın derinlemesine konfigürasyonunu değil, aynı zamanda Docker’ın kaynak yönetimi ve ağ izolasyonu mekanizmalarını da çok iyi öğretti. Kendi hatalarımdan ders çıkararak, benzer sorunları gelecekte daha hızlı teşhis etme ve çözme yeteneği kazandım.
Bulut CI/CD’de Gözlemlediğim Kısıtlar ve Esneklik Sınırları
Bulut tabanlı CI/CD çözümleri genellikle “her şeyi yapar” gibi lanse edilse de, benim tecrübelerimde bazı kısıtları ve esneklik sınırları olduğunu gördüm. Özellikle çok spesifik veya düşük seviyeli işlemlere ihtiyacınız olduğunda bu sınırlar daha belirgin hale geliyor.
Örneğin, kendi Android spam uygulamamın CI/CD pipeline’ını GitHub Actions üzerinde kurarken, bazen native C/C++ kodu derlemem veya özel bir donanım emülatörünü çalıştırmam gerekti. GitHub Actions’ın standart runner’ları bu tür senaryolar için yeterli esnekliği sunmuyordu. Özel bir kernel modülü yüklemek veya belirli bir donanım arayüzüne doğrudan erişmek imkansızdı. Bu durumda, ya iş akışını tamamen değiştirmek ya da bu adımları self-hosted bir runner’a delege etmek zorunda kaldım.
Bir diğer kısıt, vendor lock-in riski. Bulut sağlayıcıya ne kadar derin entegre olursanız, başka bir platforma geçiş yapmak o kadar zorlaşır. GitHub Actions’ın özel eylemleri, Azure DevOps’un pipeline şablonları veya GitLab CI’ın özel include mekanizmaları, belirli bir ekosisteme sizi bağlar. Bir projede, mevcut CI/CD pipeline’ımızı bir bulut sağlayıcısından diğerine taşımak, beklenenden daha fazla zaman ve çaba gerektirdi çünkü her şey sağlayıcının kendi özel DSL’ine (Domain Specific Language) göre yazılmıştı.
Maliyet de, belirli bir eşiğin üzerinde bir kısıt haline gelebilir. Başlangıçta cazip olan bulut runner’ları, büyük ölçekli ve sık build’lerde hızla pahalı hale gelebilir. Özellikle uzun süreli entegrasyon testleri veya kompleks derleme süreçleri olan projelerde, bulut faturaları beklenmedik boyutlara ulaşabiliyor. Bu durumda, maliyetleri düşürmek için build sürelerini optimize etmek, akıllı önbellekleme stratejileri geliştirmek veya daha ucuz self-hosted runner’ları devreye sokmak gibi çözümler düşünmek zorunda kalıyorum. Yani, bulut çözümleri “sadece kullan” kolaylığı sunsa da, gerçek dünya senaryolarında hala ince ayar ve stratejik planlama gerektiriyor.
Sonuç
Self-hosted CI/CD mi yoksa bulut çözümleri mi sorusunun cevabı, kariyer hedeflerinize, çalıştığınız projenin ihtiyaçlarına ve şirketinizin kaynaklarına göre değişir. Eğer sistemlerin derinliklerine inmek, altyapı yönetimi, ağ güvenliği ve performans optimizasyonu gibi alanlarda uzmanlaşmak istiyorsanız, self-hosted ortamlar size eşsiz bir öğrenme platformu sunar. Bu yol, sizi daha çok SRE, altyapı mühendisi veya güvenlik uzmanı rollerine hazırlar.
Diğer yandan, hızlı teslimat, modern DevOps pratikleri, bulut platformlarının API’leri ve otomasyon becerileri üzerine odaklanmak istiyorsanız, bulut tabanlı CI/CD çözümleri size daha geniş bir yelpaze sunar. Bu yol ise sizi daha çok DevOps mühendisi, bulut mimarı veya yazılım geliştirici rollerinde güçlendirir.
Benim tecrübelerime göre, en değerli mühendisler her iki dünyanın da temel prensiplerine hakim olanlardır. Bir projede self-hosted bir Jenkins’i ayağa kaldırabilirken, diğer bir projede GitHub Actions ile hızlı bir deploy pipeline’ı tasarlayabilmek, sizi çok yönlü ve adapte olabilir kılar. Bu adaptasyon yeteneği, teknolojinin hızla değiştiği bu dönemde kariyerinizi güvence altına almanın en sağlam yoludur. Unutmayın, önemli olan bir teknolojiye körü körüne bağlanmak değil, doğru zamanda doğru aracı seçebilme bilgeliğine sahip olmaktır.