CI/CD Pipeline Diyagramı: Commit'ten Production'a Adım Adım

CI/CD diyagramı istediğinizde genellikle karşınıza yan yana dizilmiş kutular çıkar: build, test, deploy. Bu yanlış değil, ama insanların diyagramda aradığı soruların neredeyse hiçbirini yanıtlamıyor. Tam olarak ne deploy ediliyor? Production'a kim değişiklik gönderebilir? Onaylar nerede? Nasıl geri alırız ve geri almamız gerektiğini bize ne söyler?

Bu rehber, bu soruları yanıtlayan bir CI/CD pipeline diyagramının nasıl çizileceğini yaygın bir kurulum üzerinden gösteriyor: GitHub tarzı pull request'ler, bir container registry ve Argo CD ile Kubernetes'e GitOps dağıtımları. Kurallar başka araçlar için de aynen geçerli.

Bir pipeline diyagramı neyi göstermeli

• Tetikleyiciler. Her bölümü neyin başlattığı: bir pull request, main'e merge, bir tag, bir zamanlama.
• Aşamalar ve sıraları. Lint, test, build, tarama, deploy, doğrulama.
• Artifact'ler. Aşamalar arasında taşınan şey; genellikle bir container imajı. Nasıl tanımlandığını gösterin: bir tag ya da daha iyisi, bir digest.
• Ortamlar. Artifact'in nerede çalıştığı ve oraya hangi sırayla ulaştığı.
• Geçitler. Bir değişikliği durduran manuel onaylar, zorunlu kontroller ve politikalar.
• Kimlik bilgileri. Hangi sistemin hangi ortamı değiştirebildiği.
• Geri bildirim. Production'dan gelen sinyallerin hatalı bir sürümü nasıl durdurduğu ya da geri aldığı.

Bir sıra aşama ilk ikisini karşılar. Olaylar ve denetimler ise geri kalanında yaşanır.

Örnek: Kubernetes'e GitOps

1. Bir geliştirici uygulama deposunda bir pull request açar.
2. CI her push'ta çalışır: lint, birim testleri, imaj build'i ve imaj taraması. Değişiklik main'e merge edildiğinde imajı registry'ye push eder ve digest'ini kaydeder.
3. Ardından CI, yeni imaj digest'ini ayrı bir config deposundaki staging overlay'ine commit eder.
4. Staging cluster'ındaki Argo CD commit'i fark eder, yapılandırmayı çeker ve cluster'ı senkronize eder.
5. Production'a taşımak için biri, referansı production overlay'ine kopyalayan bir pull request açar. Zorunlu inceleme, onay geçidi işlevi görür.
6. Merge'den sonra production'daki Argo CD senkronize olur; cluster'daki ayrı bir controller olan Argo Rollouts da yeni sürümü canary olarak yayına alır: önce trafiğin küçük bir kısmı, sonra tamamı.
7. Canary sırasında Argo Rollouts, Prometheus metrikleri üzerinde bir analiz çalıştırır. Analiz başarısız olursa rollout iptal edilir ve trafik kararlı sürüme geri kaydırılır; uyarılar da nöbetçi mühendisi çağırır.

Bu diyagramda gözden kaçması kolay ama çok önemli iki ayrıntı var. CI hiçbir zaman bir cluster ile konuşmaz: yalnızca imajı registry'ye push eder ve Git'e commit eder. Production ise yalnızca incelenmiş bir commit ile değişir; geri alma da aynı yoldan yapılır: commit'i revert edersiniz, Argo CD de önceki sürümü senkronize eder.

Push mu, pull mu: kimlik bilgilerinin nerede durduğunu çizin

Push tabanlı bir pipeline'da CI, cluster'ın kimlik bilgilerini tutar ve dağıtım komutunu kendisi çalıştırır. Pull tabanlı bir GitOps kurulumunda ise her cluster'ın içindeki bir ajan, örneğin Argo CD ya da Flux, istenen durumu Git'ten çekip uygular; böylece cluster dışındaki hiçbir şeyin cluster'a yazma erişimine ihtiyacı olmaz.

İkisi de geçerli bir seçim ve diyagram hangisinin seçildiğini açıkça göstermeli. Push için CI'dan her cluster'a bir kenar çizin ve kenarı kullanılan kimlik bilgisiyle etiketleyin. Pull için config deposunun her cluster'daki ajanı beslediğini çizin; CI'dan hiçbir cluster'a kenar çizmeyin. Böylece inceleyenler, sızan bir CI secret'ının etki alanını tek bakışta görebilir.

CI bulut erişimine ihtiyaç duyuyorsa, örneğin imaj push etmek için, bu erişimi nasıl aldığını not edin. OpenID Connect üzerinden alınan kısa ömürlü token'lar, diyagramda secret olarak saklanan uzun ömürlü bir anahtardan çok daha iyi bir tablo çizer.

Okunabilir bir pipeline diyagramı için kurallar

