Notitie
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen u aan te melden of de directory te wijzigen.
Voor toegang tot deze pagina is autorisatie vereist. U kunt proberen de mappen te wijzigen.
[Dit artikel is voorlopige documentatie en kan worden gewijzigd.]
De binnenste lus van Copilot Managed Runtime-apps is een snelle, Git-systeemeigen werkstroom voor het bouwen, bekijken en implementeren van apps. Bewerk code in je IDE, commit en push deze, en laat het platform de push-commit voor het preview-eindpunt bouwen. Wanneer u klaar bent om live te gaan, implementeert u expliciet door .ms app deploy
In dit artikel wordt beschreven hoe elke fase van de binnenste lus werkt, wat het platform achter de schermen doet en waar uw werk zich bij elke stap bevindt. Het vormt een aanvulling op Quickstart: een Microsoft Copilot Managed Runtime-app bouwen met GitHub Copilot (preview) en Quickstart: maak een app met de Copilot Managed Runtime SDK (preview), die end-to-end dezelfde stroom doorlopen met opdrachten.
Wat u kunt verwachten
Een paar gedragingen bepalen de hele ervaring. Als je ze van tevoren kent, wordt de rest van de binnenste lus voorspelbaar.
- Het is Git-native. De
msCLI werkt met echte Git in plaats van het te vervangen. U gebruiktgit add,git commit, engit pushop dezelfde manier als u zou doen bij elk ander project, dus uw coderingsagenten, branchebeleid en bestaande werkstromen worden allemaal overgenomen. - Builds verschijnen wanneer u ze nodig hebt. A
git pushwerkt je bron van waarheid bij, maar bouwt zelf niets. Het platform wordt op aanvraag gebouwd: wanneer u de preview-versie opent, tijdens de implementatie of wanneer u zelf een build uitvoert. - Preview is automatisch; Live gaan is opzettelijk. Elke geslaagde build is beschikbaar als preview-versie. Het promoveren ervan naar uw live app is altijd een expliciete stap die u neemt.
- Elke build is adresseerbaar. Elke build heeft een stabiele id, een status en de doorvoering waarvan deze afkomstig is, zodat u zich op elke build
--commit <sha>kunt richten wanneer u de status controleert of de build implementeert.
Opslagmodi
Elke app is gebonden aan een van de twee opslagplaatsmodi. U kiest de modus op ms app create of ms app init. De modus staat vast gedurende de levensduur van de app en voor het schakelen tussen modi moet een nieuwe app worden gemaakt.
| Modus | Trigger | Bron van waarheid | Wanneer gebruiken |
|---|---|---|---|
| Door platform beheerde Git (standaard) |
ms app create
--repo zonder vlag |
Een opslagplaats die het platform namens u inricht en beheert | Teams die geen bestaande broncontrole-instellingen hebben, of die standaard Git zonder configuratie willen. |
| Uw eigen GitHub meenemen |
ms app create
--repo <url>
|
Een externe opslagplaats die eigendom is van een GitHub Enterprise Cloud-organisatie | Teams die al standaardiseren op GitHub Enterprise Cloud en willen dat hun bestaande branchebeleid, pull-aanvraagbeoordelingen en CI van toepassing zijn op de beheerde app. |
| Breng je eigen build mee |
ms app create
--repo none
|
Er is geen repository waarvan het platform op de hoogte is. In dit geval moet u de code zelf bouwen om deze op het platform te implementeren. | Gebruik deze modus als u de broncode niet wilt beheren via GitHub of door het platform beheerde git. |
Omgevingen
Elke ontwikkelaar en elke coderingsagent die namens hen apps maakt, komt terecht in een omgeving: een veilige sandbox die het platform eerst ms app createms app initof .
Een omgeving heeft een identiteitsbereik, wordt automatisch ingericht en neemt het beleid van uw organisatie over vanaf het moment dat de omgeving bestaat. Je vraagt er niet om; Je begint gewoon te werken en het is er. Deze omgevingen zijn vooraf geconfigureerd met een door Microsoft beheerde basislijn van beheerbeleid, dus het beheer is van toepassing vanaf het moment dat u begint met maken. Beheerders kunnen vervolgens de basislijn valideren en indien nodig aanpassen.
De binnenste luscyclus
Een typische iteratie van een app doorloopt vier fasen. In elke fase is het duidelijk waar je werk zich bevindt.
Bewerken en lokaal uitvoeren
Je bewerkt code in de IDE van je keuze en voert de app lokaal uit met ms app dev. De CLI orkestreert de volledige lokale lus: het start het ontwikkelproces van uw project en drukt de afspeel-URL af. De lokale app is precies wat u in de browser ziet: geen platformaanroepen, geen build, geen implementatie.
Op dit moment leeft je werk alleen in je werkende boom. Je hebt je nog niet vastgelegd of gepusht.
Doorvoeren en pushen
Wanneer de app zich lokaal gedraagt zoals u wilt, moet u zich committeren met git commit en pushen met git push. De push werkt de externe opslagplaats bij, ofwel de door het platform beheerde Git-opslagplaats of uw gebonden externe GitHub-opslagplaats. De push activeert niet zelf een build. De afstandsbediening heeft nu een nieuwe commit die het platform als een bouwbare kandidaat beschouwt.
Uw werk bevindt zich nu in de externe opslagplaats.
Platform bouwen
Een platformbuild is het gecompileerde artefact dat het platform maakt op basis van de broncode wanneer u:
- Een voorbeeld van uw app bekijken
- Je app implementeren
- Uw app maken met
ms app build
Elke build wordt geïdentificeerd aan de hand van de doorvoer-SHA waar deze vandaan komt en heeft zijn eigen status (Bouwen, Geslaagd of Mislukt). Elke geslaagde platformbuild is automatisch beschikbaar op uw preview-eindpunt en kan worden geïmplementeerd in uw live-app met behulp van ms app deploy.
Preview
De eerste keer dat het preview-eindpunt wordt geraakt voor een doorvoering die nog geen build heeft, plaatst het platform een build voor die doorvoering in de wachtrij. Het resultaat wordt weergegeven via de voorbeeld-URL.
Implementeren
Wanneer het voorbeeld er goed uitziet, ms app deploy bevordert dit een succesvolle build van de live-app. De live-URL bedient de geïmplementeerde build tot de volgende ms app deploy.
Uw live-app blijft aanwezig in deze geïmplementeerde build, onafhankelijk van de preview, die altijd volgt op uw laatste succesvolle build.
Foutafhandeling
Als een build mislukt, blijft het preview-eindpunt de laatste geslaagde build voor de app weergeven. Voer het volgende uit ms app build-statusom uit te zoeken waarom het is mislukt:
ms app build-status --app <name> --commit <sha>
De uitvoer rapporteert de mislukte build en de reden waarom deze is mislukt, zodat je de code kunt herstellen en opnieuw kunt pushen. De volgende push activeert een nieuwe buildpoging wanneer deze wordt geopend; De eerste versie bevat geen opdracht om het handmatig opnieuw te proberen.
Gedrag van voorbeeldeindpunt
De preview-URL is een stabiele URL per app, gescheiden van de live URL. Zie het als 'de nieuwste succesvolle build on main'. Het platform lost dit op door recente builds te controleren:
| Buildstatus | Gedrag van voorbeeld |
|---|---|
| De meest recente doorvoering heeft een succesvolle build | Rendert de build. |
| De laatste doorvoering wordt nog opgebouwd | Hiermee wordt de vorige geslaagde build weergegeven met een actieve banner: 'De meest recente build wordt uitgevoerd'. |
| Meest recente doorvoering kan niet worden gemaakt | Hiermee wordt de vorige geslaagde build weergegeven met de banner ' Fout mislukt': 'Meest recente build is mislukt. De laatste geslaagde build wordt weergegeven.' |
| App heeft nog geen geslaagde build | Geeft een toegewezen 'nooit geïmplementeerde' ervaring weer. |
Als je het voorbeeld opent voor een doorvoering die geen build heeft, wordt er een gestart.
Preview-toegang is beperkt tot ontwikkelaars met schrijftoegang tot de afhankelijke opslagplaats. De preview-URL kan niet worden gedeeld met willekeurige gebruikers. daar is de live URL plus ms app share voor.
Je app implementeren voor livegebruik
Gebruik deze indeling ms app deploy om een succesvolle build van de live-app te promoten. Het gedrag is afhankelijk van wat er beschikbaar is:
-
Zonder vlag implementeert de opdracht de nieuwste succesvolle build op
main. Als de meest recente doorvoerbewerking zelf succesvol is, implementeert de opdracht die build. -
Als de nieuwste build is mislukt, valt de opdracht terug op de meest recente build die correct is uitgevoerd en
mainwordt een waarschuwing weergegeven. U ziet precies wat u implementeert en wat er is overgeslagen. -
Als een build nog in ontwikkeling is,
ms app deployverwijst u naarms app build-statusin plaats van te wachten tot de build is voltooid. -
Met
--commit <sha>, maakt de opdracht een specifieke eerdere commit vast. Gebruik deze optie om terug te gaan naar een build die bekend staat om goede prestaties, zonder de geschiedenis van de opslagplaats te herstellen.
De live URL is wat u deelt met eindgebruikers via ms app share en links deelt. De versie wordt alleen bijgewerkt wanneer u deze uitvoert ms app deploy; de liveversie is een vaste momentopname totdat u opnieuw implementeert.