İstem destekli uygulama dağıtımı

Özellik ne işe yarar?

Mevcut uygulamaya yönelik bilgi istemi uç noktası, yazılı bir bilgilendirmeyi existing Git template repository ile birleştirir ve bu depoyu normal, değişmez uygulama dağıtım hattı boyunca sıraya koyar. Özet daha sonraki yinelemeler için kaynak olarak kaydedilir.

Brifingden yeni bir uygulama havuzu oluşturur. Şablon URL’si gereklidir ve ilk dağıtım, kaynak isteği zaten uygulamadığı sürece çözümlenen revizyondaki şablon kaynağını içerir.

Bir bilgi isteminden ve şablondan oluşturun

POST /api/apps/from-prompt
Content-Type: application/json
 
{
  "brief": "A private reading-list app with a health endpoint",
  "template_git_url": "https://github.com/example/reviewed-template.git",
  "branch": "main",
  "visibility": "private"
}

Yanıt, dayanıklı uygulama, dağıtım ve derleme kimliklerinin yanı sıra bir derleme akışı URL’sini içerir. Yaratılış eş zamanlı değildir. Bir terminal durumuna ulaşana kadar dağıtım kaydını veya derleme akışını izleyin; Yalnızca ilerleme sessiz olduğundan yinelenen bir dağıtım göndermeyin.

Talebi göndermeden önce:

• havuzu ve lisansını gözden geçirin;
• dağıtım tarafından kullanılan kaynak revizyonunu tam olarak sabitleyin veya kaydedin;
• yükleme, derleme, çalıştırma, bağlantı noktası ve sağlık davranışını doğrulamak; ve
• sırları bilgi isteminden ve depodan uzak tutun.

Bilgi istemi bağlamdır, ortaya çıkan kaynağın onu karşıladığına dair kanıt değildir. Uygulanan davranışı brifingden türetilen kabul kriterlerine göre test edin.

Daha sonraki bir değişiklik talebinde bulunun

POST /api/apps/{app_id}/iterate
Content-Type: application/json
 
{
  "instruction": "Add an authenticated export endpoint and a regression test"
}

Bu, sahip olduğunuz ve Git kaynağına sahip bir uygulama için eşzamansız bir onarım aracısı görevi gönderir. Anket:

GET /api/apps/{app_id}/agent-status?thread_id={thread_id}

Durum yanıtı, en son dağıtım durumunu yineleme iş parçacığı durumuyla ve rapor edilen sonuç kanıtlarıyla birleştirir.

Önemli yineleme sınırı

Mevcut onarım yolu kendi sanal alanında çalışabilir ve yeni bir dağıtım talep edebilir, ancak geliştiricinin Git deposuna kalıcı olarak geri dönülmesi henüz garanti edilen bir aşama değildir. Dolayısıyla done aracı dizisi tek başına şunu kanıtlamaz:

• talep edilen değişikliğin yukarı akış deposunda mevcut olması;
• belirli bir taahhüt oluşturuldu;
• geçilen testler;
• yeni dağıtım aktif hale geldi; veya
• eski dağıtım geri yüklenebilir.

Her yineleme için, yukarı akış taahhüdünü, dağıtım kimliğini, derleme kimliğini, sistem durumu sonucunu ve kabul testi kanıtlarını bağımsız olarak kaydedin. Yukarı akış deposu güncellenmemişse, değişikliğe güvenmeden önce yamayı operatör tarafından incelenen bir kaynak kontrolü iş akışı aracılığıyla koruyun.

Güvenli kabul sırası

1. Özeti gözlemlenebilir kabul kriterlerine çevirin.
2. Seçilen şablonu ve tam revizyonu inceleyin.
3. Bir dağıtımı sıraya koyun ve dayanıklı kimliklerini takip edin.
4. Derlemeyi, aday sağlık kontrolünü ve rota geçişini ayrı ayrı onaylayın.
5. Kabul kriterlerini dağıtılan URL’ye göre uygulayın.
6. Kontrol ettiğiniz depoda kaynak taahhüdünün mevcut olduğunu doğrulayın.
7. Kanıtı ve geri alma hedefini saklayın.

Değişmez dağıtım aşamaları ve hata yönetimi için Uygulama dağıtımı’a bakın.