Dokumentation

Versionsinställningar

Ställ in miljöerna som en version passerar, reglerna för varje miljö och hur driftsättningar startas och rapporteras.

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.
Releaser → Releaseinställningar: välj ett projekt och gå sedan igenom fyra skärmbilder med en fråga på varje.

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 miljö 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 veta 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 ditt 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 repository finns hos den leverantören. Ange branchen eller taggen som pekar på versionens commit, 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 resultatet godkänns.

Under Driftsättningsrapporterskapar du en rapporteringstoken för miljön och lagrar den som en hemlighet i ditt CI/CD. Coroid visar tokenen en gång och sparar bara en hash av den. Om du ersätter tokenen slutar den gamla att fungera direkt. Samma vy visar slutpunkten, projekt-ID:t och miljönyckeln som din pipeline behöver, samt om rapporter kommer fram. 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 var varje versions versionsnummer hämtas ifrån: Coroid föreslår nästa nummer, Coroid läser det från en fil i repositoryt eller så rapporterar din pipeline det. Varje version får också ett byggnummer som bara ökar. Vyn listar värdena som Coroid skickar till din pipeline, kan öppna Nytt arbete med en förfrågan om att lägga till dem i ditt bygge och tar emot en versions-URL per miljö så att Coroid kan bekräfta vilken version som körs i respektive 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.