4 dk okuma
Giriş
Bir .NET uygulamasını Docker’a almak kolaydır; güvenilir şekilde build, test ve deploy etmek ise ayrı bir konudur. CI/CD sürecinin amacı yalnızca sunucuya dosya kopyalamak değil, her değişikliğin aynı kalite kontrollerinden geçmesini ve aynı şekilde paketlenmesini sağlamaktır.
.NET Docker CI/CD sürecini GitHub Actions ile kurarken pipeline’ı küçük ve anlaşılır adımlara ayırmak, secret yönetimini doğru yapmak ve container image’ı üretim için sade tutmak önemlidir.
1. Local build ile pipeline build aynı olmalı
CI ortamında çalışan komutların geliştiricinin localde kullandığı komutlarla mümkün olduğunca aynı olması hata ayıklamayı kolaylaştırır.
Temel bir .NET pipeline çoğunlukla restore, build ve test adımlarından oluşur. GitHub’ın .NET Actions rehberi de dotnet restore, dotnet build ve dotnet test komutlarını temel akış olarak gösterir.
Build komutlarını özel shell scriptlere gömmek gerekiyorsa bu scriptlerin localde de çalıştırılabilir olması iyi bir pratiktir.
2. Multi-stage Docker build kullanın
Docker’ın multi-stage build yaklaşımı compile için gereken SDK ile production’da gereken runtime’ı ayırmayı sağlar.
İlk stage’de dotnet restore ve publish yapılır. Son stage’de yalnızca publish çıktısı runtime image’a kopyalanır. Böylece final image içinde SDK, kaynak kod ve build araçları bulunmaz.
Docker dokümantasyonu multi-stage build’in final image boyutunu küçültmek ve build-time bağımlılıklarını runtime’dan ayırmak için kullanılmasını öneriyor.
3. Docker cache’i bilinçli kullanın
Dockerfile içindeki COPY sırası build süresini ciddi biçimde etkileyebilir. Önce csproj/sln dosyalarını kopyalayıp restore yapmak, daha sonra kaynak kodu kopyalamak NuGet restore katmanının cache’de kalmasını sağlar.
Aynı mantık .dockerignore için de geçerlidir. bin, obj, .git, test çıktıları veya gereksiz büyük dosyalar build context’e gönderilmemelidir.
4. Test geçmeden image yayınlamayın
Pipeline’da image build adımı testlerden sonra çalışmalıdır. Unit ve integration testler başarısız olduğunda artifact veya image yayınlamak deployment riskini artırır.
Test sonuçlarını GitHub Actions artifact olarak saklamak, başarısız build’lerde log ve raporların sonradan incelenmesini kolaylaştırır.
5. Tag stratejisini belirleyin
latest etiketi tek başına yeterli değildir. Deploy edilen image’ın hangi commit’ten üretildiğini bilmek için Git SHA veya release version ile tag oluşturmak faydalıdır.
Örneğin uygulama:1.4.2 ve uygulama:git-abc123 gibi etiketler rollback ve audit süreçlerini kolaylaştırır.
Production deployment’ta immutable tag kullanmak, aynı tag’in farklı image’ları göstermesi riskini azaltır.
6. Secret’ları image içine koymayın
Connection string, API key veya sertifika parolası Dockerfile içinde ENV olarak hardcode edilmemelidir. Aynı şekilde appsettings.Production.json dosyasına gerçek secret ekleyip image içine kopyalamak da risklidir.
GitHub Actions Secrets, environment secret veya hedef ortamın secret store’u kullanılabilir. Container başlarken gerekli değerler environment variable veya secret mount olarak verilmelidir.
7. Deployment’ı health check ile tamamlayın
Container’ın çalışıyor görünmesi uygulamanın hazır olduğu anlamına gelmez. Uygulamanın veri tabanına veya gerekli servislerine erişebildiğini kontrol eden readiness endpoint’i deployment doğrulaması için kullanılabilir.
Yeni versiyon ayağa kalktıktan sonra health check başarısızsa otomatik rollback veya deployment başarısızlığı üretilmesi daha güvenlidir.
8. CI ile CD’yi gerektiğinde ayırın
Her branch push’unda production deploy etmek çoğu ekip için doğru yaklaşım değildir. Pull request’te CI çalıştırıp build/test yapmak; release, tag veya protected branch üzerinde CD tetiklemek daha kontrollü bir modeldir.
GitHub Environments kullanıldığında production gibi ortamlar için ek onay ve secret ayrımı uygulanabilir.
Pipeline’ın amacı mümkün olduğunca otomasyon sağlamak ama kritik production adımlarında gerekli kontrol noktalarını korumaktır.
Sonuç
.NET Docker CI/CD yapısında en iyi sonuç karmaşık YAML dosyalarından değil, tekrar üretilebilir build ve net deployment kurallarından gelir.
Multi-stage image, test zorunluluğu, immutable tag, secret yönetimi ve health check birlikte kullanıldığında deployment süreci daha güvenli ve öngörülebilir hale gelir. GitHub Actions ise bu adımları repository olaylarıyla otomatikleştirmek için güçlü ve pratik bir araçtır.
