Lietotnes izvietošana ar promptu

Ko dara funkcija

Pašreizējais prompt-to-app endpoint apvieno rakstisku brief ar esošu Git template repozitoriju un ievieto šo repozitoriju rindā caur parastu nemainīgu lietotnes izvietošanas pipeline. Brief tiek saglabāts kā provenance turpmākām iterācijām.

Tas negenerē jaunu lietotnes repozitoriju no brief. Template URL ir obligāts, un pirmajā izvietošanā ir template source uz atrisinātā revision, ja vien šis source jau neveic pieprasījumu.

Izveidot no prompta un template

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

Atbildē ir ilgtspējīgi app, deployment un build ID plus build straumes URL. Izveide ir asinhrona. Sekojiet izvietošanas ierakstam vai build straumei līdz galīgajam stāvoklim; neiesniedziet dublētu izvietošanu tikai tāpēc, ka progress ir klus.

Pirms iesniegt pieprasījumu:

• pārskatiet repozitoriju un tās licenci;
• piesaistiet vai fiksējiet precīzu source revision, ko izmanto izvietošana;
• pārbaudiet install, build, run, port un health uzvedību; un
• turiet secrets ārpus prompta un repozitorija.

Prompts ir konteksts, ne pierādījums, ka rezultāta source to apmierina. Pārbaudiet izvietoto uzvedību pret pieņemšanas kritērijiem, kas atvasināti no brief.

Pieprasīt vēlāku izmaiņu

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

Tas nosūta asinhronu repair-agent uzdevumu lietotnei, kuras īpašnieks esat un kurai ir Git source. Aptaujojiet:

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

Statusa atbildē apvienots jaunākais izvietošanas stāvoklis ar iterācijas thread stāvokli un jebkādiem ziņotajiem rezultātu pierādījumiem.

Svarīga iterācijas robeža

Pašreizējais repair ceļš var strādāt savā sandbox un pieprasīt jaunu izvietošanu, bet persistence atpakaļ uz izstrādātāja Git repozitoriju vēl nav garantēts posms. Tāpēc done agent thread pats par sevi nepierāda, ka:

• pieprasītā izmaiņa ir upstream repozitorijā;
• konkrēts commit tika build;
• testi izturēti;
• jaunā izvietošana kļuva aktīva; vai
• veco izvietošanu var atjaunot.

Katrā iterācijā neatkarīgi fiksējiet upstream commit, deployment ID, build ID, health rezultātu un acceptance test pierādījumus. Ja upstream repozitorijs netika atjaunināts, saglabājiet patch caur operatora pārskatītu source control workflow pirms paļauties uz izmaiņu.

Droša pieņemšanas secība

1. Pārvērtiet brief par novērojamiem pieņemšanas kritērijiem.
2. Pārskatiet izvēlēto template un precīzu revision.
3. Ievietojiet rindā vienu izvietošanu un sekojiet tās ilgtspējīgajiem ID.
4. Apstipriniet build, kandidāta health check un route switch atsevišķi.
5. Pārbaudiet pieņemšanas kritērijus pret izvietoto URL.
6. Apstipriniet, ka source commit pastāv repozitorijā, kuru kontrolējat.
7. Saglabājiet pierādījumus un rollback mērķi.

Skatiet Lietotnes izvietošana par nemainīgiem izvietošanas posmiem un kļūdu apstrādi.