Versioner

Fabriken omvandlar uppgifter och planer till granskade pull requests. När de har mergats svarar en release på nästa fråga: vilket arbete körs var, och var det säkert att lägga det där?

En release låser en exakt Git-commit och följer den genom dina miljöer, till exempel Staging och sedan Production. Committen kan redan finnas på din deployment-branch, eller så kan Coroid först samla öppna pull requests i en release-pull request vars merge-commit blir releasen. Vid varje steg kontrollerar Coroid committen, samlar in de godkännanden du begär och registrerar deploymenten som din CI/CD rapporterar tillbaka. Coroid markerar aldrig en release som distribuerad enbart på sina egna uppgifter. Din pipeline, eller en person som registrerar en extern deployment, måste bekräfta den.

Idén på en minut#

• Release: en commit, ett namn och en valfri version. En version som 2.4.0 är valfri, så kontinuerlig leverans fungerar utan taggar.
• Miljö: ett steg på vägen till användarna, till exempel Staging eller Production. Varje projekt definierar sina egna steg och i vilken ordning de kommer.
• Utrullning: vilka miljöer releasen hittills har nått.
• Arbete: uppgifterna som planerats för releasen och de mergade ändringar den innehåller, visade som klara av totalt antal.
• Fyra steg per miljö: kontroller, godkännande, distribution och hälsa. Release- sidan öppnar alltid på steget där du behövs.
• Paket: en release som byggts av öppna pull requests. Coroid mergar dem till en release-branch, i en ordning du kan ändra, och öppnar en release-pull request. En samlingsrelease har ett femte steg, Paket, före kontrollerna.

Få en snabb överblick över en release#

Öppna Versioner i huvudmenyn i sidofältet för alla projekt, eller projektets Versioner -flik för just det projektet. Körs just nu, högst upp, visar vilken version varje miljö kör, baserat på den senast bekräftade deploymenten, oavsett vem som startade den. Listan visar varje releases arbetsförlopp, dess utrullning mellan miljöer och dess status. Använd flikarna för att växla mellan releaser som pågår, har levererats eller har stängts.

Välj en release för att öppna dess sida.

Utrullningsspåret fungerar också som en växlare. Välj en miljö där för att se dess fyra steg. Sidan öppnas på den första miljö som releasen ännu inte har nått, så nästa sak att göra visas vanligtvis redan.

De fyra stegen i varje miljö#

Kontroller. Välj Kör kontroller. Coroid kör projektets Quality Graph för releasevalidering mot den exakta committen och bekräftar att varje länkad ändring ingår i den committen. Alla obligatoriska checklistpunkter för miljön måste också markeras som klara. Om något blockerar releasen visar steget vad det är. Om committen eller de länkade ändringarna ändras blir tidigare kontroller inaktuella och steget ber dig köra dem igen.

Godkännande. När kontrollerna har godkänts kan de personer som reglerna tillåter godkänna. Steget visar hur många godkännanden som krävs och från vilka roller. Om reglerna kräver godkända releasenoteringar godkänns även noteringarna här.

Distribution. När kontroller och godkännande är klara är releasen redo för miljön. Om Coroid är anslutet till GitHub Actions eller GitLab CI/CD för den miljön väljer en Ägare eller Administratör Distribuera till… så startar Coroid pipelinen för exakt den committen. Annars sköter din pipeline deploymenten på egen hand och rapporterar tillbaka. Oavsett vilket blir steget grönt först när en lyckad deployment har bekräftats.

Hälsa. Efter en lyckad deployment kör Coroid projektets canary- Quality Graph, om du har en sådan. En godkänd canary markerar miljön som frisk. Om den misslyckas visas Behöver åtgärdas och återställning erbjuds. Utan en canary förblir hälsostatusen okänd, i stället för att antas vara frisk.

Statusförklaring#

Redo betyder aldrig att något har distribuerats. Bara en bekräftad deployment flyttar en release framåt i utrullningsspåret.

Arbetsflöden#

Konfigurera releaser för ett projekt#

Gör detta en gång per projekt. Öppna Versioner, välj Releaseinställningar, och välj projektet.

1. I Miljöer, lägg till stegen och ordna dem, till exempel Staging före Production.

2. I Godkännanderegler, publicera regler för varje miljö: antal nödvändiga godkännanden, vilka roller de ska komma från och eventuella checklistpunkter. En miljö kan inte klara sina kontroller förrän reglerna har publicerats.

3. I Deploymentpipeline, välj om Coroid ska starta deploymenten eller om din pipeline ska göra det. Skapa sedan en rapporteringstoken så att din CI/CD kan tala om för Coroid vad den distribuerade.

4. I Versionshantering, välj var varje releases version ska hämtas från och ange en versions-URL för varje miljö så att Coroid kan bekräfta vad som körs där.

Releaseinställningar går igenom varje skärm, och Lägg till versionen i din build visar hur versionen når din app.

Leverera planerat arbete#

Använd detta när du i förväg vet vad som ska levereras tillsammans.

1. Skapa releasen i förväg, innan en commit är låst. Den börjar som ett utkast.
2. Ange målrelease för uppgifterna du vill ha med. De visas under Planerade uppgifter, och arbetsindikatorn fylls i allt eftersom de blir klara.
3. När arbetet har mergats väljer du Redigera uppgifter och väljer committen som ska levereras. Coroid bekräftar vilka mergade ändringar committen innehåller.
4. Gå igenom de fyra stegen för den första miljön och sedan nästa.

Samla öppna pull requests#

