Versioner

Mjukvaruutvecklingsfabriken omvandlar uppgifter och planer till granskade pull requests. När de har mergats svarar en version på nästa fråga: vilket av arbetena körs var, och var det säkert att driftsätta det där?

En release låser fast en specifik Git-commit och följer den genom dina miljöer, till exempel Staging och sedan Production. Commiten kan redan finnas på din driftsättningsbranch, 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 commiten, samlar in de godkännanden du begär och registrerar driftsättningen som din CI/CD rapporterar tillbaka. Coroid markerar aldrig en release som driftsatt utan bekräftelse. Din pipeline, eller en person som registrerar en extern driftsättning, 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 det totala antalet.
• Fyra steg per miljö: kontroller, godkännande, driftsättning och hälsa. Releasesidan öppnas alltid på det steg där du behöver agera.
• Paket: en release som byggts från öppna pull requests. Coroid mergar dem till en release-branch, i en ordning som du kan ändra, och öppnar en release-pull request. En samlad release har ett femte steg, Paket, före kontrollerna.

Få en överblick över en version#

Öppna Versioner i huvudmenyn i sidofältet för alla projekt, eller fliken Versioner för ett enskilt projekt. Listan visar för varje version hur arbetet fortskrider, hur den rullas ut i miljöerna och dess status. Använd flikarna för att växla mellan versioner som pågår, har driftsatts eller har stängts.

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

Utrullningsspåret fungerar också som en väljare. Välj en miljö i spåret för att se dess fyra steg. Sidan öppnas vid den första miljö som versionen ännu inte har nått, så nästa åtgärd visas oftast redan.

De fyra stegen i varje miljö#

Kontroller. Välj Kör kontroller. Coroid kör projektets Quality Graph för versionsvalidering mot den specifika committen och bekräftar att alla länkade ändringar ingår i den. Eventuella obligatoriska checklistpunkter för miljön måste också markeras som slutförda. Om något blockerar versionen visas det i steget. Om du ändrar committen eller de länkade ändringarna blir tidigare kontroller inaktuella, och steget ber dig köra dem igen.

Godkännande. När kontrollerna har godkänts kan de personer som dina regler tillåter godkänna versionen. I steget visas hur många godkännanden som krävs och från vilka roller. Om dina regler kräver godkända versionsanteckningar godkänns även anteckningarna här.

Driftsättning. När kontrollerna och godkännandet är klara är versionen redo för miljön. Om Coroid är anslutet till GitHub Actions eller GitLab CI/CD för miljön väljer en ägare eller administratör Driftsätt till… så startar Coroid pipelinen för just den committen. Annars driftsätter din pipeline automatiskt och rapporterar tillbaka. I båda fallen blir steget grönt först när driftsättningen har bekräftats som lyckad.

Hälsa. Efter en lyckad driftsättning 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ällningsalternativ erbjuds. Utan en canary förblir hälsostatusen okänd i stället för att antas vara frisk.

Vad statusarna betyder#

Redo betyder aldrig distribuerad. Endast en bekräftad distribution för en version vidare i utrullningen.

Arbetsflöden#

Konfigurera versioner för ett projekt#

Gör detta en gång per projekt. Öppna Versioner, välj Versionsinställningaroch välj projektet.

1. Under Miljöer, lägg till dina steg och ordna dem, till exempel Staging före Production.

2. Under Godkännanderegler, publicera regler för varje miljö: antal godkännanden, vilka roller som får godkänna och eventuella punkter på checklistan. En miljö kan inte klara kontrollerna förrän reglerna har publicerats.

3. Under Distributionspipeline, välj om Coroid startar distributioner eller om din pipeline gör det. Skapa sedan en rapporteringstoken så att din CI/CD kan tala om för Coroid vad den distribuerade.

4. Under Versionshantering, välj varifrån varje versions versionsnummer hämtas och ange en versions-URL för varje miljö så att Coroid kan bekräfta vad som körs där.

Versionsinställningar går igenom varje skärm, och Lägg in versionen i bygget visar hur versionen når din app.

Distribuera planerat arbete#

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

1. Skapa versionen i god tid, innan någon commit har valts. Den börjar som ett utkast.
2. Ange målversionen för de uppgifter du vill ha med. De visas under Planerade uppgifter, och förloppsindikatorn fylls i takt med att de blir klara.
3. När arbetet har mergats väljer du Redigera uppgifter och väljer vilken commit 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 för nästa.

