Inställningar för versioner gäller per projekt. Öppna Versioner, välj Inställningar för versioneroch välj projekt. Det finns fyra vyer, och var och en besvarar en fråga.
- Miljöer
- Vilka miljöer ska en release passera? Lägg till stopp och ordna dem.
- Godkännanderegler
- Vad måste vara klart först? Godkännanden, roller, checklista och regler för snabbfixar för varje miljö.
- Driftsättningspipeline
- Vem driftsätter, och hur får CoRoid besked? Din pipeline eller CoRoid startar driftsättningen. En rapporteringstoken gör att CI/CD kan bekräfta resultatet.
- Versionshantering
- Vilken version är det här? Var versionerna kommer ifrån, vad bygget får och var CoRoid kontrollerar vad som körs.
Endast ägare och administratörer kan ändra inställningarna för versioner. Alla andra kan läsa dem. Anslut ett repository först, eftersom varje version hänvisar till en commit i det.
Miljöer
Vart går en version och i vilken ordning?
Varje projekt börjar med Production. Lägg till de andra miljöer du driftsätter till, till exempel
Staging eller QA, med Lägg till en miljö. Ge varje enhet ett namn. CoRoid
föreslår en nyckel utifrån namnet, till exempel staging. Ditt CI/CD använder den nyckeln
när det rapporterar en driftsättning, så ändra den inte när pipelines väl använder den.
Ange ordningen med Kommer efter. Om Staging inte kommer efter någon miljö och Production kommer efter Staging blir flödet Staging › Production. Versionssidan visar utrullningsordningen så här, och godkännanderegler kan kräva att den föregående miljön har lyckats först.
Godkännanderegler
Vad måste vara uppfyllt innan en version driftsätts här?
Välj miljö högst upp. Reglerna gäller per miljö, så Staging kan ha enklare regler och Production striktare.
- Godkännanden som krävs: hur många olika personer som måste godkänna. Noll innebär att en version kan driftsättas så snart kontrollerna har godkänts.
- Vem kan godkänna: vilka organisationsroller som får godkänna.
- Håll beställaren åtskild från godkännarna: personen som startar dräiftsättningen kan inte också godkänna den, och den som redigerar versionsanteckningarna kan inte godkänna dem.
- Kvalitetskontroller godkända: alltid aktiverat. Projektets Quality Graph med en
release_validation-trigger körs mot den exakta committen. Publicera grafen från projektets kvalitetsinställningar. - Föregående miljö först: versionen måste redan vara driftsatt till miljön som den här kommer efter.
- Godkända versionsanteckningar: de aktuella anteckningarna måste godkännas, och varje senare redigering kräver ett nytt godkännande.
- Checklista: manuella steg som någon bekräftar på versionssidan, till exempel "Databasmigrering granskad". Markera ett objekt som obligatoriskt eller valfritt. För ett obligatoriskt objekt kan ett tillfälligt undantag beviljas. En ägare eller administratör anger ett skäl och en giltighetstid på upp till 24 timmar. Undantaget gäller bara den committen och miljön.
- Hotfixregler: enklare regler för brådskande korrigeringar: antal godkännanden och om den föregående miljön och godkännande av anteckningar fortfarande krävs. Kvalitetskontroller och obligatoriska checklistepunkter gäller alltid, och endast ägare och administratörer får godkänna hotfixar.
Välj Publicera regler för att spara. När du publicerar skapas en ny version av reglerna. Godkännanden enligt den gamla versionen blir inaktuella, så en version som redan är på gång kräver ett nytt godkännande. En miljö utan publicerade regler kan inte klara kontrollerna, och det visas på sidan.
Driftsättningspipeline
Vem startar en driftsättning och hur får CoRoid reda på vad som hände?
Välj miljö högst upp och välj sedan hur driftsättningar startar:
- Min pipeline driftsätter automatiskt: behåll din nuvarande process. CoRoid registrerar driftsättningar när din CI/CD rapporterar dem, eller när en Ägare eller Administratör registrerar en extern driftsättning på versionssidan.
- CoRoid startar ett GitHub Actions-arbetsflöde eller CoRoid startar en GitLab CI/CD-pipeline: visas när projektets repo finns hos den leverantören. Ange grenen eller taggen som pekar på versionscommiten, arbetsflödesfilen för GitHub och det exakta namnet på jobbet som driftsätter. CoRoid kontrollerar referensen innan körningen startar och kontrollerar det angivna jobbet innan ett lyckat resultat godkänns.
Under Driftsättningsrapporter, skapa en rapporteringstoken för miljön och spara den som en hemlighet i din CI/CD. CoRoid visar tokenen en gång och sparar bara en hash av den. Om du byter token slutar den gamla att fungera direkt. På samma skärm visas slutpunkten, projekt-ID:t och miljönyckeln som din pipeline behöver, samt om rapporter kommer in. Driftsättningshändelser och CI-konfiguration innehåller händelseformatet och exempel.
Versionshantering
Vilken version är det här och hur får bygget versionsnumret?
Välj varifrån varje versions versionsnummer hämtas: CoRoid föreslår nästa nummer, CoRoid läser det från en fil i repot eller så rapporterar din pipeline det. Varje version får också ett löpnummer som bara ökar. På skärmen visas värdena som CoRoid skickar till din pipeline. Därifrån kan du öppna Nytt arbete med en förfrågan om att lägga till dem i bygget och ange en versions-URL per miljö, så att CoRoid kan bekräfta vilken version som körs i varje miljö. Lägg till versionsnumret i bygget innehåller detaljer och recept för webb-, server-, Docker-, iOS- och Android-byggen.
Flytta inställningar mellan organisationer
Export och import av inställningar omfattar miljöer, deras ordning, pipeline- konfiguration, versionshantering, versions-URL:er och publicerade regler, inklusive hotfixregler. Rapporteringstoken och byggnummer exporteras aldrig. Skapa nya token efter importen; varje projekt behåller sina egna byggnummer.