Docs
Menü

Dokümantasyon / Kurulum

Environment'lar

Deploy hedeflerinizi environment olarak tanımlayın; onay, freeze, supply chain policy ve diğer kuralları environment üzerinde yönetin.

Environment nedir?#

Environment, workload'larınızın çalıştığı deploy hedefidir: bir Kubernetes cluster'ı ya da bir Docker host'u. Agent'lar bir environment'a kaydolur ve o environment'a gelen işleri yürütür. Bir repo binding'i her zaman bir environment'a deploy eder.

Tipik bir kurulumda staging ve production gibi birden fazla environment olur. Başarılı bir run, Promote ile bir environment'tan diğerine taşınabilir.

Environment oluşturma#

  1. Altyapı > Environment'lar sayfasında Yeni environment'a basın.
  2. Ad alanına benzersiz bir ad girin, örneğin production. Ad : karakteri içeremez.
  3. Tip olarak Kubernetes (K8S) veya Docker'ı seçin.
  4. Environment oluştur'a basın.
  5. Environment sayfasında Agent kur ile bir agent ekleyin. Bkz. Agent kurulumu.

İpucu: Environment sayfasındaki Environment hazırlık durumu kartı; agent'ları, scanner'ları, supply chain ayarlarını ve preview ayarlarını kontrol eder ve eksikleri ok, warn veya fail olarak gösterir.

Ayarlar#

Environment sayfasında şu ayarları yönetebilirsiniz:

Ayar Ne işe yarar
Agent başına job Bu environment'taki bir agent'ın aynı anda kaç deployment çalıştırabileceği. Agent'ın kendi sınırı da vardır (varsayılan 4); düşük olan geçerlidir.
Cache maks. (GB) Agent'ların bu environment'ta kullanabileceği cache alanının üst sınırı. Sınır aşılınca en eski girdiler silinir.
Production (DORA'ya sayılır) Bu environment'ı DORA metriklerinde (deploy sıklığı, lead time, change fail, MTTR) production olarak sayar.
Deployment'lar için manuel onay iste Run'lar PENDING_APPROVAL durumunda onay bekler.
Onaylayanlar Virgülle ayrılmış kullanıcı adları. Boş bırakılırsa herhangi bir developer onaylayabilir; admin'ler her zaman onaylayabilir.
Freeze window'lar Belirli gün ve saatlerde yeni deploy'ları durdurur. Rollback ve preview kaldırma yine çalışır.
Supply-chain policy'si İmzalı image, SBOM ve critical vulnerability kuralları. Bkz. Supply chain güvenliği.
Step image policy'si Pack step'lerinin ve image ile çalışan SHELL step'lerinin image'larına imza ve tarama kurallarını uygular: Kapalı, Warn veya Enforce.
Host shell'e izin ver Image'ı olmayan SHELL step'lerinin doğrudan agent host'unda çalışmasına izin verir. Yeni environment'larda kapalıdır.
Otomatik SBOM ve vulnerability scan Organizasyon ayarını devralır ya da bu environment için açar veya kapatır.
Prod fail oranı yüksek olduğunda Production'da fail oranı yükseldiğinde ne yapılacağı: sadece bildir, freeze ya da rollback.
Deploy verification Deploy sonrası Prometheus ve HTTP check'leri. Bkz. Deploy verification ve rollback.
Review App'ler Kubernetes'te PR başına preview namespace'leri. Bkz. Preview'lar.

Onay#

Deployment'lar için manuel onay iste açıkken bu environment'a giden her run onaylanana kadar bekler. Onaylayan listesi boşsa developer rolündeki herkes onaylayabilir. Rollback de onaya tabidir.

Freeze window'lar#

Freeze window'lar haftanın günleri, başlangıç ve bitiş saati ve saat dilimiyle tanımlanır. Gece yarısını geçen pencereler de desteklenir (örneğin Cuma 17:00 → Pazartesi 09:00). Aktif bir pencere commit, manuel, schedule ve promote run'larını durdurur; rollback çalışmaya devam eder. Environment'ı anında dondurmak için Bu environment'ı freeze et'i kullanabilirsiniz.

Host shell#

Host shell'e izin ver kapalıyken image'ı olmayan bir SHELL step'i deployment'ı fail eder; step'e bir image verin. Aynı durumda DOCKER_COMPOSE_UP step'leri ve host'a erişim veren argümanlarla (--privileged, host path mount'ları, Docker socket gibi) çalışan DOCKER_RUN step'leri de reddedilir.

Uyarı: Host shell açıkken bu environment'ta pipeline düzenleyebilen herkes agent host'una agent'ın kullanıcısıyla erişebilir. Step'leriniz image ile çalışır hale gelince bu ayarı kapatın.

Kubernetes environment'ları#

  • K8S_DEPLOY, HELM_UPGRADE ve benzeri step'ler, step'te başka bir namespace verilmedikçe agent'ın çalıştığı namespace'e deploy eder.
  • TRIVY_SCAN step'leri için cluster'a Trivy kurulmalıdır: environment sayfasında Trivy kur'a basın. Trivy, agent'ın içinde değil ayrı Job pod'larında çalışır.
  • KANIKO_BUILD, Docker daemon'ı olmadan cluster içinde image build eder.

Docker environment'ları#

  • DOCKER_BUILD, DOCKER_RUN ve DOCKER_COMPOSE_UP step'leri agent host'unun Docker daemon'ını kullanır.
  • PODMAN_BUILD ise Docker daemon olmadan agent host'unda podman build çalıştırır. Agent, podman_build capability'sini yalnızca podman binary'si PATH'inde ise bildirir; yoksa run açık bir hatayla reddedilir. Registry login'i step bitince silinen geçici bir authfile kullanır. Kubernetes agent'ı PODMAN_BUILD'i reddeder: orada KANIKO_BUILD kullanın. Push edilmeden (registry_id olmadan) build edilen image podman'in kendi storage'ında kalır; DOCKER_RUN (Docker daemon) onu göremez: push edip registry'den deploy edin. build_args içine secret koymayın: image history'sine ve komut satırına girerler.
  • Image ile çalışan SHELL step'leri ve pack step'leri ayrı container'larda çalışır.

Environment'a özel değişkenler#

Altyapı > Değişkenler sayfasında kapsamı bir environment olan değişkenler tanımlayabilirsiniz. Bunlar aynı anahtara sahip global ve repo değişkenlerini ezer. Bkz. Secret'lar ve değişkenler.

Sonraki adımlar#

Son güncelleme: 21 Ekim 2026