Ortamlar ve terfi

Cluster ERP'nin dört ortamı vardır: geliştirme iş istasyonu, sürekli tümleştirme, bir staging düğümü ve bir üretim düğümü. Bir sürüm, aynı etiket staging'de koştuktan sonra üretime ulaşır. Bu sayfa zinciri ve onu uygulayan kodu açıklar: deploy/install.sh, .github/workflows/ci.yml ve src/cluster_erp/server/staging_fixtures.py. Adım adım kurulum bir Linux düğümü kurun sayfasında, CI işleri CI hattı ve sürüm sayfasındadır.

Kısaca¶

• Bir düğüm deploy/install.sh --tag <tag> --domain <domain> --role staging|production ile kurulur; rol zorunludur (deploy/install.sh:77-83).
• Üretim kurulumu, aynı commit üzerinde açıklamalı staging-ok/<tag> terfi etiketi olmayan bir etiketi reddeder (deploy/install.sh:101-107).
• Bir düğüm rolünü ilk kurulumda kaydeder ve sonra başka bir rolü reddeder (deploy/install.sh:122-128).
• Sürekli tümleştirme her push'ta lint, lock ve test işlerini; sürüm etiketlerinde ise production ortamında onay bekleyen bir dağıtım işini koşar (.github/workflows/ci.yml:25-28, .github/workflows/ci.yml:126-136).
• Tarayıcı bataryası sürekli tümleştirmenin parçası değildir; terfi etiketi atılmadan önce staging düğümüne karşı koşar (.github/workflows/ci.yml:21-22).

Nasıl çalışır¶

Zincirin beş kapısı vardır. Diyagram onları sırayla gösterir.

flowchart LR
  dev["İş istasyonu"] --> ci["CI işleri lint, lock, test"]
  ci --> tag["Sürüm etiketi v*"]
  tag --> stg["install.sh --role staging"]
  stg --> battery["staging üzerinde _run_battery.mjs"]
  battery --> ok["staging-ok/v* etiketi"]
  ok --> prod["install.sh --role production"]
  tag --> deploy["CI deploy işi, onay"]
  deploy --> prod

Aynı içerik düz yazıyla:

1. Geliştirici bir iş istasyonunda çalışır. Windows'ta sunucu, server_workers ne derse desin tek süreç olarak koşar (src/cluster_erp/server/main.py:27-35).
2. Her push ve pull request lint, lock ve test işlerini koşar (.github/workflows/ci.yml:37-124).
3. Bir v* sürüm etiketi itilir. İş akışı aynı kapıları ve ardından deploy işini koşar (.github/workflows/ci.yml:126-129).
4. Operatör etiketi staging düğümüne --role staging ile kurar. Staging kurulumu terfi kaydı istemez (deploy/install.sh:101, tests/test_install_role_gate.py:145).
5. Tarayıcı bataryası staging düğümüne karşı koşar. web-client/_run_battery.mjs koşucusu her _e2e_*.mjs süitini sırayla koşar ve bir süit başarısız olduğunda ya da sonuç yazmadığında sıfırdan farklı kodla çıkar (web-client/_run_battery.mjs:1-20). İkinci bir PostgreSQL sunucusu veya yerel süreç isteyen süitler --exclude ile dışarıda bırakılır (web-client/_run_battery.mjs:35-38).
6. Batarya geçince operatör terfiyi aynı commit üzerinde ikinci bir açıklamalı etiket staging-ok/<tag> olarak kaydeder ve iter (deploy/install.sh:15-21).
7. Üretim kurulumu (elle ya da CI deploy işiyle) iki etiketi uzak depoda çözer. Kayıt yoksa ya da başka bir commit'i gösteriyorsa durur (deploy/install.sh:85-107).

Düğüm rolü¶

İlk kurulumda betik rolü ROLE_FILE ile adlandırılan dosyaya yazar (deploy/install.sh:58, deploy/install.sh:122-128). Sonraki bir kurulum farklı bir rolle gelirse betik, bir düğümün rolünü hiç değiştirmediğini söyleyerek durur. Staging test hesapları yalnız kayıtlı rolü staging olan bir düğümde oluşturulur (src/cluster_erp/server/staging_fixtures.py:92-105). Bkz. demo ve staging verisi.

Dağıtım işinin onayı¶

deploy işi GitHub production ortamına ve koşan bir dağıtımı hiç iptal etmeyen bir eşzamanlılık grubuna bağlıdır (.github/workflows/ci.yml:131-136). İş akışının başlığı ortamın zorunlu onaylayıcılarla yapılandırıldığını, böylece her dağıtımı bir kişinin Actions ekranında onayladığını söyler (.github/workflows/ci.yml:7-12). Onaylayıcı ayarının kendisi depo ayarlarında durur: Koddan belirlenemedi. İş düğümde install.sh --role production koşar; bu yüzden 7. adımdaki terfi kapısı ona da uygulanır (.github/workflows/ci.yml:155-156).

Neden böyle kurulmuştur¶

• "production runs a tagged release, never a branch tip" (deploy/install.sh:77).
• "a release reaches production only through staging" (deploy/install.sh:81).
• "a node keeps the role of its first install; staging data never meets production" (deploy/install.sh:122).
• "a tag alone never reaches a customer node" (.github/workflows/ci.yml:9-10).

Kurallar ve sınırlar¶

• Terfi kapısını tests/test_install_role_gate.py sınar (def test_ satırları olarak sayılan yedi test).
• Bir kurulum ancak /ready HTTP 200 döndükten ve ikamet denetimi geçtikten sonra canlı sayılır (deploy/install.sh:247-259). Bkz. security.txt ve hazırlık ve veri ikameti denetimi.
• Üretim kurulumu göçten önce yedek alır (deploy/install.sh:214-226).

Diğer parçalarla etkileşim¶

• Kiracı yaşam döngüsü: çok kiracılı düğümde kurulum, filo yükseltme çalıştırıcısını koşar.
• Veritabanı göçleri: bir sürümün şema değişikliği.
• Yedekler ve geri yükleme: yükseltme öncesi yedek.

Sınırlar ve açık noktalar¶

• Sürekli tümleştirme canlı korumaları CLUSTER_SKIP_LIVE_TESTS=1 ile atlar (.github/workflows/ci.yml:18-20, .github/workflows/ci.yml:99).
• Staging ve üretim düğümlerini hangi makinelerin oluşturduğu dağıtım verisidir ve güvenlik açıklama politikası gereği yazılmamıştır.
• Geçmiş terfilerin listesi wiki dışında tutulur ve burada yinelenmez.

Tanıtılan terimler¶

İlgili sayfalar¶

• İşletim
• Bir Linux düğümü kurun
• CI hattı ve sürüm
• E2E bataryası

92f8051 numaralı commit ile 2026-11-13 tarihinde doğrulandı.