AI Destekli Yazılım Geliştirmede Deterministik CI/CD Derlemeleri

AI destekli yazılım geliştirme için deterministik derleme sözleşmesi

Generative AI ile üretilen değişikliklerde asıl risk yalnızca hatalı kaynak kod değildir: aynı Git commitinin farklı zamanlarda farklı image üretmesi, rollback ve olay incelemesini belirsizleştirir. İlk kontrolü kaynak, lockfile, taban image digesti ve derleme ortamı için yapın. CI işinde aşağıdaki komut, committen üretilen OCI image digestini kayda geçirir. Digest sonraki aşamalarda tag yerine dağıtım kimliği olmalıdır.

docker buildx build   --platform linux/amd64   --provenance=false   --metadata-file build-metadata.json   --tag registry.example.com/payments-api:${GITHUB_SHA}   --push .

jq -r '."containerimage.digest"' build-metadata.json   | tee image-digest.txt

Dockerfile içinde yalnızca tag kullanmak deterministik değildir; `node:22-alpine` gibi bir tag registry tarafında farklı manifestlere işaret edebilir. Tabanı digest ile sabitleyin, bağımlılık çözümlemesini `pnpm install` yerine `pnpm install --frozen-lockfile` ile kapatın ve uygulamanın build adımına zaman bilgisi sızmasını engelleyin. `SOURCE_DATE_EPOCH`, Webpack veya Vite eklentilerinin dosya bannerına yerel saat basması gibi görünmesi zor farkları yakalamada özellikle etkilidir.

FROM node:22-alpine@sha256:REPLACE_WITH_VERIFIED_DIGEST AS build
WORKDIR /app
ENV SOURCE_DATE_EPOCH=1735689600
COPY package.json pnpm-lock.yaml ./
RUN corepack enable && pnpm install --frozen-lockfile
COPY . .
RUN pnpm run build

FROM nginx:alpine@sha256:REPLACE_WITH_VERIFIED_DIGEST
COPY --from=build /app/dist /usr/share/nginx/html

Bu yaklaşımı doğrulamak için iki temiz işçi üzerinde `docker buildx build --no-cache --output type=oci,dest=/tmp/app.oci .` komutunu çalıştırın ve `sha256sum /tmp/app.oci` çıktılarını karşılaştırın. OCI arşivi farklıysa önce `diffoscope` ile iki arşivi inceleyin; sık görülen nedenler dosya mtime değerleri, derleme çıktısındaki mutlak çalışma dizini ve dil araçlarının rastgele sıraladığı dosya listeleridir. Bu kontrol, bir yapay zeka eğitimi veya llm eğitimi laboratuvarında 'testler geçti' sinyalinden daha güçlü bir teslim kriteridir.

CI CD pipeline cache'ini bağımlılık çözümünden ayırma

Bir ci cd pipeline içinde cache anahtarını yalnızca branch adıyla kurmak, farklı lockfile kullanan işlerin eski `node_modules` katmanını tüketmesine yol açar. Cache, derleme çıktısı değil indirilen paket deposu için kullanılmalıdır. Aşağıdaki GitHub Actions örneğinde anahtar, runner mimarisi ve lockfile hashine bağlıdır; `restore-keys` bilinçli olarak yoktur. Böylece eski bir bağımlılık grafiğinin yeni committe 'yakın eşleşme' olarak kullanılmasını engellersiniz.

- name: Restore pnpm store
  uses: actions/cache@v4
  with:
    path: ~/.local/share/pnpm/store
    key: pnpm-${{ runner.os }}-${{ runner.arch }}-${{ hashFiles('pnpm-lock.yaml') }}

- name: Install exact dependency graph
  run: |
    corepack enable
    pnpm install --frozen-lockfile
    git diff --exit-code pnpm-lock.yaml

BuildKit cache mount kullanıyorsanız mount, son image katmanına yazılmaz ama aynı builder üzerinde kalır. Bu nedenle paket yöneticisinin doğrulama davranışı hâlâ zorunludur. Örneğin npm için `npm ci`, lockfile ile çelişen `package.json` durumunda başarısız olur; `npm install` ise lockfile'ı güncelleyerek sorunu gizleyebilir. Cache tüketimini görmek için `docker buildx du --verbose` çalıştırın ve cache exporter kullanıyorsanız registry referansını uygulama image'ından ayrı tutun: `--cache-to type=registry,ref=registry.example.com/cache/payments-api,mode=max`.

