Byg, forhåndsvis og udrul Microsoft Copilot Managed Runtime-apps (prøveversion)

[Denne artikel er foreløbig dokumentation og kan ændres uden varsel.]

Copilot Managed Runtime-apps ' indre loop er en hurtig, Git-native arbejdsproces til opbygning, forhåndsvisning og udrulning af apps. Rediger kode i dit IDE, udfør og skub den, og lad platformen bygge den pushede bekræftelse for eksempelvisningens slutpunkt. Når du er klar til at gå online, kan du installere eksplicit ved hjælp af ms app deploy.

Denne artikel beskriver, hvordan hver fase i det indre loop fungerer, hvad platformen gør bag kulisserne, og hvor dit arbejde befinder sig på hvert trin. Den supplerer Hurtig introduktion: Byg en Microsoft Copilot Managed Runtime-app med GitHub Copilot (prøveversion) og Hurtig introduktion: Opret en app med Copilot Managed Runtime SDK (prøveversion), som gennemgår det samme flow fra ende til slut med kommandoer.

Hvad kan du forvente

Nogle få funktionsmåder former hele oplevelsen. At kende dem på forhånd gør resten af det indre loop forudsigeligt.

  • Det er Git-native. ms CLI fungerer med ægte Git i stedet for at erstatte den. Du bruger git add, git commit, og git push på samme måde, som du ville gøre på et hvilket som helst projekt, så dine kodningsagenter, branchepolitikker og eksisterende arbejdsprocesser alle overføres.
  • Builds kan realiseres, når du har brug for dem. A git push opdaterer din kilde til sandhed, men bygger ikke noget alene. Platformen bygger efter behov: når du åbner prøveversionen, når du installerer, eller når du selv kører et build.
  • Forhåndsvisning sker automatisk. At gå live er bevidst. Alle vellykkede builds kan vises. At promovere en til din live-app er altid et eksplicit skridt, du tager.
  • Hvert build kan adresseres. Hvert build har et stabilt id, en status og bekræftelsen, det kom fra, så du kan målrette ethvert build ved hjælp --commit <sha> af, hvornår du kontrollerer dets status eller installerer det.

Lagertilstande

Hver app er bundet til en af to lagertilstande. Du vælger tilstanden ved ms app create eller ms app init. Tilstanden er fast i appens levetid, og skift af tilstand kræver, at der oprettes en ny app.

Tilstand Udløser Sandhedens kilde Anvendelse
Platformsadministreret Git (standard) ms app create uden --repo flag Et lager, som platformen klargør og administrerer på dine vegne Teams, der ikke har en eksisterende konfiguration til kildekontrol, eller som vil have nul-konfigurations-Git med det samme.
Medbring dit eget GitHub ms app create --repo <url> Et eksternt lager, der ejes af en GitHub Enterprise Cloud-organisation Teams, der allerede standardiserer på GitHub Enterprise Cloud og ønsker, at deres eksisterende forgreningspolitikker, gennemgange af pull-anmodninger og CI skal gælde for den administrerede app.
Medbring dit eget build ms app create --repo none Der er ikke noget lager, som platformen er opmærksom på. I dette tilfælde skal du selv bygge koden for at installere den på platformen. Brug denne tilstand, hvis du ikke vil administrere kilden via GitHub eller platformsadministreret Git.

Miljøer

Hver udvikler og enhver kodningsagent, der opretter apps på deres vegne, lander i et miljø: en sikker sandkasse, som platformen klargør på første ms app create eller ms app init.

Et miljø er identitetsbegrænset, klargøres automatisk og nedarver din organisations politikker fra det øjeblik, det opstår. Du beder ikke om det; Du går bare i gang med at arbejde, og så er det der. Disse miljøer er forudkonfigureret med en Microsoft-administreret grundlinje af administratorpolitikker, så styring gælder fra det øjeblik, du begynder at oprette. Administratorer kan derefter validere og tilpasse den oprindelige plan efter behov.

Den indre loop-cyklus

En typisk gentagelse i en app bevæger sig gennem fire faser. I hver fase er det tydeligt, hvor du arbejder.

Rediger og kør lokalt

Du redigerer koden i dit foretrukne IDE og kører appen lokalt med ms app dev. CLI orkestrerer det fulde lokale kredsløb: det starter dit projekts udviklingsproces og udskriver afspilnings-URL'en. Den lokale app er præcis, hvad du ser i browseren: ingen platformkald, intet build, ingen installation.

