Azure DevOps ile Semantic Release Kullanarak Manuel Sürüm Yükseltmeleri: Detaylı Bir Kılavuz
Yazılım geliştirme süreçlerinde sürüm yönetimi, projelerin düzenini, izlenebilirliğini ve kalitesini doğrudan etkileyen kritik bir adımdır. Özellikle büyük ve karmaşık projelerde, doğru sürümleme stratejileri benimsemek, hem geliştirici ekiplerinin iş yükünü hafifletir hem de son kullanıcıya sunulan ürünün istikrarını garantiler. Bu makalede, modern CI/CD dünyasının vazgeçilmez araçlarından Azure DevOps ve otomatik sürümleme felsefesinin güçlü temsilcisi Semantic Release’i bir araya getirerek, manuel tetiklemeli sürüm yükseltmelerini nasıl daha verimli ve hatasız hale getirebileceğimizi detaylı bir şekilde inceleyeceğiz.
Giriş: Semantik Sürümleme ve Önemi
Yazılım projelerinde sürüm numaraları, bir projenin gelişimini ve değişikliklerini ifade eden önemli göstergelerdir. Ancak bu numaraların rastgele verilmesi, hem geliştiriciler hem de kullanıcılar için kafa karışıklığına yol açabilir. Semantik Sürümleme (Semantic Versioning), bu karmaşayı ortadan kaldırmak için tasarlanmış basit ama etkili bir standarttır.
Semantik Sürümleme Temelleri
Semantik Sürümleme, MAJOR.MINOR.PATCH formatında üç parçalı bir sürüm numarası kullanır. Her bir parça, yapılan değişikliklerin türünü gösterir:
* MAJOR (Büyük): Geriye dönük uyumluluğu bozan (breaking changes) API değişiklikleri yapıldığında artırılır.
* MINOR (Küçük): Geriye dönük uyumlu yeni özellikler (new features) eklendiğinde artırılır.
* PATCH (Yama): Geriye dönük uyumlu hata düzeltmeleri (bug fixes) yapıldığında artırılır.
Bu yapı, bir sürüm numarasını gören herkesin, o sürümde ne tür değişiklikler bekleyebileceği konusunda net bir fikre sahip olmasını sağlar.
Neden Semantik Sürümleme Kullanmalıyız?
Semantik Sürümleme, yazılım ekosisteminde birçok fayda sağlar:
* Net İletişim: Geliştiriciler ve kullanıcılar arasında sürüm değişiklikleri hakkında net bir dil oluşturur.
* Bağımlılık Yönetimi: Diğer projelerle entegrasyonu olan projelerde, bağımlılıkların uyumluluğunu yönetmeyi kolaylaştırır.
* Risk Azaltma: Geriye dönük uyumsuzlukların ne zaman bekleneceğini bilmek, yükseltme risklerini azaltır.
* Otomasyon Dostu: Otomatik sürümleme araçları için ideal bir temel sunar.
Manuel Sürümlemenin Riskleri
Geleneksel manuel sürümleme yöntemleri, özellikle büyük ekiplerde ve hızlı geliştirme döngülerinde ciddi riskler taşır:
* İnsan Hatası: Sürüm numaralarının unutulması, yanlış girilmesi veya standartlara uygun olmaması.
* Tutarsızlık: Farklı geliştiricilerin farklı sürümleme yaklaşımları benimsemesi.
* Geliştirme Hızı Engeli: Her sürümde manuel müdahale gerekliliği, CI/CD süreçlerini yavaşlatır.
* İzlenebilirlik Eksikliği: Hangi değişikliğin hangi sürümle ilişkilendirildiğini takip etmek zorlaşır.
Semantic Release Nedir ve Neden Kullanılır?
Semantic Release, geliştirme süreçlerinizi otomatikleştirmek ve sürüm yönetimini kolaylaştırmak için tasarlanmış güçlü bir araçtır. Projenizin Git commit geçmişini analiz ederek, Semantik Sürümleme kurallarına uygun olarak yeni sürüm numaralarını otomatik olarak belirler, Git etiketlerini (tags) oluşturur ve değişiklik günlüklerini (changelog) günceller.
Otomatik Sürümleme Felsefesi
Semantic Release’in temel felsefesi, sürümleme kararının insan müdahalesi yerine commit mesajlarının içeriğine dayanmasıdır. Bu, geliştiricilerin sadece anlamlı ve standartlaştırılmış commit mesajları yazmaya odaklanmasını sağlar. Örneğin, fix: düzeltme yapıldı mesajı bir PATCH sürümünü tetiklerken, feat: yeni özellik eklendi bir MINOR sürümünü tetikler.
Temel Bileşenleri
Semantic Release, bir dizi eklenti (plugins) aracılığıyla çalışır. Bu eklentiler, farklı görevleri yerine getirir:
* @semantic-release/commit-analyzer: Commit mesajlarını analiz eder ve sürüm türünü (major, minor, patch) belirler.
* @semantic-release/release-notes-generator: Analiz edilen commit’lerden değişiklik günlüğü oluşturur.
* @semantic-release/changelog: Değişiklik günlüğünü bir dosyaya (örn. CHANGELOG.md) yazar.
* @semantic-release/npm: package.json dosyasındaki sürüm numarasını günceller ve npm paketini yayınlar.
* @semantic-release/git: Güncellenmiş dosyaları (changelog, package.json) commit eder ve yeni bir Git etiketi oluşturur.
* @semantic-release/github veya @semantic-release/azure-devops: GitHub veya Azure DevOps üzerinde release oluşturur.
Avantajları
Semantic Release kullanmanın başlıca avantajları şunlardır:
* Tutarlılık: Tüm sürümler Semantik Sürümleme standartlarına uygun olur.
* Otomasyon: Manuel sürümleme hatalarını ortadan kaldırır ve süreci hızlandırır.
* Geliştirici Odaklılık: Geliştiriciler sürüm numaralarını düşünmek yerine koda odaklanır.
* Şeffaflık: Otomatik olarak oluşturulan değişiklik günlükleri sayesinde, her sürümdeki değişiklikler net bir şekilde görülebilir.
Azure DevOps Ortamında Sürümleme Yaklaşımları
Azure DevOps, kapsamlı CI/CD yetenekleri sunan entegre bir platformdur. Sürümleme, Azure Pipelines’ın temel bir parçasıdır ve çeşitli yaklaşımlarla uygulanabilir.
Geleneksel Sürümleme Yöntemleri
Azure Pipelines’ta geleneksel olarak sürüm numaraları, genellikle derleme numaraları veya manuel olarak belirlenen değişkenler aracılığıyla yönetilir.
* Derleme Numarası: $(Build.BuildNumber) gibi ön tanımlı değişkenler, her derleme için benzersiz bir numara sağlar. Ancak bu numaralar genellikle anlamsızdır ve Semantik Sürümleme kurallarına uymaz.
* Manuel Değişkenler: Kullanıcılar, pipeline’da manuel olarak major, minor, patch değişkenleri tanımlayabilir ve bunları elle güncelleyebilir. Bu da manuel sürümlemenin getirdiği riskleri barındırır.
Azure Pipelines ve Sürüm Numaraları
Azure Pipelines, semver gibi yerleşik fonksiyonlar sunmaz, ancak özel betikler (script) veya eklentilerle Semantik Sürümleme uygulanabilir. semantic-release gibi araçlar, bu boşluğu doldurarak Azure Pipelines’ın gücünü Semantik Sürümleme ile birleştirir.
Git Akış Modelleri ve Sürümleme
Farklı Git akış modelleri (Git Flow, GitHub Flow, GitLab Flow), sürümleme stratejilerini etkiler. Semantic Release, özellikle main (veya master) branch’ine yapılan commit’ler üzerinden otomatik sürümleme yapmak için tasarlanmıştır. Bu, genellikle GitHub Flow veya GitLab Flow gibi daha basit ve sürekli entegrasyonu teşvik eden modellerle iyi uyum sağlar. Manuel tetikleme, bu modellerin dışında, örneğin belirli bir release branch’inden veya özel bir durum için sürüm oluşturma ihtiyacında devreye girebilir.
Manuel Sürüm Yükseltmelerinin Zorlukları ve Çözümler
Manuel sürüm yükseltmeleri, yukarıda bahsedildiği gibi birçok zorluk içerir. Ancak bazı durumlarda, özellikle kritik yamalar, acil durum düzeltmeleri veya özel yayın süreçleri için manuel müdahale gerekebilir. Burada önemli olan, manuel müdahaleyi otomasyonun gücüyle birleştirmektir.
İnsan Hatası Faktörü
Manuel sürüm yükseltmelerinde en büyük risk, insan hatasıdır. Yanlış bir sürüm numarasının girilmesi, CHANGELOG.md dosyasının güncellenmemesi veya Git etiketinin atlanması gibi durumlar, projenin sürüm geçmişinde tutarsızlıklara yol açabilir.
Tutarsızlık ve Karmaşa
Birden fazla geliştiricinin aynı projede çalışması durumunda, manuel sürümleme kurallarının veya standartlarının tam olarak takip edilmemesi, sürüm numaralarında ve süreçlerde tutarsızlığa neden olabilir. Bu da hem iç ekipler hem de dış bağımlılıklar için kafa karıştırıcı olabilir.
Otomasyonun Rolü
Semantic Release gibi araçlar, bu zorlukların üstesinden gelmek için otomasyonu devreye sokar. Manuel tetiklemeli bir pipeline’da bile, sürüm yükseltme adımlarının Semantic Release tarafından yönetilmesi, tutarlılığı ve doğruluğu garanti eder. Geliştiricinin tek yapması gereken, pipeline’ı manuel olarak tetiklemek ve Semantic Release’in gerisini halletmesini sağlamaktır.
Azure DevOps ile Semantic Release Entegrasyonu
Azure DevOps ve Semantic Release’i bir araya getirmek, güçlü ve esnek bir sürümleme süreci oluşturmanızı sağlar. Bu entegrasyon, özellikle manuel tetiklemeli bir senaryoda, otomasyonun avantajlarından faydalanırken kontrolü elinizde tutmanıza olanak tanır.
Gerekli Araçlar ve Eklentiler
Entegrasyon için başlıca ihtiyaçlar şunlardır:
* Node.js: Semantic Release bir Node.js uygulamasıdır, bu yüzden pipeline’ınızda Node.js kurulu olmalıdır.
* semantic-release paketi: Projenizin devDependencies kısmına eklenmelidir.
* @semantic-release/git: Değişiklikleri Git deposuna geri yazmak için kullanılır.
* @semantic-release/changelog: Değişiklik günlüğü oluşturmak için.
* @semantic-release/npm: Eğer bir npm paketi yayınlıyorsanız.
* @semantic-release/azure-devops (isteğe bağlı): Azure DevOps release’leri oluşturmak için.
* Kişisel Erişim Belirteci (PAT): Semantic Release’in Git deposuna yazma ve etiket oluşturma yetkisine sahip olması için bir PAT gereklidir.
Pipeline Yapılandırması
Azure DevOps YAML pipeline’ınızda Semantic Release’i çalıştırmak için bir script görevi eklemeniz gerekir. Bu script, semantic-release komutunu çalıştıracaktır.
trigger: none # Manuel tetikleme için
pool:
vmImage: 'ubuntu-latest'
variables:
GIT_AUTHOR_NAME: 'Azure DevOps Build'
GIT_AUTHOR_EMAIL: 'azuredevops@example.com'
# PAT'i güvenli bir şekilde saklayın ve pipeline değişkeni olarak kullanın
# Örneğin, bir Secret Variable grubundan veya pipeline değişkeni olarak gizli tutun
# SEMANTIC_RELEASE_TOKEN: $(System.AccessToken) veya özel bir PAT
steps:
- task: NodeTool@0
inputs:
versionSpec: '16.x'
displayName: 'Install Node.js'
- script: |
npm ci
displayName: 'Install Dependencies'
- script: |
npx semantic-release
displayName: 'Run Semantic Release'
env:
# Git push işlemleri için bir PAT gereklidir.
# Bu PAT'in "Code (Read & write)" izinlerine sahip olması gerekir.
# $(System.AccessToken) genellikle sadece okuma izni verir, bu yüzden özel bir PAT daha iyidir.
# AZURE_DEVOPS_TOKEN: $(System.AccessToken) # Eğer bu token yeterli yetkiye sahipse
# Veya daha güvenli bir şekilde:
AZURE_DEVOPS_TOKEN: $(PAT_FOR_SEMANTIC_RELEASE) # Kendi oluşturduğunuz PAT değişkeni
# Diğer gerekli ortam değişkenleri (örn. NPM_TOKEN eğer npm'e yayın yapılıyorsa)Kimlik Doğrulama ve Yetkilendirme
Semantic Release'in Git deposuna commit yapabilmesi ve etiket oluşturabilmesi için uygun kimlik doğrulama yetkilerine sahip olması gerekir.
* System.AccessToken: Azure Pipelines'ın varsayılan olarak sağladığı bu token, genellikle sadece okuma iznine sahiptir. Git'e yazma işlemleri için yeterli olmayabilir.
* Kişisel Erişim Belirteci (PAT): En güvenli ve önerilen yöntem, "Code (Read & write)" izinlerine sahip bir PAT oluşturmak ve bunu Azure DevOps pipeline'ınızda bir gizli değişken olarak kullanmaktır. Bu PAT, AZURE_DEVOPS_TOKEN veya benzeri bir ortam değişkeni olarak Semantic Release'e sağlanır.
Önemli: PAT'inizi doğrudan YAML dosyasına yazmayın. Azure DevOps'ta "Variable group" veya pipeline değişkenleri bölümünde "secret" olarak işaretleyerek güvenli bir şekilde saklayın.
Manuel Tetikleme ve Sürüm Yükseltme Süreci
Manuel tetiklemeli bir sürüm yükseltme senaryosunda, bir geliştirici veya yayın yöneticisi, belirli bir zamanda veya belirli bir ihtiyaç doğrultusunda sürüm oluşturma pipeline'ını başlatır.
Özel Pipeline Tetikleyicileri
Yukarıdaki YAML örneğinde trigger: none kullanılması, pipeline'ın otomatik olarak tetiklenmesini engeller. Bu pipeline, sadece Azure DevOps arayüzünden manuel olarak "Run pipeline" seçeneğiyle başlatılabilir.
Sürümleme Adımlarının Tanımlanması
Manuel tetiklemeli pipeline'da Semantic Release'in çalıştırılması, tüm sürümleme adımlarını otomatikleştirir:
1. Commit Analizi: main (veya belirlenen) branch'indeki commit mesajları analiz edilir.
2. Sürüm Belirleme: Yeni MAJOR, MINOR veya PATCH sürümü belirlenir.
3. Değişiklik Günlüğü Oluşturma: Yeni sürüme ait değişiklikler için CHANGELOG.md güncellenir.
4. Sürüm Dosyalarını Güncelleme: package.json gibi sürüm içeren dosyalar güncellenir.
5. Git İşlemleri: Güncellenmiş dosyalar yeni bir commit ile depoya geri yazılır ve yeni sürüm numarasıyla bir Git etiketi oluşturulur.
6. Release Oluşturma: İsteğe bağlı olarak, Azure DevOps veya GitHub üzerinde bir release oluşturulur.
Örnek YAML Pipeline Yapılandırması
Aşağıda, manuel tetiklemeli ve Semantic Release kullanan basit bir Azure DevOps YAML pipeline örneği bulunmaktadır:
# azure-pipelines.yml
trigger: none # Bu pipeline sadece manuel olarak çalıştırılacak
pool:
vmImage: 'ubuntu-latest' # Veya Windows agent
variables:
# Semantic Release'in Git işlemlerini yapabilmesi için PAT
# Bu değişkeni Azure DevOps'ta gizli (secret) olarak tanımlayın
PAT_FOR_SEMANTIC_RELEASE: $(System.AccessToken) # Eğer Build Service hesabına yeterli yetki verildi ise
# Veya kendi oluşturduğunuz PAT için:
# PAT_FOR_SEMANTIC_RELEASE: $(MySemanticReleasePAT)
stages:
- stage: Release
displayName: 'Create Release'
jobs:
- job: SemanticReleaseJob
displayName: 'Run Semantic Release'
steps:
- checkout: self
persistCredentials: true # Bu, Git push/tag işlemlerinin çalışması için önemli
- task: NodeTool@0
inputs:
versionSpec: '16.x'
displayName: 'Install Node.js'
- script: |
npm install
displayName: 'Install Project Dependencies'
- script: |
npm install -g semantic-release @semantic-release/git @semantic-release/changelog @semantic-release/npm
displayName: 'Install Semantic Release CLI and Plugins'
- script: |
git config user.name "$(GIT_AUTHOR_NAME)"
git config user.email "$(GIT_AUTHOR_EMAIL)"
npx semantic-release
displayName: 'Execute Semantic Release'
env:
# Semantic Release'in Git işlemlerini yapabilmesi için token
# Gerekirse, Git URL'ini de token ile birlikte yapılandırabilirsiniz
# GITHUB_TOKEN: $(PAT_FOR_SEMANTIC_RELEASE) # Eğer GitHub içinse
# AZURE_DEVOPS_TOKEN: $(PAT_FOR_SEMANTIC_RELEASE) # Azure DevOps için
# Npm paketini yayınlamak için Npm token
# NPM_TOKEN: $(NPM_AUTH_TOKEN)
# Diğer ortam değişkenleri...
Not: checkout: self adımında persistCredentials: true kullanmak, semantic-release'in Git işlemlerini yapabilmesi için önemlidir. PAT_FOR_SEMANTIC_RELEASE değişkeninin System.AccessToken olarak ayarlanması, eğer Build Service hesabına "Contribute" ve "Create tag" izinleri verilmişse çalışabilir. Aksi takdirde, özel bir PAT kullanmak daha güvenli ve yaygın bir yaklaşımdır.
Sürüm Etiketlerinin Oluşturulması
Semantic Release, başarılı bir sürüm yükseltme sonrasında otomatik olarak Git deposuna yeni bir sürüm etiketi (örn. v1.2.3) ekler. Bu etiketler, belirli bir sürümün kod tabanını kolayca bulmayı ve referans vermeyi sağlar.
En İyi Uygulamalar ve Dikkat Edilmesi Gerekenler
Manuel tetiklemeli Semantic Release kullanımı, esneklik sağlarken, bazı en iyi uygulamaların takip edilmesini gerektirir.
Commit Mesajı Standartları
Semantic Release'in doğru çalışması için commit mesajlarının belirli bir standarda (örn. Conventional Commits) uyması zorunludur.
* feat: yeni özellikler için
* fix: hata düzeltmeleri için
* chore: yapılandırma veya bakım görevleri için
* BREAKING CHANGE: geriye dönük uyumsuz değişiklikler için mesaj gövdesinde belirtilmelidir.
Güvenlik ve İzinler
Semantic Release'in Git deposuna yazma yetkisi olduğu için, kullanılan PAT'in izinlerini dikkatlice yönetmek önemlidir. Sadece gerekli minimum izinleri (Code: Read & Write) verin ve PAT'i gizli tutun.
Geri Alma Stratejileri
Otomatik sürümlemede bir hata olması durumunda (nadiren de olsa), geri alma stratejileri önemlidir. Yanlış bir sürüm yayınlandığında, Git etiketini silip önceki bir commite geri dönmek ve ardından düzeltilmiş bir commit ile yeni bir sürüm tetiklemek gerekebilir.
Test ve Doğrulama
Semantic Release pipeline'ını ilk kez kurarken veya önemli değişiklikler yaparken, bir test projesi üzerinde veya bir dry-run modu ile dikkatlice test etmek önemlidir. semantic-release --dry-run komutu, gerçek bir yayın yapmadan ne olacağını görmenizi sağlar.
Sonuç
Azure DevOps ve Semantic Release'in birleşimi, yazılım geliştirme süreçlerinde sürüm yönetimini devrim niteliğinde basitleştirir ve güçlendirir. Manuel tetiklemeli bir yaklaşımla bile, Semantic Release'in sunduğu otomasyon, insan hatasını en aza indirir, tutarlılığı artırır ve geliştiricilerin daha verimli çalışmasını sağlar. Doğru yapılandırma ve en iyi uygulamaların takibiyle, projelerinizde hem esnek hem de güvenilir bir sürümleme süreci inşa edebilirsiniz. Bu entegrasyon, modern CI/CD pratiklerinin vazgeçilmez bir parçası olarak, yazılım kalitesini ve yayın süreçlerinin öngörülebilirliğini önemli ölçüde artırır.
SSS (Sık Sorulan Sorular)
S1: Semantic Release neden manuel sürümlemeyi tamamen ortadan kaldırmıyor?
C1: Semantic Release, commit geçmişine dayalı otomatik sürümleme için tasarlanmıştır. Ancak bazı özel durumlarda (acil yamalar, belirli bir tarihte yayınlama vb.) manuel kontrol ihtiyacı doğabilir. Bu makale, bu manuel tetikleme ihtiyacını Semantic Release'in otomasyonuyla birleştirmeyi amaçlamaktadır.
S2: System.AccessToken yerine neden özel bir PAT kullanmalıyım?
C2: System.AccessToken genellikle Azure DevOps Build Service hesabına atanan varsayılan izinlere sahiptir ve çoğu zaman Git deposuna yazma (commit, tag oluşturma) yetkisi içermez. Semantic Release'in Git işlemlerini yapabilmesi için "Code (Read & write)" izinlerine sahip bir PAT gereklidir. Bu PAT'i bir gizli değişken olarak tanımlamak daha güvenlidir.
S3: Semantic Release'i Azure DevOps'ta her branch için çalıştırabilir miyim?
C3: Semantic Release genellikle ana branch'ler (örn. main veya master) için yapılandırılır. Ancak, yapılandırmasını özelleştirerek belirli release branch'leri gibi diğer branch'lerde de çalıştırabilirsiniz. branches yapılandırması ile hangi branch'lerin sürüm yayınlayabileceğini belirleyebilirsiniz.
S4: semantic-release komutunu çalıştırmadan önce npm install yapmam gerekiyor mu?
C4: Evet, semantic-release ve onun eklentileri projenizin devDependencies kısmında tanımlıysa, pipeline'da bu bağımlılıkları yüklemek için npm install (veya npm ci) komutunu çalıştırmanız gerekir. Alternatif olarak, npx semantic-release komutu, yerel olarak kurulu olmayan paketleri geçici olarak indirip çalıştırabilir, ancak bağımlılıkları önceden yüklemek genellikle daha sağlam bir yaklaşımdır.