Vibe coding eğitimi ve vibe coding kursu içeriklerinde sık atlanan ayrıntı şudur: modelin eklediği yeni bir paket yalnızca kaynak diffi değildir, transitif bağımlılık grafiği değişikliğidir. Pull request kontrolünde `pnpm list --depth Infinity --json > dependency-tree.json` üretip önceki başarılı buildin ağacıyla karşılaştırın. Yeni native modül, farklı CPU mimarisinde derleme gerektirebilir; bu yüzden cache anahtarına `runner.arch` eklemek gereksiz bir ayrıntı değil, yanlış ikili dosya yeniden kullanımını önleyen sınırdır.

Docker eğitimi pratiğinde BuildKit darboğazını ölçmek

Derleme süresini azaltmadan önce darboğazı ölçün. `docker buildx build --progress=plain` çıktısındaki her `DONE` satırı katman süresini verir, ancak cache etkisini ayırmak için hem soğuk hem sıcak ölçüm alın. Her varyantı en az beş kez çalıştırın, medyanı raporlayın ve CPU frekans ölçekleme farkını azaltmak için aynı self-hosted runner imajını kullanın. Soğuk ölçümde `--no-cache`, sıcak ölçümde aynı builder kullanın.

for mode in cold warm; do
  for run in 1 2 3 4 5; do
    args=""
    [ "$mode" = "cold" ] && args="--no-cache"
    /usr/bin/time -f "$mode,$run,%e"       docker buildx build $args --progress=plain --load .       2>&1 | tee "build-$mode-$run.log"
  done
done

Örneğin bağımlılık manifestlerini kaynak koddan sonra kopyalayan Dockerfile'da, tek bir `.ts` değişikliği `pnpm install` katmanını da geçersiz kılar. Önceki düzen `COPY . .` ardından kurulum yapıyorsa, bunu manifestleri önce kopyalayan çok aşamalı düzene dönüştürün. Sonra `build-warm-*.log` dosyalarında `CACHED` oranını ve `/usr/bin/time` medyanını önce-sonra karşılaştırın. Kazancın mekanizması şudur: Docker katman anahtarı önceki katmanların filesystem snapshot'ına bağlıdır; kaynak dosyası değişince manifestten bağımsız indirme katmanının anahtarı da gereksiz yere değişir.

Bu ölçüm, docker eğitimi kapsamında 'cache kullanın' demekten daha değerlidir: cache hit oranını sayısallaştırır. `grep -c ' CACHED' build-warm-1.log` ile hit sayısını, `docker buildx du --verbose` ile cache boyutunu kaydedin. Sıcak build hızlanırken cache deposu sınırsız büyüyorsa, builder için `docker buildx prune --filter until=168h` gibi açık bir saklama politikası tanımlayın; aksi halde disk doluluğu yüzünden cache temizliği rastgele anlarda derlemeyi yavaşlatır.

Terraform ile image digestini infrastructure as code girdisine dönüştürme

Image tagini Terraform değişkeni olarak geçirmek, `latest` veya yeniden yazılmış release tagleri nedeniyle plan ile gerçek çalışma zamanı arasında fark yaratabilir. Bunun yerine CI'nin yazdığı `image-digest.txt` dosyasını `TF_VAR_image_digest` olarak iletin ve iş yükünde tam digest kullanın. Aşağıdaki örnek, Kubernetes provider kullanan bir cloud native mimari için image referansını registry ve digestten üretir.

variable "image_repository" { type = string }
variable "image_digest" {
  type = string
  validation {
    condition     = can(regex("^sha256:[0-9a-f]{64}$", var.image_digest))
    error_message = "image_digest must be a sha256 OCI digest."
  }
}

resource "kubernetes_deployment_v1" "api" {
  metadata { name = "payments-api" }
  spec {
    template {
      spec {
        container {
          name  = "api"
          image = "${var.image_repository}@${var.image_digest}"
        }
      }
    }
  }
}

Uygulamada CI sırası `build -> digest doğrulama -> terraform plan -> onay -> terraform apply` olmalıdır. `terraform plan -out=tfplan` ile kaydedilen planı, apply aşamasında yeniden plan üretmeden `terraform apply tfplan` ile uygulayın. Bu, deploy beklerken registry taginin değişmesi sorununu azaltır. AWS eğitimi bağlamında ECR, Google Cloud eğitimi bağlamında Artifact Registry kullanılsa da OCI digest semantiği aynıdır; provider değişse bile dağıtım sözleşmesi tag değil digest olmalıdır.

