AI Destekli Yazılım Geliştirmede Değişiklik Bütçesi ve Canary

AI destekli yazılım geliştirmede değişiklik bütçesi çıkarma

Kod ajanı tarafından üretilen bir PR için satır sayısı tek başına risk sinyali değildir. 12 satırlık bir değişiklik, ödeme yetkilendirme yolunda veya mesaj tekrar işleme mantığında binlerce isteği etkileyebilir. Değişiklik bütçesini, Git diff içindeki dosya sınıfı, değişen public API yüzeyi, çağrıldığı servis sayısı ve geri alma kolaylığıyla sayısallaştırın. Bu yaklaşım, generative ai aracının ürettiği büyük fakat izole bir test değişikliği ile küçük ama kritik bir davranış değişikliğini ayırır.

#!/usr/bin/env python3
import subprocess

critical = ('payments/', 'auth/', 'migrations/', 'infra/')
changed = subprocess.check_output(
    ['git', 'diff', '--name-only', 'origin/main...HEAD'], text=True
).splitlines()

score = 0
for path in changed:
    if path.startswith(critical):
        score += 35
    elif path.endswith(('.proto', '.sql', 'openapi.yaml')):
        score += 20
    else:
        score += 5

lines = int(subprocess.check_output(
    ['git', 'diff', '--numstat', 'origin/main...HEAD'], text=True
).decode().split()[0])
score += min(lines // 40, 20)

lane = 'direct' if score < 20 else 'canary' if score < 60 else 'manual-approval'
print(f'risk_score={score}')
print(f'deployment_lane={lane}')

Bu betiği CI işinin ilk adımında çalıştırıp sonucu build artifact metadata'sına yazın. Eşikler tahmini kalmamalı: son 90 gündeki incident kayıtlarında geri alınan dağıtımları sorgulayın, her PR'ın skorunu ve sonucunu kaydedin, sonra false-negative oranını hesaplayın. Özellikle yeniden adlandırma işlemleri edge case'tir: Git rename algılarsa gerçek davranış değişikliği olmadan onlarca dosya görünür. `git diff --find-renames=80%` kullanmak, yalnızca taşınan dosyaların bütçeyi gereksiz yükseltmesini engeller.

CI CD pipeline içinde risk skorundan dağıtım hattına geçmek

Bir ci cd pipeline, kod ajanının PR açıklamasındaki 'test edildi' ifadesine güvenmemelidir. Önce risk betiğinin ürettiği lane değerini job output olarak yayınlayın; sonra yalnızca canary lane için imzalı container image üretin ve dağıtım işini çağırın. Image etiketi olarak branch adı kullanmak yerine değişmez Git SHA kullanın; branch tekrar push edildiğinde aynı etiketin farklı manifest'e işaret etmesi rollback incelemesini bozar.

name: delivery
on: [push]
jobs:
  classify:
    runs-on: ubuntu-latest
    outputs:
      lane: ${{ steps.risk.outputs.lane }}
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - id: risk
        run: |
          python3 ci/risk_budget.py | tee result.txt
          echo "lane=$(awk -F= '/deployment_lane/ {print $2}' result.txt)" >> $GITHUB_OUTPUT
  canary:
    needs: classify
    if: needs.classify.outputs.lane == 'canary'
    runs-on: ubuntu-latest
    steps:
      - run: ./ci/build-and-sign.sh $GITHUB_SHA
      - run: kubectl argo rollouts set image checkout checkout=registry.example/checkout:$GITHUB_SHA

Buradaki kritik ayrıntı, sınıflandırma ile build arasındaki kaynak ağacının aynı commit olmasıdır. Ayrı workflow'larda `main` dalını tekrar checkout etmek TOCTOU hatası üretir: skor commit A için hesaplanır, image commit B'den oluşturulur. Bu yüzden risk çıktısı, commit SHA ve image digest'i bir release manifest içinde birlikte saklayın. Bu pratik, yapay zeka eğitimi veya llm eğitimi alan ekiplerin ajan çıktısını insan denetimine bağlamasında da somut bir örnektir; amaç modeli güvenilir ilan etmek değil, modelin ürettiği değişikliği deterministik bir hatta sınırlamaktır.

Canary metrik kapısı: Prometheus ve sürekli profiling ile önce-sonra karşılaştırması

Canary değerlendirmesinde sadece HTTP 5xx oranı yetersizdir. Yeni sürüm CPU tüketimini artırıp autoscaler'ın daha çok pod açmasına, ardından kuyruk gecikmesinin büyümesine yol açabilir. Argo Rollouts AnalysisTemplate içinde hata oranı ve p95 gecikmeyi ölçün; karşılaştırma paydasını canary ile stable sürümünün aynı zaman penceresindeki trafiğinden alın. Sabit bir 200 ms eşik, gün içi trafik deseni değiştiğinde yanlış pozitif üretir.

apiVersion: argoproj.io/v1alpha1
kind: AnalysisTemplate
metadata:
  name: checkout-canary
spec:
  metrics:
  - name: error-rate
    interval: 1m
    count: 5
    successCondition: result[0] < 0.005
    provider:
      prometheus:
        address: http://prometheus.monitoring.svc:9090
        query: |
          sum(rate(http_server_requests_total{app='checkout',version='canary',code=~'5..'}[2m])) /
          sum(rate(http_server_requests_total{app='checkout',version='canary'}[2m]))
  - name: p95-regression
    interval: 1m
    count: 5
    successCondition: result[0] < 1.10
    provider:
      prometheus:
        address: http://prometheus.monitoring.svc:9090
        query: |
          histogram_quantile(0.95, sum(rate(http_server_request_duration_seconds_bucket{app='checkout',version='canary'}[2m])) by (le)) /
          histogram_quantile(0.95, sum(rate(http_server_request_duration_seconds_bucket{app='checkout',version='stable'}[2m])) by (le))

Gecikme regresyonu görülürse nedenini sadece metrikten çıkaramazsınız. Pyroscope veya Parca ile stable ve canary pod'larının aynı 5 dakikalık penceredeki CPU flamegraph'larını karşılaştırın. Örneğin JSON serileştirme fonksiyonu canary'de CPU sample'larının yüzde 18'ini, stable'da yüzde 3'ünü alıyorsa, rollback gerekçesi ölçülebilir hale gelir. Profiling agent'ını örnekleme oranı yüksekken tüm pod'larda açmak da üretim maliyetini çarpıtabilir; önce canary replica'larına `PYROSCOPE_APPLICATION_NAME=checkout-canary` etiketiyle sınırlı agent enjekte edin. Bu, performans kararında gerçek önce-sonra karşılaştırması sağlar.

Kubernetes, minikube ve Docker ile yerel canary provası

Üretimde container orchestration davranışını ilk kez görmek yerine, PR'da kısa ömürlü bir kümede dağıtım stratejisini prova edin. docker eğitimi kapsamında yalnızca image build etmek yeterli değildir; image'ın non-root kullanıcıyla çalışması, readiness probe başarısız olduğunda trafikten çıkması ve image pull politikası da test edilmelidir. Aşağıdaki komutlar, minikube üzerinde ingress, Prometheus ve Argo Rollouts kurulumunun ardından k6 ile sabit yük üretir.

minikube start --cpus=4 --memory=8192
minikube addons enable ingress
helm repo add argo https://argoproj.github.io/argo-helm
helm upgrade --install argo-rollouts argo/argo-rollouts -n argo-rollouts --create-namespace
kubectl apply -f deploy/rollout.yaml
k6 run --vus 50 --duration 6m tests/checkout-load.js
kubectl argo rollouts get rollout checkout --watch

Yük testinde canary pod'una trafik gerçekten gidiyor mu, bunu yalnızca k6 toplam sonucu ile doğrulamayın. Uygulamanın response header'ına build SHA ekleyin ve k6 custom metric ile `version=canary` oranını sayın. Service mesh olmadan Argo Rollouts ağırlıklı yönlendirmeyi ancak ingress controller veya uygun traffic routing provider destekliyorsa yapabilir. Bu destek yokken replica sayısını yüzde 10'a çekmek trafik payını yüzde 10 yapmaz; uzun yaşayan bağlantılar ve pod kapasitesi nedeniyle sonuç yanıltıcı olur. kubernetes eğitimi ve devops eğitimi laboratuvarlarında bu farkı görünür kılmak için HTTP keep-alive açık ve kapalı iki ayrı k6 koşusu çalıştırın.

Cloud native mimari için Terraform tabanlı geri alma altyapısı

Canary mekanizmasının bağımlılıkları - metrik kaynağı, IAM yetkisi, kayıt defteri ve rollout controller - elle kurulduğunda ortamlar birbirinden ayrışır. Terraform ile infrastructure as code yaklaşımında, dağıtım rolüne yalnızca hedef namespace ve image registry için gereken izinleri verin. `cluster-admin` yetkili CI kimliği, hatalı bir ajan komutunun tüm cluster kaynaklarını silmesine izin verir.

resource "aws_iam_role_policy" "deploy_checkout" {
  role = aws_iam_role.ci_deployer.id
  policy = jsonencode({
    Version = "2012-10-17"
    Statement = [{
      Effect = "Allow"
      Action = ["ecr:BatchGetImage", "ecr:GetDownloadUrlForLayer"]
      Resource = aws_ecr_repository.checkout.arn
    }]
  })
}

resource "kubernetes_namespace" "checkout" {
  metadata { name = "checkout" }
}

aws eğitimi alan bir ekip bu modülü ECR ve IAM ile, google cloud eğitimi alan ekip ise aynı sınırı Artifact Registry ve Workload Identity ile uygular. Sağlayıcı değişse bile ilke aynıdır: CI'ya uzun ömürlü erişim anahtarı vermek yerine OIDC ile kısa ömürlü kimlik alın, `terraform plan -out=tfplan` çıktısını PR artifact'i olarak saklayın ve apply aşamasında aynı plan dosyasını kullanın. Aksi halde plan incelemesinden sonra sağlayıcıdaki dış değişiklikler farklı bir kaynak setinin uygulanmasına neden olabilir.

Yazılım eğitimi programlarında değişiklik bütçesi laboratuvarı

Bu konu, yazılım eğitimi ve teknoloji eğitimi içeriklerinde ayrı bir release engineering laboratuvarı olarak işlenebilir. yapay zeka kursu veya vibe coding kursu katılımcısına yalnızca prompt ile endpoint yazdırmak yerine, endpoint PR'ını düşük, orta ve yüksek risk olarak sınıflandıran üç senaryo verin. vibe coding eğitimi için ölçülebilir teslim kriteri şudur: katılımcı, risk skoru 60 üzerindeki PR'ın doğrudan prod dağıtımını engelleyen CI testini ve başarısız Prometheus analizi sonrası otomatik abort kaydını gösterebilmelidir.

• Bir generative ai ajanına yalnızca test dosyasını değiştiren PR ürettirin ve `direct` lane sonucunu doğrulayın.
• Aynı ajana `migrations/` altında indeks silen bir SQL değişikliği ürettirin; `manual-approval` sonucu bekleyin.
• cloud native mimari laboratuvarında canary p95 oranını 1.10 üzerine çıkaracak yapay gecikme ekleyin ve Argo Rollouts abort olayını kaydedin.

Bu laboratuvar, ai destekli yazılım geliştirme pratiğini insan onayı, ölçüm ve geri alma ile birleştirir. Katılımcının değerlendirmesinde prompt kalitesinden çok, image digest ile commit SHA eşleşmesini, PromQL sorgusunun stable-canary karşılaştırmasını ve Terraform planının tekrar üretilebilirliğini denetleyin. Böylece llm eğitimi, devops eğitimi ve kubernetes eğitimi birbirinden kopuk araç listeleri yerine aynı dağıtım kararının denetlenebilir parçaları olur.

Sık Sorulan Sorular

AI destekli yazılım geliştirme için risk skoru nasıl kalibre edilir?

Her merge için risk skoru, seçilen deployment lane, incident sonucu ve rollback bilgisini bir tabloda tutun. En az bir release döngüsü sonunda rollback yaşanan PR'ların kaçının 20 altı skor aldığını hesaplayın. Bu false-negative oranı yüksekse kritik dizin ağırlığını veya API sözleşmesi değişikliği puanını artırın; eşikleri sezgisel olarak değiştirmeyin.

Kubernetes eğitiminde minikube canary testi üretimi ne kadar temsil eder?

minikube, manifest doğrulama, probe davranışı ve rollout abort akışı için yeterlidir; çok bölgeli ağ gecikmesi, gerçek cloud load balancer davranışı ve node autoscaling için temsil edici değildir. Yerelde k6 ile build SHA dağılımını doğrulayın, ardından aynı manifest'i staging cluster'da gerçek ingress ve Prometheus ile en az 10 dakikalık yük altında çalıştırın.

Docker eğitimi alan ekipler canary için hangi image hatasını sık yapar?

En yaygın hata `latest` etiketiyle dağıtımdır. Rollback komutu önceki manifest'i seçse bile registry'deki `latest` image'ı değiştiyse pod beklenmeyen binary ile açılabilir. CI, image'ı Git SHA ile etiketlemeli ve rollout manifest'ine mümkünse `image@sha256:...` digest'i yazmalıdır.

Terraform ve infrastructure as code canary altyapısında neden ayrı plan artifact'i ister?

`terraform plan` ile `terraform apply` arasında sağlayıcı kaynakları değişebilir. CI önce `terraform plan -out=tfplan` üretmeli, plan dosyasının SHA-256 özetini release kaydına eklemeli ve onay sonrası yalnızca `terraform apply tfplan` çalıştırmalıdır. Yeniden plan üretmek, incelenmemiş bir değişikliğin uygulanmasına yol açar.