Deploy
Dal başına önizleme, üretimden önce bir onay kapısı ve tek tıkla geri alma ile git’e bağlı deploylar.
Bu sayfada
PrimDB deployları GitHub üzerinden git’e bağlıdır. Herhangi bir dala yapılan her push bir önizleme deployu oluşturabilir; üretim, proje başına kontrol ettiğin bir onay kapısıyla korunur.
Ne dağıtabilirsin
Deponda Dockerfile varsa PrimDB onu derler ve aşağıdaki tablo geçersizdir: container haline getirebildiğin her şey çalışır. Dockerfile yoksa derleme kendiliğinden algılanır. Aşağıdakiler, gerçekten çalıştırdığımız derleyiciye karşı sınadığımız yığınlar ve her birinin senden istediği şey.
| Yığın | Neye bakar | Ne elde edersin | Senden ne ister |
|---|---|---|---|
| PHP / Laravel | composer.json | nginx + php-fpm, Laravel yönlendirmesi ve 404 davranışı bağlanmış hâlde | APP_KEY ayarla. Giriş noktan /public değilse NIXPACKS_PHP_ROOT_DIR ver. |
| Node | start betiği olan package.json | npm run start | Sabitlemezsen Node 18 gelir; package.json içinde engines.node ver. |
| Go | go.mod | Derlenmiş ikili | Hiçbir şey. |
| Python / Django | requirements.txt | Önce python manage.py migrate, sonra gunicorn | Ayarlarında WSGI_APPLICATION tanımlı olmalı. Yoksa derleme tam olarak bu mesajla durur. |
| Ruby / Rails | Gemfile | Ruby araç zinciri | .ruby-version dosyası şart, yoksa derleme anında durur. Başlatma komutu çıkarılamazsa kendin ver. |
Dürüst not. Bu tablo sınadıklarımız, çalışan her şey değil: derleyici bunlardan fazla dili destekliyor ve Dockerfile her zaman çalışır. İddia edebileceğimizi değil, kendimiz çalıştırdığımızı yazıyoruz.
URL’ler
Önizlemeler bir test alt alan adına, üretim ise proje slug’ına (ya da özel bir alan adına) iner.
preview {branch}-{hash}.test.{slug}.primdb.dev
production {slug}.primdb.dev (or your custom domain)Proje başına iki anahtar
| Anahtar | AÇIK | KAPALI |
|---|---|---|
auto-deploy | Bir git push otomatik olarak bir build tetikler | Deploy’u panelden ya da CLI’den elle tetiklersin |
auto-promote | Başarılı bir build doğrudan üretime gider | Build, bir insan onaylayana dek önizleme URL’sinde kalır |
Varsayılan auto-deploy AÇIK ve auto-promote KAPALI: pushlar otomatik build olur ama üretim her zaman onay bekler.
Onaya bağlı terfi
- Her build önce bir test alt alan adına iner.
- Bir Owner ya da Developer bunu inceler ve üretime ulaşmadan önce onaylar.
- Bir proje için ilk deploy otomatik terfi eder, çünkü korunacak önceki bir üretim yoktur.
İşlemler
- Geri alma: tek tıkla (ya da
primdb rollback) önceki herhangi bir üretim deployuna dön. - Zorla terfi: acil düzeltmeler için yalnızca Owner’a özel atlatma; test alt alan adını atlar ve denetim kaydında işaretlenir. CLI’den:
primdb deploy --force-prod. - Reddet: bir inceleyici bir build’i gerekçeyle reddeder; test alt alan adı hata ayıklama için 24 saat canlı kalır, sonra temizlenir.
Deploy yaşam döngüsü
| Durum | Anlam |
|---|---|
pending_review | Build başarılı, onay bekliyor |
production | Onaylandı ve üretim URL’sinde canlı |
rejected | Bir inceleyici tarafından reddedildi |
superseded | Aynı daldaki daha yeni bir build ile değiştirildi |
expired | 7 günden uzun süre işlem görmeden inceleme bekledi; otomatik temizlendi |
rolled_back | Üretimdeydi, şimdi bir geri almayla değiştirildi |
CLI komutları
primdb deploy # deploy the current branch at HEAD
primdb deploy --branch feature/x # deploy a specific branch
primdb deploy --wait # block until the build completes, stream logs
primdb deploy --force-prod # Owner only: bypass the approval gate
primdb deployments # list deployments (ID | STATUS | PROMOTION | ...)
primdb promote <id> # approve a preview to production
primdb rollback # roll back to the previous production deployment
primdb rollback --to <id> # roll back to a specific deploymentDürüst not. Build sistemi, tek bir Caddy önlü röle arkasında, Hetzner işçi düğümlerinde rootless Docker ile Nixpacks üzerinde çalışır. Bir git push’tan canlı önizlemeye hedef iki dakikanın altındadır.