Terraform burada yalnızca kaynak yaratma aracı değildir; infrastructure as code içinde çalıştırılabilir bir sürüm sınırı tanımlar. `terraform show -json tfplan | jq -r '.. | .image? // empty'` ile planın beklenen digesti içerdiğini CI'da doğrulayın. Edge case: çok mimarili bir manifest listesi digesti ile platforma özel image digesti aynı değildir. `linux/amd64` ve `linux/arm64` worker'larınız varsa `docker buildx imagetools inspect` çıktısındaki manifest listesi digestini dağıtın; kubelet kendi mimarisi için doğru child manifest'i seçer.

Kubernetes eğitimi: minikube ile digest tabanlı runtime doğrulaması

Container orchestration katmanında doğrulama, yalnızca `kubectl rollout status` çağrısından ibaret olmamalıdır. Minikube üzerinde gerçek registry digestiyle test etmek için cluster'ın erişebildiği bir registry kullanın ve Pod'un çözdüğü image ID'yi kontrol edin. `image:` alanında digest olsa bile `kubectl get pod -o jsonpath` çıktısındaki `imageID`, container runtime'ın çektiği gerçek kimliği gösterir.

kubectl apply -f deployment.yaml
kubectl rollout status deployment/payments-api --timeout=120s
kubectl get pods -l app=payments-api   -o jsonpath='{range .items[*].status.containerStatuses[*]}{.image}{"\n"}{.imageID}{"\n"}{end}'

Yerel geliştirmede `minikube image load` ile tag yüklendikten sonra `imagePullPolicy: IfNotPresent` kullanmak, registrydeki artifact yerine node'daki eski tagi çalıştırabilir. Digest doğrulama testi için bu kısa yolu kullanmayın; mümkünse Minikube'un erişebildiği yerel registryye push edin ve manifestte `repo@sha256:...` referansı kullanın. Bu ayrım kubernetes eğitimi içerisinde önemlidir, çünkü yerel image cache'i üretim registry davranışını taklit etmez.

Bu konunun eğitim programlarına etkisi de pratiktir: yazılım eğitimi, teknoloji eğitimi, devops eğitimi ve yapay zeka kursu projelerinde teslim çıktısı olarak commit SHA, lockfile hash, OCI digest ve Terraform plan özeti istenebilir. Böyle bir kontrol listesi, ai destekli yazılım geliştirme sırasında üretilen kodun hangi artifacte dönüştüğünü izlenebilir yapar; kod önerisini kabul etmek ile çalıştırılacak imajı kanıtlamak arasındaki operasyonel farkı görünür kılar.

Sık Sorulan Sorular

AI destekli yazılım geliştirme için Docker image digesti neden tagden daha güvenilir?

Tag yeniden işaretlenebilir, digest ise OCI manifest içeriğinin SHA-256 kimliğidir. CI sonunda `docker buildx build --metadata-file build-metadata.json` ile digesti çıkarın, Terraform'a `repo@sha256:...` biçiminde aktarın ve Pod `imageID` değerini bu kimlikle doğrulayın.

Docker eğitimi sırasında BuildKit cache performansını nasıl ölçebilirim?

Aynı commit için beş soğuk `--no-cache` ve beş sıcak build çalıştırın. `/usr/bin/time` ile süreleri CSV olarak kaydedin, medyanları karşılaştırın, ardından `docker buildx du --verbose` ile cache boyutunu ve plain progress loglarındaki `CACHED` katman sayısını raporlayın.

Terraform ve infrastructure as code ile container image sürümü nasıl sabitlenir?

CI'nin ürettiği `sha256:<64-hex>` digestini `TF_VAR_image_digest` olarak verin. Terraform değişkeninde regex doğrulaması ekleyin, resource image alanını `${repository}@${digest}` olarak kurun ve `terraform plan -out=tfplan` sonrasında aynı plan dosyasını apply edin.

Kubernetes eğitimi ve minikube testinde imagePullPolicy hangi hataya yol açabilir?

Minikube node'unda daha önce yüklenmiş bir tag varsa `IfNotPresent`, registryde yeni artifact olsa bile yerel eski imajı başlatabilir. Digest referansı kullanın, `kubectl get pod -o jsonpath` ile `imageID` değerini alın ve tag tabanlı yerel image testini registry entegrasyon testinden ayrı tutun.