Artifact'i görünür kılın

Registry'ye giren kenarı artifact ve onun nasıl tanımlandığıyla etiketleyin: image shop-api, by digest. Tag'ler başka bir imaja kaydırılabilir; digest ise her zaman aynı imajı gösterir. Bir SBOM ya da imza da üretiyorsanız, bunları imajın yanında gösterin.

Ortamları çerçeve olarak çizin

Her ortam, deploy ajanını ve cluster'ını içinde barındıran bir çerçevedir. Çerçevelerin sırası, sürümün ortamlar arasında izlediği yolu gösterir; bir çerçeveyi atlayan her şey hemen göze çarpar.

Geçitlere kendi düğümünü verin

Onay, bir okun üzerindeki etiket değil, sahibi olan bir adımdır. Onu ortamlar arasında bir düğüm olarak çizin ve kimin onayladığını yazın: approve: release manager ya da 2 reviews required.

Döngüyü kapatın

"deploy" ile biten bir pipeline'da geri bildirim yoktur. Production'ı neyin izlediğini ve neler yapabildiğini çizin: bir canary'yi durdurmak, birini çağırmak, rollback başlatmak.

Job ayrıntılarını CI dosyasında tutun

On iki paralel test job'ı CI yapılandırmasına aittir. Diyagramda kısa bir etiketi (lint, test, build, scan) olan tek bir aşama düğümü yeterlidir.

Sık yapılan hatalar

• Artifact yok. Belirli hiçbir şey taşımayan oklarla birbirine bağlanmış kutular. Okuyan, neyin bir sonraki ortama taşındığını anlayamaz.
• Aşama olarak çizilen ortamlar. "Staging'e deploy" ve "prod'a deploy" diye yan yana iki kutu çizmek, bunların farklı izinlere sahip farklı yerler olduğunu gizler.
• Eksik rollback yolu. Kimse onu diyagramda gösteremiyorsa, muhtemelen hiç test edilmemiştir.
• Her job için bir düğüm. Diyagram CI loguna dönüşür.
• Sorumluluklar yerine araçlar. Üzerinde bir ürün adı yazan kutu, build and scan image yazan kutudan daha az şey söyler.

Archboard'da oluşturun

1. Google ya da GitHub ile giriş yapın ve bir diyagram oluşturun.
2. DevOps paketinden uygulama ve config depoları için Depo düğümleri, CI için de bir İş hattı ekleyin. Docker paketinden bir Kayıt deposu ekleyin.
3. Her ortam için Temel paketinden bir Çerçeve ekleyin; içine Argo CD için (production'da Argo Rollouts için de) DevOps paketinden bir Dağıtım düğümü ve Bulut paketinden bir Kubernetes kümesi yerleştirin.
4. Onay geçidi için Temel paketinden bir Eşkenar dörtgen şekli ekleyin.
5. DevOps paketinden Metrikler ve Uyarı düğümlerini, geliştirici ile nöbetçi mühendis için de C4 Modeli paketinden Kişi düğümlerini ekleyin.
6. Port'ları bağlayın, her kenarı üzerinden ne aktığıyla etiketleyin ve geri bildirim kenarını kesik çizgili yapın.

Örnekte 15 diyagram düğümü kullanılıyor; bu da Free planın sınırı. Gözlemlenebilirliği içeren bir pipeline için /examples/cicd-observability sayfasını açın; cluster tarafı için Kubernetes mimari diyagramı nasıl çizilir yazısına bakın.

SSS

Her CI job'ını çizmeli miyim? Hayır. Job'ları aşamalar halinde gruplayın ve ayrıntıları CI dosyasında tutun. Bir job'ı yalnızca bir geçit olduğunda ayrı çizin; örneğin sürümü engelleyen bir güvenlik taraması.

Feature flag'leri nasıl gösteririm? Production'ın yanında ayrı bir sistem olarak ve flag okuyan servislere giden bir kenarla. Flag'ler davranışı dağıtım yapmadan değiştirir; bu yüzden diyagramda kendi çizgilerini hak ederler.

Secret'lar diyagramda nereye konur? Secret'ların kendisini değil, hangi sistemin hangi kimlik bilgisini ne için tuttuğunu gösterin. CI için kısa ömürlü OIDC token'ları mı yoksa saklanan anahtarlar mı kullandığını not edin.

Her depo için ayrı bir diyagram mı gerekir? Genellikle teslimat yolu başına bir diyagram. Birçok servis aynı pipeline'ı paylaşıyorsa onu bir kez çizin ve servisleri bir notta listeleyin.

Diyagramı nasıl güncel tutarım? Pipeline değiştiğinde, CI dosyasını incelediğiniz gibi diyagramı da inceleyin. Tek bir kopya kalması için canlı diyagrama deponun README dosyasından bağlantı verin.

Ücretsiz başlayın — tek kullanıcı, kredi kartı gerekmez.