På dette tidspunkt bor dit arbejde kun i dit arbejdstræ. Du har ikke forpligtet dig eller skubbet endnu.

Bekræft og skub

Når appen fungerer, som du ønsker det lokalt, skal du bekræfte med git commit og skub med git push. Push-opdateringer til det eksterne lager, enten det platformsadministrerede Git-lager eller dit bundne eksterne GitHub-lager. Skubbet udløser ikke et build af sig selv. Fjernbetjeningen har nu en ny bekræftelse om, at platformen betragter som en kandidat, der kan bygges.

Dit arbejde ligger nu i det eksterne lager.

Platformsbuild

Et platformsbuild er den kompilerede artefakt, som platformen opretter ud fra kildekoden, når du:

Hvert build identificeres af den bekræftelses-SHA, det kom fra, og har sin egen status (opbygger, lykkedes eller mislykkedes). Alle vellykkede platformsbuilds er automatisk tilgængelige på dit eksempelslutpunkt og kan installeres i din liveapp ved hjælp af ms app deploy.

Forhåndsvisning

Første gang eksempelslutpunktet rammes for en bekræftelse, der endnu ikke har et build, sætter platformen et build i kø for den pågældende bekræftelse. URL-adressen til forhåndsvisningen gengiver resultatet.

Rul ud

Når eksemplet ser rigtigt ud, ms app deploy fremhæves et vellykket build til liveappen. Den dynamiske URL-adresse bruges til det installerede build indtil det næste ms app deploy.

Din live-app forbliver på dette installerede build, uafhængigt af prøveversionen, som altid følger dit seneste vellykkede build.

Håndtering af fejl

Hvis et build mislykkes, fortsætter eksempelslutpunktet med at betjene det sidste vellykkede build til appen. Du kan finde ud af, hvorfor det mislykkedes, ved at køre ms app build-status:

ms app build-status --app <name> --commit <sha>

Outputtet rapporterer om det mislykkede build og årsagen til, at det mislykkedes, så du kan rette koden og skubbe igen. Det næste push udløser et nyt build-forsøg, når det åbnes. Der er ingen manuel kommando til at forsøge igen i den første version.

Eksempelvisning af slutpunktets funktionsmåde

URL-adressen til forhåndsvisning er en stabil URL-adresse pr. app, der er adskilt fra den aktive URL-adresse. Tænk på det som "den seneste succesfulde build på main." Platformen løser det ved at tjekke de seneste builds:

Build-tilstand Funktionsmåde for eksempelvisning
Seneste bekræftelse har et vellykket build Gengiver buildet.
Seneste bekræftelse bygges stadig Gengiver det tidligere vellykkede build med et igangværende banner: "Seneste build er i gang."
Seneste bekræftelse kunne ikke bygges Gengiver det tidligere vellykkede build med et fejlbanner: "Seneste build mislykkedes. Viser det sidste vellykkede build."
Appen har endnu ikke noget vellykket build Gengiver en dedikeret "aldrig udrullet" oplevelse.

Når du åbner eksemplet for en bekræftelse, der ikke har noget build, starter en.

Adgangen til forhåndsvisning er begrænset til udviklere med skriveadgang til det bundne lager. Eksempel-URL'en kan ikke deles med vilkårlige brugere. Det er det, den dynamiske URL plus ms app share er til.

Installér din app for at gå live

Bruges ms app deploy til at promovere et vellykket build til liveappen. Funktionsmåden afhænger af, hvad der er tilgængeligt:

  • Uden flag installerer kommandoen det seneste vellykkede build på main. Hvis den seneste bekræftelse af sig selv lykkes, implementerer kommandoen dette build.
  • Hvis det seneste build mislykkedes, går kommandoen tilbage til det seneste vellykkede build og main viser en advarsel. Du kan se præcis, hvad du installerer, og hvad der blev sprunget over.
  • Hvis et build stadig er i gang, henvises du til i stedet for at ms app build-status vente på, ms app deploy at bygget afsluttes.
  • Med --commit <sha>fastgør kommandoen en bestemt tidligere bekræftelse. Brug denne indstilling til at gå tilbage til et fungerende build uden at gendanne din lagerhistorik.

Den live URL-adresse er den, du deler med slutbrugere via ms app share og deler links. Det opdateres kun, når du kører ms app deploy. Live-buildet er et fast snapshot, indtil du installerer igen.

  • Sidst opdateret den