Samla öppna pull requests#

Använd det här när många pull requests väntar, från Coroid eller ditt team, och de ska levereras tillsammans.

1. Välj Ny version, välj projektet och välj Öppna pull requests. Alternativet kräver ett GitHub- eller GitLab-repo, så projekt som hanteras av Coroid släpper i stället en commit.
2. Coroid listar öppna pull requests till deployment-branchen, med de säkraste först. En pull request som Coroid har öppnat visas som sin uppgift eller plan. Coroid väger in vad leverantören och den egna granskningen redan känner till: kontroller, granskningar, storlek, konflikter och filer som berörs av flera pull requests. Den utelämnar utkast, kontroller som misslyckats, ändringsbegäranden och pull requests från forks, och förklarar varför.
3. Avmarkera det som ska vänta och ändra ordningen med pilarna. En pull request som bygger vidare på en annan (en staplad pull request eller en som anger "depends on #12") kommer alltid efter den.
4. Välj Skapa version. Coroid skapar release/<version> från deployment-branchen, mergar pull requests i ordning och öppnar en release-pull request som listar och länkar till var och en av dem.
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 merga den och lösa konflikten i en uppgift, eller välj Utelämna den för att fortsätta utan den.
6. Granska release-pull requesten och merga den med en merge commit. Därefter markerar leverantören alla medföljande pull request som mergade. Coroid väljer merge-commiten som release-commit, registrerar de medföljande pull requests som det som levereras och stänger alla 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- och rebase-mergar fungerar också, men leverantören markerar inte de ursprungliga pull requests som mergade. Coroid stänger dem i stället med en kommentar.

Leverera det som finns på main-grenen#

Använd det här för kontinuerlig leverans, när du levererar allt som har mergats.

1. Välj Ny version och välj committen, vanligtvis den senaste på distributionsgrenen.
2. Under Jämför medväljer du miljön som ska ersättas. 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 versionen utifrån datumet och den korta commit-hashen, och projektets versionskälla fyller i versionen. Varje version får också nästa byggnummer.
4. Skapa versionen och gå igenom de fyra stegen.

Om din pipeline distribuerar vid varje merge utan att fråga Coroid, kan den ändå rapportera varje distribution. Om det inte finns någon version för en rapporterad commit skapar Coroid en observerad version som tydligt markeras som att den inte har klarat Coroid:s kontroller.

Leverera en akut rättning#

En Ägare eller Administratör kan aktivera Det här är en snabbkorrigering när en version skapas, välja korrigeringens fullständiga commit-hash 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 fel#

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 igen. Återställning och versionsflöden beskriver alternativen, även för pipelines som inte kan rapportera tillbaka.

Från chatt eller din editor#

Chattassistenten och MCP-servern för Coroid har samma versionsverktyg: lista och granska versioner, välja en commit, förhandsgranska vad som ska levereras, förbereda en version, samla öppna pull requests, köra kontroller, godkänna, begära en distribution och skapa utkast till versionsinformation. Att samla, godkänna och distribuera kräver alltid bekräftelse från en person. Se Chattassistent och Coroid som MCP-server.

Släpp flera projekt tillsammans#

Ett versionsflöde samlar versioner från flera projekt som måste levereras tillsammans, i en viss ordning, till exempel ett API och appen som är beroende av det. Se Återställning och versionsflöden.

Vad Coroid gör och inte gör#

• Coroid väljer commits, kontrollerar och registrerar. Ditt repo och CI/CD bygger och distribuerar.
• När Coroid samlar pull requests skapar det release-branchen och release-pull requesten. Det mergar aldrig release-pull requesten åt dig.
• Coroid startar en pipeline endast när du ansluter en och en ägare eller administratör begär en driftsättning.
• En begäran om driftsättning är inget bevis. Driftsättningsspåret går vidare först när din pipeline bekräftar att driftsättningen lyckades eller någon registrerar en verifierad extern driftsättning.
• Versionsinformation är utkast som du redigerar och godkänner. Coroid publicerar den inte någonstans.
• En sprint är en planeringsperiod, inte en gräns för driftsättning. En sprint kan ligga till grund för flera versioner, och en version kan innehålla arbete från flera sprintar.

Relaterat#

• Versionsinställningar
• Distributioner och CI-konfiguration
• Lägg till versionen i bygget
• Återställning och versionsflöden
• Sprintar
• Uppgifter, planer, sprintar och banor
• Underlag för kvalitet och granskning