GitHub Spec Kit'i CI/CD ve DevOps uygulamalarıyla tümleştirme
Belirtim temelli geliştirme (SDD), ilk özellik uygulamasının ötesine uzanır. SDD uygulamalarının sürekli tümleştirme ve dağıtım işlem hatlarıyla tümleştirilmesi, belirtimlerin yazılım yaşam döngüsü boyunca üretim koduyla eşitlenmiş kalmasını sağlar.
CI/CD'de belirtim doğrulamayı otomatikleştirme
Sürekli tümleştirme işlem hatları genellikle lint, test ve güvenlik taraması aracılığıyla kod kalitesini doğrular ve belirtim-kod hizalamasını doğrulamak için bu işlem hatlarını genişletebilirsiniz.
Belirtim eksiksizlik denetimlerini uygulama
Tüm belirtim gereksinimlerinin ilgili testlere sahip olduğunu doğrulayan otomatik denetimler oluşturun. Kabul kriterlerini ayıklamak için spec.md dosyasını ayrıştırmak, ardından her kriterin test paketinizde ilişkili bir teste sahip olduğunu doğrulamak.
Örneğin, spec.md "Kabul Ölçütleri: 50 MB'tan büyük dosyalar bir hata iletisi görüntüler" ifadesini içeriyorsa CI işlem hattınız gibi test_upload_oversized_file_shows_error bir adla test arar veya bu senaryonun bir test alıştırması olduğunu doğrular.
Bu otomasyon, üretime ulaşmadan önce eksik uygulamaları yakalar. Birisi bir özellik uygular ancak belirtimde belgelenen bir köşe durumunu işlemeyi unutursa, Sürekli Entegrasyon (CI) derleme süreci, eksik testi tanımlayan net bir mesajla başarısız olur.
Belirtim söz dizimini ve eksiksizliğini doğrulama
Kuruluşunuzun belirtim şablonuna uygun olduğundan emin olmak için belirtim markdown dosyalarında otomatik denetimler çalıştırın. Gerekli bölümlerin (Özet, Kabul Ölçütleri, İşlevsel Gereksinimler, Uç Durumlar) mevcut ve boş olmadığını doğrulayın.
Örnek Azure DevOps İşlem Hattı görevi:
- task: PowerShell@2
displayName: 'Validate Specification Structure'
inputs:
targetType: 'inline'
script: |
$specFile = Get-Content "spec.md" -Raw
$requiredSections = @("Summary", "Acceptance Criteria", "Functional Requirements", "Edge Cases")
$missing = @()
foreach ($section in $requiredSections) {
if ($specFile -notmatch "## $section") {
$missing += $section
}
}
if ($missing.Count -gt 0) {
Write-Error "Specification missing required sections: $($missing -join ', ')"
exit 1
}
Bu doğrulama, özelliklerin kuruluşunuz genelinde tutarlı bir yapıya sahip olmasını sağlayarak daha kolay okunmasını ve otomatikleştirilmiş araçların daha güvenilir olmasını sağlar.
Anayasa uyumluluğunu zorunlu kılma
Kod değişikliklerinin anayasa ilkelerini ihlal etmediğini doğrulayan denetimleri otomatikleştirin. Kuralları ayıklamak için constitution.md ayrıştırarak kodu bu kurallara göre doğrulayın.
Anayasanızda "Tüm bulut kaynaklarının Azure hizmetlerini kullanması gerekiyor" ifadesi varsa, Amazon Web Services (AWS) veya Google Cloud Platform (GCP) kaynaklarının tanımlanmadığını doğrulamak için Kod olarak Altyapı dosyalarını (ARM şablonları, Bicep dosyaları, Terraform yapılandırmaları) tarayın.
Anayasada "Tüm API'lerin Microsoft Entra Kimliği aracılığıyla kimlik doğrulaması yapması gerekir" gerekiyorsa, tüm uç noktalarda kimlik doğrulama özniteliklerinin mevcut olduğundan emin olmak için API denetleyicisi kodunu analiz edin.
Bu otomatik denetimler, yanlışlıkla yapılan anayasa ihlallerinin üretime ulaşmasını engeller.
Azure DevOps ile tümleştirme
Azure DevOps, SDD yapıtlarını kurumsal iş akışlarına eklemeye yönelik zengin tümleştirme noktaları sağlar.
İş öğelerini belirtimlere bağlama
Özellikler için Azure Boards iş öğeleri oluştururken, deponuzda ilgili spec.md dosyasının bağlantılarını ekleyin. İş öğelerine bağlantı eklemek, proje yönetiminden gereksinimlerden uygulamaya kadar izlenebilirlik oluşturur.
Örnek iş öğesi açıklama şablonu:
## Specification
See [spec.md](https://dev.azure.com/yourorg/yourproject/_git/yourrepo?path=/features/document-upload/spec.md)
## Plan
See [plan.md](https://dev.azure.com/yourorg/yourproject/_git/yourrepo?path=/features/document-upload/plan.md)
## Tasks
See [tasks.md](https://dev.azure.com/yourorg/yourproject/_git/yourrepo?path=/features/document-upload/tasks.md)
Proje katılımcıları veya geliştiriciler iş öğesini görüntülediğinde, depolar arasında arama yapmadan belirtim ayrıntılarını tamamlamak için anında erişime sahip olurlar.
Görevlerden iş öğeleri oluşturma
tasks.md'den Azure Boards iş öğelerinin oluşturulmasını otomatikleştirin. Görev listesini ayrıştırın ve ilgili iş öğelerini oluşturun; başlık, açıklama, yineleme ve alan yolu gibi uygun alanları ayarlayın.
Bu otomasyon, el ile veri girişini kaydeder ve proje izleme sisteminizin SDD görev listelerinizle eşitlenmiş kalmasını sağlar. Geliştirme sırasında tasks.md dosyasını düzenlerken, iş öğelerini güncel uygulama planını yansıtacak şekilde yeniden oluşturun.
Belirtim tabanlı çekme isteği şablonları
Geliştiricilerin değişikliklerinin hangi belirtim gereksinimlerini uyguladığını belirtmesini gerektiren çekme isteği şablonlarını yapılandırın.
Aşağıdaki çekme isteği şablonunu göz önünde bulundurun:
## Changes Description
<!-- Describe what this PR changes -->
## Specification Reference
<!-- Link to the spec.md file and list which acceptance criteria this PR satisfies -->
- Spec file:
- Acceptance criteria addressed:
## Testing
<!-- Describe how you verified these changes work correctly -->
## Checklist
- [ ] Code implements all acceptance criteria listed above
- [ ] Tests added for all acceptance criteria
- [ ] Plan.md updated if architectural approach changed
- [ ] Tasks.md updated to mark completed tasks
Bu şablon, çekme isteği değerlendirenlerin uygulamaları, spesifikasyonlara göre verimli bir şekilde doğrulayabilmesini sağlar.
GitHub ile tümleştirme
GitHub, GitHub Enterprise kullanan kuruluşlar için benzer tümleştirme özellikleri sağlar.
Spesifikasyon doğrulaması için GitHub Actions
Çekme isteklerindeki belirtimleri otomatik olarak doğrulayan GitHub Actions iş akışları oluşturun:
name: Validate Specifications
on:
pull_request:
paths:
- '**/spec.md'
- '**/plan.md'
- '**/tasks.md'
jobs:
validate:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Validate Specification Structure
run: |
python scripts/validate_spec.py
- name: Check constitution compliance
run: |
python scripts/check_constitution.py
- name: Verify Acceptance Criteria Coverage
run: |
python scripts/verify_test_coverage.py
Bu iş akışları, belirtimler değiştiğinde otomatik olarak çalıştırılır ve doğrulama hataları hakkında anında geri bildirim sağlar.
GitHub Issues entegrasyonu
"Program aracılığıyla görevleri tasks.md dosyasından GitHub Problemlerine dönüştürün." Uygun etiketler, kilometre taşları ve atamalarla ilgili sorunlar oluşturmak için GitHub API'sini veya CLI'sini kullanın.
GitHub CLI'sı kullanma örneği:
gh issue create \
--title "Implement upload endpoint validation" \
--body "Task from Phase 2: Add file validation logic (size, type) to DocumentService" \
--label "feature/document-upload" \
--label "back-end" \
--assignee developer-username
Tüm görevler için sorun oluşturmak için bu işlemi otomatikleştirin ve ilgili kod birleştirildiğinde bunları otomatik olarak kapatın.
Belirtim değişikliği bildirimleri
Özellikler değiştiğinde ilgili ekip üyelerini bilgilendirmek için GitHub Actions'ı yapılandırın:
name: Notify Spec Changes
on:
pull_request:
paths:
- '**/spec.md'
jobs:
notify:
runs-on: ubuntu-latest
steps:
- name: Notify stakeholders
uses: actions/github-script@v6
with:
script: |
github.rest.issues.createComment({
issue_number: context.issue.number,
owner: context.repo.owner,
repo: context.repo.name,
body: '📋 Specification changed. @product-team @qa-team please review.'
})
Bu otomasyon, proje katılımcılarının gereksinim değişikliklerini görüntüleyebilir ve uygulama devam etmeden önce bunları gözden geçirebilir.
Belirtim-kod kayma durumunu izleme
Zaman içinde, hata düzeltmeleri ve küçük değişiklikler biriktikçe kod belirtimlerden kayabilir ve otomatik izleme sorunlu hale gelmeden önce bu kaymayı algılar.
Düzenli spesifikasyon denetimleri
Uygulanan işlevleri belirtimlerle karşılaştıran düzenli otomatik denetimler zamanlayın. Şu bilgileri tanımlayan raporlar oluşturun:
- spec.md dosyasındaki kabul ölçütleri, karşılık gelen testler olmadan.
- Koddaki herhangi bir belirtim içinde belgelenmemiş özellikler.
- Kod tabanında uygulanan "Gelecekteki Geliştirme" olarak işaretlenen belirtim bölümleri.
- Üretim kodunda anayasa ihlalleri.
Bu denetimleri haftalık veya aylık olarak çalıştırarak sonuçları ekip panolarına yayımlayın. Yaklaşan sprint'lerde tanımlanan sapmaları ele alın.
Belirtim kapsamı ölçümleri
Belirtim kalitesi ve kapsamı hakkındaki ölçümleri izleyin:
- İlişkili testlerle kabul ölçütlerinin yüzdesi
- Belirtimleri olmayan özellik sayısı
- Belirtim oluşturma ve uygulama arasındaki ortalama süre
- Belirtimleri uygun şekilde güncelleştiren çekme isteklerinin yüzdesi
Ekibinizin SDD benimsemesini anlamak ve geliştirme fırsatlarını belirlemek için bu ölçümleri panolarda görselleştirin.
Spesifikasyon sürüm yönetimini ele alma
Özellikler birden çok sürümde geliştikçe, belirtim sürümlerinin yönetilmesi geçmiş bağlamı korumak için önemli hale gelir.
Sürümlerle etiket spesifikasyonları
Git'te bir yayın etiketi oluşturulduğunda, etiketli komit, tüm belirtimlerin o andaki geçerli durumunu içermelidir. Bu gereksinim, her yayının belirtimine göre ne yapması gerektiğinin geçmiş kaydını oluşturur.
Geçmiş bir sürümün ne uyguladığını anlamak için yayın etiketini gözden geçirin ve spec.md dosyalarını okuyun. Bu geçmiş bağlam, hataları araştırırken veya özellik gelişimini anlarken yardımcı olur.
Özellik değişiklik günlüğünü koru
Uzun ömürlü özellikler için, gereksinimlerin ne zaman ve neden değiştirildiğini belgeleyen spec.md bir değişiklik günlüğü bölümü bulundurmayı göz önünde bulundurun:
## Specification Changelog
### 2025-01-15
- Increased max file size from 50MB to 100MB per customer request
- Added support for .xlsx file type
- Removed virus scanning requirement (handled by network security)
### 2024-12-01
- Initial specification created
Bu değişiklik günlüğü, gelecekteki geliştiricilere gereksinimlerin nasıl geliştiği hakkında bağlam sağlar.
Dağıtım geçitlerini uygulama
Derlemeleri üretime almadan önce kaliteyi sağlamak için spesifikasyonları dağıtım aşaması ölçütleri olarak kullanın.
Tüm kabul ölçütleri test edildi
Tüm kabul ölçütlerinin başarılı testlere sahip olup olmadığını denetleyin. Bu doğrulama, spec.md ayrıştırılarak ve test sonuçlarıyla çapraz başvuruda bulunarak otomatikleştirilebilir.
Bilinen anayasa ihlalleri yok
Anayasa ilkelerinin bilinen ihlallerini tarayın. Eğer güvenlik ekibiniz geliştirme sırasında geçici bir istisna işaretlediyse, bu işaretin üretim dağıtımından önce çözülmesi gerekir.
Spesifikasyon-belge hizalama
Kullanıcıya yönelik belgeleri (kullanıcı kılavuzları, yardım makaleleri, API belgeleri) koruyorsanız, değişiklikleri dağıtmadan önce geçerli belirtimlerle uyumlu olduğunu doğrulayın. Güncel olmayan belgeler, kullanıcı karışıklığına ve destek biletlerine neden olur.
Gelişmiş yapay zeka destekli iş akışları
Geliştirme sürecinizi daha da kolaylaştırmak için belirtim ile ilgili gelişmiş otomasyon için yapay zeka yardımcılarını kullanın.
Kullanıcı hikayelerinden otomatik belirtim oluşturma
Ürün sahibi kullanıcı hikayelerinden ilk belirtim taslakları oluşturmak için yapay zeka modellerini eğitin. Bu işlem, tutarlı yapıyı korurken belirtim oluşturma sürecini hızlandırır.
Ürün sahipleri üst düzey kullanıcı hikayeleri sağlar. Yapay zeka, hikayelere göre doldurulmuş bölümler içeren yapılandırılmış spec.md taslaklar oluşturur. Geliştiriciler, yapay zeka tarafından oluşturulan özellikleri son haline getirmeden önce gözden geçirir ve iyileştirir.
Spesifikasyondan teste oluşturma
Doğrudan kabul ölçütlerinden türetilen yapay zeka tarafından oluşturulan testlerle denemeler yapın. İnsan incelemesi hala gerekli olsa da yapay zeka, geliştiricilerin ete kemiğe bürünebileceği bir test iskelesi oluşturabilir.
Örneğin, "50 MB'tan büyük dosyalar hata iletisi görüntüler" kabul ölçütüne göre yapay zeka bir test şablonu oluşturur:
[Test]
public void UploadFile_ExceedsMaxSize_ReturnsError()
{
// Arrange
var file = CreateMockFile(sizeInMB: 51);
// Act
var result = await _uploadService.UploadFileAsync(file);
// Assert
Assert.That(result.IsError, Is.True);
Assert.That(result.ErrorMessage, Contains.Substring("too large"));
}
Geliştiriciler oluşturulan test mantığını doğrular ve eksik onayları ekler.
Anayasa uyumluluğu önerileri
Yapay zeka yardımcılarını, kodun anayasa ilkelerini ne zaman ihlal edebileceğinizi proaktif olarak önerecek şekilde yapılandırın. Kod oluşturma sırasında yapay zeka constitution.md başvurabilir ve kod yazilmeden önce olası ihlaller hakkında uyarı verebilir.
İdare ve en iyi yöntemleri oluşturma
Başarılı SDD benimseme, idare yapılarını ve sürekli en iyi yöntemleri geliştirmeyi gerektirir.
Belirtim sahiplerini belirleme
Belirtimlerin sahipliğini belirli ekip üyelerine veya rollere atayın. Belirtim sahipleri özellikleri güncel tutmak, belirtim incelemelerini kolaylaştırmak ve özellikler arasında tutarlılık sağlamakla sorumludur.
Bu sorumluluk, belgelerin sahipsiz kalıp bakım yapılmayan belgeler haline gelmesini engeller.
Spesifikasyon değerlendirmelerini geçmişe dönük yapma
Sprint değerlendirmelerine spesifikasyon kalitesini dahil edin. Şu soruları tartışın:
- Belirtimlerimiz uygulama zorluklarını doğru bir şekilde tahmin etti mi?
- Geliştirme sırasında en çok hangi belirtim bölümleri değerliydi?
- Şartnameler gerekli ayrıntıları nerede eksikti?
- Belirtim yazımızı nasıl geliştirebiliriz?
Belirtim şablonlarını ve yazma yönergelerini iyileştirmek için geçmişe dönük içgörüler kullanın.
Kurumsal bilgi oluşturma
Kuruluşunuz SDD deneyimi kazandıkça, desenleri ve anti-desenleri belgeleyin. Ekip içi iyi ve kötü spesifikasyon örneklerini gösteren kılavuzlar oluşturun. Başarılı belirtim temelli projeleri SDD değerini gösteren örnek olay incelemeleri olarak paylaşın.
Bu bilgi paylaşımı, kuruluşunuz genelinde SDD benimsemeyi hızlandırır ve yeni ekiplerin yaygın tuzaklardan kaçınmalarına yardımcı olur.
Özet
Belirtim temelli geliştirmeyi CI/CD işlem hatlarıyla tümleştirmek, belirtimlerin yazılım yaşam döngüsü boyunca kodla eşitlenmiş kalmasını sağlar. Belirtim doğrulama, anayasa uyumluluğu denetimi ve test kapsamı doğrulamayı otomatikleştirin. Tam izlenebilirlik için SDD yapıtlarını Azure Boards veya GitHub Sorunları gibi proje yönetimi araçlarına bağlayın. Düzenli denetimler ve ölçümler aracılığıyla belirtim kodu kayma durumunu izleyin. Üretim sürümlerinin belgelenmiş gereksinimleri karşıladığından emin olmak için belirtimleri dağıtım kapısı ölçütleri olarak kullanın. SDD benimsenmesini sürekli geliştirmek için spesifikasyon sahipleri ve düzenli retrospektifler de dahil olmak üzere yönetim uygulamaları oluşturun. Bu gelişmiş tümleştirme desenleri, SDD'yi bir geliştirme tekniğinden, dağıtım aracılığıyla gereksinimlerden hizalamayı koruyan kapsamlı bir yazılım teslim metodolojisine dönüştürür.