DevOps & Infrastructure 6 dk okuma

GitHub Actions ile .NET 8 CI/CD Pipeline Oluşturma Rehberi

6 dk okuma

Giriş

CI/CD, yazılım değişikliklerini daha küçük adımlarla doğrulayıp güvenli biçimde teslim etmeyi sağlayan otomasyon yaklaşımıdır. GitHub Actions ise repository içindeki olayları tetikleyici olarak kullanarak build, test, analiz, paketleme ve deployment adımlarını workflow dosyaları üzerinden çalıştırır.

.NET 8 projelerinde iyi tasarlanmış bir pipeline, geliştiricinin bilgisayarında çalışan kod ile üretime giden artefact arasındaki farkı azaltır. Her commit aynı restore, build ve test adımlarından geçtiği için süreç tekrarlanabilir hale gelir. Bu yazıda GitHub Actions kullanarak temel ama üretim ortamına taşınabilir bir .NET 8 CI/CD mimarisini adım adım ele alıyoruz.

1. CI/CD Nedir ve Neden Önemlidir?

Continuous Integration, geliştiricilerin değişikliklerini sık sık ortak branch yapısına birleştirmesini ve her değişikliğin otomatik olarak doğrulanmasını hedefler. Continuous Delivery veya Deployment ise doğrulanmış çıktının test, staging veya production ortamlarına kontrollü şekilde taşınmasını kapsar.

Pipeline kullanmak yalnızca zaman kazandırmaz. Manuel adımları azaltır, aynı işlemin farklı kişiler tarafından farklı yapılmasını önler, hatayı daha erken yakalar ve geriye dönük hangi commitin hangi artefactı ürettiğini izlenebilir hale getirir.

2. GitHub Actions Temelleri

GitHub Actions workflow dosyaları repository içinde .github/workflows klasöründe YAML formatında tutulur. Workflow bir veya daha fazla job içerir; joblar runner üzerinde çalışır ve step adımlarından oluşur.

Yaygın tetikleyiciler push, pull_request, workflow_dispatch ve schedule olaylarıdır. Pull request üzerinde build ve test çalıştırmak kalite kapısı için, main branch push sonrasında paketleme veya deploy çalıştırmak ise teslimat akışı için kullanılabilir.

3. .NET 8 Pipeline Mimarisi

Temel .NET 8 pipeline akışı checkout, SDK kurulumu, dependency restore, build ve test adımlarından oluşur. NuGet cache kullanımı pipeline süresini azaltabilir. Build sırasında Release konfigürasyonu tercih edilmeli ve test sonuçları CI sistemi tarafından raporlanabilir formatta üretilmelidir.

Çözüm birden fazla proje içeriyorsa bağımsız test projeleri paralel joblara ayrılabilir. Böylece büyük çözümlerde toplam pipeline süresi düşürülebilir. Ancak joblar arası bağımlılık ve artefact paylaşımı açık şekilde tasarlanmalıdır.

4. Örnek Workflow Yapısı

Workflow dosyasında önce hangi branch ve olayların pipelineı tetikleyeceği tanımlanır. Ardından ubuntu-latest veya ihtiyaca göre Windows runner seçilir. actions/checkout ile kod alınır, actions/setup-dotnet ile .NET 8 SDK hazırlanır ve dotnet restore, dotnet build –no-restore ve dotnet test –no-build adımları çalıştırılır.

Versiyonları sabitlemek önemlidir. Kritik action bağımlılıklarında major sürüm etiketi veya doğrulanmış commit SHA kullanmak supply-chain riskini azaltır. Pipeline izinleri de en düşük yetki prensibine göre ayarlanmalıdır.

5. Test, Build ve Kalite Kapıları

Pipeline yalnızca projenin derlenip derlenmediğini kontrol etmemelidir. Unit test, integration test, static analysis, format kontrolü ve gerektiğinde dependency/security taraması ayrı kalite kapıları olarak eklenebilir.

Pull request merge işlemini bu kontrollerin başarılı olmasına bağlamak, hatalı kodun ana branche ulaşmasını engeller. Coverage tek başına kalite ölçütü değildir; ancak kritik modüllerde gerilemeleri görmek için faydalı bir sinyaldir.

6. Artefact, Docker Image ve Publish

Build çıktısı deployment adımından ayrılmalıdır. Aynı committen üretilen artefact test ortamında doğrulandıktan sonra mümkünse yeniden build edilmeden productiona taşınmalıdır. Bu yaklaşım build once, deploy many prensibini destekler.

Docker kullanılan projelerde image pipeline içinde build edilir, commit SHA veya semantik sürümle etiketlenir ve güvenilir bir registryye push edilir. latest etiketi tek başına izlenebilirlik sağlamadığı için production dağıtımlarında değişmez sürüm etiketi tercih edilmelidir.

7. Secrets ve Güvenlik

Connection string, registry parolası, deployment tokenı veya cloud credential bilgileri repository içine yazılmamalıdır. GitHub Actions Secrets, Environment Secrets veya OpenID Connect tabanlı kısa ömürlü kimlik bilgileri kullanılabilir.

Production deployment için environment protection rules, required reviewers ve branch protection politikaları eklenebilir. Workflow token izinlerini read ağırlıklı tutmak ve yalnızca gerekli joblarda write izni vermek güvenlik açısından önemlidir.

8. Deployment ve Rollback Stratejisi

Deployment adımı hedef altyapıya göre değişir: IIS, Linux service, Docker host, Kubernetes veya cloud platformları kullanılabilir. Her durumda health check ve doğrulama adımı deploy işleminin parçası olmalıdır.

Rollback planı deploydan önce düşünülmelidir. Önceki çalışan artefactın veya image sürümünün erişilebilir olması, hatalı release durumunda hızlı dönüş sağlar. Database migration içeren release senaryolarında geri dönüş uyumluluğu ayrıca değerlendirilmelidir.

9. En İyi Uygulamalar

Pipeline sürelerini düzenli ölçün ve en yavaş adımları optimize edin. Cache kullanırken eski veya yanlış bağımlılıkların tekrar kullanılmamasına dikkat edin.

Workflowları küçük ve okunabilir tutun. Tekrarlanan adımları reusable workflow veya composite action yapısına taşıyın. Production deploy yetkisini herkesin erişebildiği genel secretlara bağlamayın.

Branch protection, CODEOWNERS, required status checks ve environment onaylarını kod kalitesi ve operasyonel güvenlikle birlikte tasarlayın. Pipeline başarısızlığını görmezden gelmek yerine başarısız pipelineı geliştirici geri bildirim döngüsünün bir parçası kabul edin.

Sonuç

GitHub Actions ve .NET 8 birlikte kullanıldığında kod değişikliğinden production teslimatına kadar güçlü bir otomasyon zinciri kurulabilir. Sağlam bir CI/CD pipeline, yalnızca deploymentı hızlandırmak değil; kaliteyi ölçmek, güvenliği artırmak ve her teslimatı izlenebilir hale getirmek için kullanılmalıdır.

Küçük bir restore-build-test workflowu ile başlayıp artefact yönetimi, Docker, güvenlik kontrolleri, environment onayları ve rollback stratejileri ekleyerek üretim seviyesinde bir teslimat platformuna dönüşmek mümkündür.

Araştırma Kaynakları ve İleri Okuma

Paylaş