Skip to Content
TestingPrompt-alapú alkalmazás-telepítés

Prompt-alapú alkalmazás-telepítés

Mit csinál a funkció

A jelenlegi prompt-to-app végpont egy írásos briefet meglévő Git sablon repóval kombinál, és a repót a szokásos immutable app-deployment pipeline sorába teszi. A brief provenance-ként mentődik a későbbi iterációkhoz.

Nem hoz létre új alkalmazás repót a briefből. A sablon URL kötelező, az első telepítés a sablon forrását tartalmazza a feloldott revízióban, hacsak a forrás már nem valósítja meg a kérést.

Létrehozás promptból és sablonból

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"
}

A válasz tartalmazza az alkalmazás, a telepítés és a build tartós ID-it, valamint a build stream URL-jét. A létrehozás aszinkron. Kövesse a telepítés rekordját vagy a build streamet, amíg terminális állapotba nem ér; ne küldjön duplikált telepítést csak azért, mert a folyamat sokáig csendes.

A kérés elküldése előtt:

  • nézze át a repót és a licencét;
  • rögzítse vagy jegyezze fel a telepítés által használt pontos forrásrevíziót;
  • ellenőrizze a telepítés, build, futás, port és health check viselkedését; és
  • tartsa a secret-eket a prompton és a repón kívül.

A prompt kontextus, nem bizonyíték arra, hogy a kapott forrás megfelel a briefnek. Tesztelje a telepített viselkedést a briefből levezetett elfogadási kritériumokkal szemben.

Későbbi módosítás kérése

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

Ez aszinkron repair-agent feladatot indít egy Ön által birtokolt, Git forrással rendelkező alkalmazáshoz. Lekérdezés:

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

A státusz válasz összekapcsolja a legfrissebb telepítési állapotot az iteration thread állapotával és az esetlegesen jelentett eredménybizonyítékokkal.

Fontos iterációs határ

A jelenlegi repair út dolgozhat a sandboxában és kérhet friss telepítést, de a visszaírás a fejlesztő Git repójába még nem garantált szakasz. A done agent thread önmagában ezért nem bizonyítja, hogy:

  • a kért módosítás megvan az upstream repóban;
  • egy adott commit buildelt;
  • a tesztek sikeresek voltak;
  • az új telepítés aktív lett; vagy
  • a régi telepítés visszaállítható.

Minden iterációnál külön rögzítse az upstream commitot, a deployment ID-t, a build ID-t, a health check eredményét és az elfogadási teszt bizonyítékait. Ha az upstream repó nem frissült, őrizze meg a patch-et operátor által átnézett source-control workflow-n keresztül, mielőtt a módosításra támaszkodna.

Biztonságos elfogadási sorrend

  1. Fordítsa le a briefet megfigyelhető elfogadási kritériumokra.
  2. Nézze át a kiválasztott sablont és a pontos revíziót.
  3. Sorba állítson egy telepítést, és kövesse a tartós ID-ket.
  4. Külön erősítse meg a buildet, a jelölt health checket és az útvonal váltást.
  5. Futtassa az elfogadási kritériumokat a telepített URL-en.
  6. Erősítse meg, hogy a forrás commit létezik az Ön által irányított repóban.
  7. Őrizze meg a bizonyítékokat és a rollback célt.

Lásd az App deployment oldalt az immutable telepítési szakaszokról és a hibakezelésről.

Alkalmazás-megfigyelhetőségObjektumtár