Använd detta när många pull requests väntar, från Coroid eller teamet, och de ska levereras tillsammans.

1. Välj Ny release, välj projektet och sedan Öppna pull requests. Alternativet kräver ett GitHub- eller GitLab-repository, så projekt som hanteras av Coroid släpper i stället en commit.
2. Coroid visar öppna pull requests till distributionsbranchen, med de säkraste först. En pull request som Coroid har öppnat visas som dess uppgift eller plan. Coroid väger in vad leverantören och dess egen granskning redan känner till: kontroller, granskningar, storlek, konflikter och filer som berörs av flera pull requests. Utkast, underkända kontroller, begärda ändringar och pull requests från forkar utelämnas, och orsaken anges.
3. Avmarkera det som bör vänta och ändra ordningen med pilarna. En pull request som bygger på en annan (en staplad pull request eller en som säger ”depends on #12”) kommer alltid efter den.
4. Välj Skapa release. Coroid skapar release/<version> från distributionsbranchen, slår ihop pull requests i ordning och öppnar en release-pull request med en lista över dem och länkar till var och en.
5. Om en pull request står i konflikt med release-branchen stannar steget Paket där och visar filerna. Välj Lös med Coroid så att utvecklaragenten kan slå ihop den och lösa konflikten i en uppgift, eller Utelämna den för att fortsätta utan den.
6. Granska release-pull requesten och slå ihop den med en merge commit. Leverantören markerar då varje inkluderad pull request som sammanslagen. Coroid låser merge commit som release-commit, registrerar de inkluderade pull requestsen som det som levereras och stänger de som fortfarande är öppna med en länk till release-pull requesten.
7. Gå igenom de fyra stegen för varje miljö som vanligt.

Squash- eller rebase-sammanslagningar fungerar också, men leverantören markerar inte de ursprungliga pull requestsen som sammanslagna. Coroid stänger dem i stället med en kommentar.

Leverera det som finns på main-branchen#

Använd detta för kontinuerlig leverans, när du levererar allt som har slagits ihop.

1. Välj Ny release och välj commit, oftast den senaste på distributionsbranchen.
2. Under Jämför medväljer du miljön som du ska ersätta. Coroid listar pull requests och commits mellan det som körs där och din commit, och väljer dem som går att verifiera.
3. Lämna namn och version tomma om du vill. Coroid namnger releasen efter datumet och den korta commit-hashen, och projektets versionskälla fyller i versionen. Varje release får också nästa byggnummer.
4. Skapa releasen och gå igenom de fyra stegen.

Om din pipeline distribuerar vid varje sammanslagning, eller om någon distribuerar manuellt utan att be Coroid om det, kan den ändå rapportera varje distribution. Om det inte finns någon release för en rapporterad commit skapar Coroid en observerad release för den, tydligt markerad som att den inte har klarat Coroids kontroller. Den får den version som pipelinen rapporterade, eller nästa version om Coroid tilldelar projektets versioner (1.4.1 efter 1.4.0), samt nästa byggnummer.

Leverera en akut korrigering#

En ägare eller administratör kan aktivera Det här är en snabbkorrigering när en release skapas, låsa korrigeringens fullständiga commit och ange varför den vanliga tidsplanen inte fungerar. Snabbkorrigeringar följer varje miljös regler för snabbkorrigeringar, som kan kräva färre godkännanden. Kvalitetskontroller och obligatoriska checklistpunkter gäller fortfarande, och endast ägare och administratörer kan godkänna snabbkorrigeringar.

Återställ efter ett avbrott#

Om hälsosteget visar Behöver åtgärdasöppnar du Hälsa i den berörda miljön och väljer en tidigare fungerande commit att distribuera på nytt. Återställning och release-tåg tar upp alternativen, även pipelines som inte kan rapportera tillbaka.

Från chatt eller din editor#

Chattassistenten och Coroid:s MCP-server har samma verktyg för releaser: lista och granska releaser, välja en commit, förhandsgranska vad som skulle levereras, förbereda en release, samla öppna pull requests, köra kontroller, godkänna, begära en distribution och skapa utkast till versionsanteckningar. En person måste alltid bekräfta när pull requests samlas, godkänns eller distribueras. Se Chattassistent och Coroid som MCP-server.

Släpp flera projekt tillsammans#

Ett release-tåg grupperar releaser från flera projekt som måste levereras tillsammans, i ordning, till exempel ett API och appen som är beroende av det. Se Återställning och release-tåg.

Vad Coroid gör och inte gör#

• Coroid låser, kontrollerar och registrerar. Ditt repo och CI/CD bygger och distribuerar.
• När pull requests samlas skapar Coroid release-branchen och release-pull requesten. Den slår aldrig ihop release-pull requesten åt dig.
• Coroid startar en pipeline endast när du ansluter en och en ägare eller administratör begär en distribution.
• En distributionsbegäran är inget bevis. Utrullningsspåret går vidare först när pipelinen bekräftar att distributionen lyckades eller någon registrerar en verifierad extern distribution.
• Versionsanteckningar är utkast som du redigerar och godkänner. Coroid publicerar dem inte någonstans.
• En sprint är en planeringsperiod, inte en gräns för distributioner. En sprint kan bidra till flera releaser, och en release kan innehålla arbete från flera sprintar.

Relaterat#

• Releaseinställningar
• Distributionshändelser och CI-konfiguration
• Lägg in versionen i din build
• Återställning och release-tåg
• Sprintar
• Uppgifter, planer, sprintar och banor
• Kvalitet och granskningsunderlag