Driftsättningsmiljöer

Miljöer är namngivna mål för driftsättning (t.ex. staging, production, eu-west) med kombinerbara säkerhetsgrindar. Ett jobb i ett arbetsflöde som deklarerar environment: production prövas mot ALLA konfigurerade grindar innan fremforge provisionerar runnerns VM. Om någon grind fallerar nekas driftsättningen med en strukturerad orsak. Organisationens administratörer hanterar det i administrationsgränssnittet, och arbetsflödet kan köras om när det underliggande villkoret är uppfyllt.

Snabbstart

1. Gå till Organisationens administration → Miljöer (https://frem.sh/<org>/_admin/environments).

2. Under Ny miljö anger du ett namn och klickar på Skapa.

3. Öppna den nya miljöns detaljsida, scrolla till Driftsättningspolicyer, konfigurera de policyer du vill ha och klicka på Spara policyer.

4. Hänvisa till miljön i valfritt jobb i ett arbetsflöde:

   jobs:
     deploy:
       runs-on: fremforge
       environment: production
       steps:
         - run: ./deploy.sh

Nästa driftsättning som riktar sig mot miljön prövas mot dina grindar.

De 9 grindarna

Alla grindar är oberoende av varandra och kan kombineras. ALLA konfigurerade grindar måste godkänna för att en driftsättning ska gå vidare. En grind utan konfiguration hoppas över (räknas som godkänd).

A. Krav på godkännare

Håll tillbaka starten tills N personer har klickat på Godkänn för den väntande driftsättningen.

• När den ska användas: driftsättningar till produktion, reglerade miljöer, allt där ett extra par ögon är skyddsnätet.
• Konfigurera: Required reviewers på miljöns detaljsida. 0 = inget godkännande; 1–6 = N godkännare krävs.
• Var du godkänner: Organisationens administration → Driftsättningar (/<org>/_admin/deployments), avsnittet Väntande godkännanden.
• Obs: den användare som utlöste arbetsflödet (den som pushade committen eller öppnade pull requesten) kan inte godkänna sin egen driftsättning. Plattformen avvisar egengodkännande både i routningslagret och i utvärderingen.
• Återkalla: godkännare kan återkalla sitt eget godkännande innan driftsättningen startar (t.ex. om du upptäcker ett problem efter att ha klickat på Godkänn). När driftsättningen väl har startat går godkännandet inte att ändra.

B. Tillåtna refs (mönster för branches och taggar)

Begränsa vilka git-refs som får driftsättas till miljön.

• När den ska användas: ”bara main driftsätts till produktion”; ”bara taggar release/* driftsätts till canary”.
• Konfigurera: Branches och taggar för driftsättning på miljöns detaljsida. Globmönster i GitHub-stil: main, release/*, **/hotfix-*, refs/tags/v[0-9]+.*. Tomt = alla refs tillåts.

C. Tidsfönster

Begränsa driftsättningar till vissa kontorstider eller blockera dem under frysperioder.

• När den ska användas: ”driftsättning bara mån–tors 09:00–17:00 CET”; ”blockera alla driftsättningar 22 dec – 2 jan (helgfrysning)”.

• Konfigurera: Time-window JSON på miljöns detaljsida. Format:

  {
    "tz": "Europe/Copenhagen",
    "allowed": [
      { "days": ["Mon", "Tue", "Wed", "Thu"], "from": "09:00", "to": "17:00" }
    ],
    "blackouts": [
      { "from": "2026-12-22T00:00Z", "to": "2027-01-02T00:00Z", "reason": "holiday freeze" }
    ]
  }
  • tz: tidszon enligt IANA. Standard är UTC.
  • allowed: lista över tillåtna fönster. Dagar anges med tre bokstäver (Mon..Sun). Tider anges i 24-timmarsformat HH:MM i tz.
  • blackouts: lista över absoluta UTC-intervall då driftsättning är förbjuden oavsett allowed.

• Obs: blackouts går före allowed. Tomt = ingen tidsbegränsning.

D. SLO-budgeten är frisk

Neka driftsättningar medan SLO-felbudgeten förbrukas.

• När den ska användas: ”driftsätt inte medan kundnära latens eller felfrekvens är rödmarkerad – åtgärda regressionen först.”
• Konfigurera: Block when these alarms are firing – kommaseparerade namn på CES/LTS-larm som dina burn-rate-övervakare underhåller. Exempel: my-api-latency-sev1, my-api-error-budget-sev2.
• Så fungerar det: fremforge följer det senaste tillståndet för varje listat larm. När något av de listade larmen har tillståndet firing nekar grinden start.
• Stängd vid fel: om fremforge inte har något aktuellt tillstånd för ett listat larm stänger grinden – hellre en undersökning än en tyst förbikoppling.

E. Krav på statuskontroller

Kräv att namngivna commit-statuskontexter i Forgejo har värdet success på den commit som driftsätts.

• När den ska användas: ”driftsättningar måste vänta tills dep-scan, SAST och image-scan alla är godkända på den här committen.”
• Konfigurera: Required check contexts – en per rad. Exempel: dep-scan, sast, sha-pin-scan, image-scan-trivy.
• Så fungerar det: fremforge läser GET /api/v1/repos/<o>/<r>/statuses/<sha> vid förkontrollen. Varje krävd kontext måste rapportera tillståndet success. Saknade tillstånd och tillstånd som inte är success får grinden att fallera.

F. Samtidighetslås

Sätt ett tak för antalet pågående driftsättningar till miljön.

• När den ska användas: ”bara en driftsättning till produktion åt gången” – förhindrar kapplöpningar där två driftsättningar skriver över varandra.
• Konfigurera: Max in-flight deploys – heltal 0–100. 0 = inget tak.
• Räknas: tillstånden pending_gates, pending_approval och dispatched. Ett försök med completed eller failed räknas inte längre.

G. Karenstid efter en nyligen gjord rollback

Efter en rollback blockeras driftsättningar i N minuter så att teamet kan undersöka.

• När den ska användas: ”efter en rollback, tvinga fram 60 minuters paus innan nästa driftsättning” – förhindrar att samma regression av misstag utlöses igen.
• Konfigurera: Cooldown after rollback (minutes) – heltal 0–1440 (24 h). 0 = ingen karenstid.

H. Krav på länkat ärende

Kräv att texten i pull requesten som driftsätts hänvisar till ett ärende eller en incident.

• När den ska användas: krav på efterlevnad eller verifieringskedja – varje driftsättning till produktion måste ha ett ”varför” kopplat till sig.
• Konfigurera: markera Require PR body to reference an issue/incident ticket. Valfritt: åsidosätt med ett eget reguljärt uttryck i Ticket pattern.
• Standardmönster: (?i)(JIRA|FF|INC|FIX)-[0-9]+|fixes? #[0-9]+|closes? #[0-9]+|resolves? #[0-9]+ – matchar JIRA-1234, FF-99, fixes #42, Closes #99 osv. Prefixet (?i) gör det skiftlägesokänsligt.
• Åsidosättning per organisation: valfritt giltigt reguljärt uttryck i JavaScript. Prefixet (?i) respekteras.

I. Pausflagga

En brytare per miljö som stoppar alla driftsättningar.

• När den ska användas: under en incident. Sätt en paus, undersök, ta bort den.
• Konfigurera: Per miljö (organisationens administration): <org>/_admin/deployments → avsnittet Pausflaggor. fremforge kan också lägga en plattformsövergripande paus under en incident; varje aktiv paus som omfattar din miljö blockerar driftsättningen.
• Upplösning: den mest specifika nivån avgör vilken orsak som visas, men VARJE aktiv nivå blockerar driftsättningen.

Så går en utvärdering till

När plattformen plockar upp ett arbetsflöde med environment: <name>:

1. Förkontroll – fremforge slår upp miljön för organisationen. Ingen miljö konfigurerad = inga grindar gäller (gradvis införande; nya kunders arbetsflöden blockeras inte innan de har konfigurerat miljöer).
2. Skapa eller hitta ett driftsättningsförsök med nyckeln (env, ref, commit_sha). Nya starter av samma arbetsflöde mot samma commit delar samma försök – så ett godkännandeflöde gäller över omförsök.
3. Hämta underlag – aktörens mejladress och texten i pull requesten läses från Forgejo. Bästa möjliga försök; om Forgejo fungerar sämre används syntetiska reservvärden.
4. Utvärdera alla 9 grindar parallellt – varje grind är oberoende och läser sin egen signal.
5. Sammanställ – om ALLA konfigurerade grindar godkänner byter tillståndet till dispatched och runnerns VM provisioneras. Om ENDAST grind A (godkännare) fallerar byter tillståndet till pending_approval – administratörer kan klicka på Godkänn, och nästa omförsök utvärderar på nytt. Om någon annan grind fallerar byter tillståndet till gates_failed.
6. Granskning – hela uppdelningen av grindresultaten sparas och en granskningshändelse skickas.

Så ser en nekad driftsättning ut

Kunden ser: körningen av arbetsflödet avbruten, med en commit-statuskontroll som visar orsaken (t.ex. deploy_gate_C_time_window — outside allowed windows).

Organisationens administratör ser: en rad under Pending deployments med hela utvärderingen – vilka grindar som godkände och vilka som fallerade, med den specifika reason-strängen per grind.

Vad som körs i varje miljö

Organisationens administration → Driftsättningar (https://frem.sh/<org>/_admin/deployments) börjar med Live per miljö. För varje miljö visas driftsättningen som körs nu och den före den, som är ditt mål för en återställning:

• repository, ref (branch eller tagg) och commit, länkad;
• taggarna som pekar på committen, till exempel prd-2026-11-01 eller rc-81;
• vem som godkände den, och när;
• när driftsättningen slutfördes, och en länk till dess workflow-körning.

En driftsättning räknas bara som live när körningen startades och slutfördes utan fel. Misslyckade, avbrutna, nekade och väntande försök räknas aldrig, så efter en misslyckad driftsättning visas den föregående fortfarande som live. En miljö utan någon slutförd driftsättning visar Aldrig driftsatt.

Release-verktyg kan läsa samma data från API:t med en token som har deployments:read, utan att läsa av sidan:

curl -fsS "https://frem.sh/_app/api/v1/orgs/acme/deployments/live?environment=production" \
  -H "Authorization: Bearer $FREMFORGE_TOKEN"

Varje miljö i svaret har live och previous, och båda är null tills något har driftsatts där. Var och en har repo_full_name, ref, commit_sha, commit_url, tags, approvals, deployed_at, run_number och run_url. Utelämna ?environment= för att få alla miljöer. tags läses från repositoryts 150 nyaste taggar och kan vara upp till en minut gamla. Fältet är null (inte []) när taggarna inte kunde läsas just då.

Kombinera grindar

Stegen är medvetet kombinerbara – de flesta kunder konfigurerar 2–3 grindar per miljö, inte alla 9. Förslag på utgångspunkter:

Börja smått – lägg till grindar när du växer.

Secrets och variabler per miljö

Oberoende av grindarna har miljöer egna secrets och variabler som bara skickas in i jobb som deklarerar environment: <name>. Se Secrets för hur secrets hanteras.

Hantera miljöer via API:t

Allt som administrationsgränssnittet gör kan REST-API:t också göra. Miljöer ligger i namnrymden fremforge-extension, så bas-URL:en är https://frem.sh/_app/api/v1 – inte den bara /api/v1, som är Forgejos eget API och avvisar anropet.

Miljönamn matchar [A-Za-z0-9_.-]+ (inget /). Variabelnamn matchar [A-Z][A-Z0-9_]*, med värden på upp till 64 KiB. Värden för secrets krypteras i vila och returneras aldrig – list-endpoints ger bara namn och metadata.

# Create an environment, then give it a variable and a secret.
curl -fsS -X POST https://frem.sh/_app/api/v1/orgs/acme/environments \
  -H "Authorization: Bearer $FREMFORGE_TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{"name":"staging"}'

curl -fsS -X PUT https://frem.sh/_app/api/v1/orgs/acme/environments/staging/variables/REGION \
  -H "Authorization: Bearer $FREMFORGE_TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{"value":"eu-de"}'

curl -fsS -X PUT https://frem.sh/_app/api/v1/orgs/acme/environments/staging/secrets/DEPLOY_KEY \
  -H "Authorization: Bearer $FREMFORGE_TOKEN" \
  -H 'Content-Type: application/json' \
  -d '{"value":"…"}'

Om du får 403

403 Token lacks required scope 'environments:…' betyder att endpointen finns men att din token saknar scopet – det är ingen funktion som saknas. Kontrollera vilka scopes dina inloggningsuppgifter faktiskt har. En PAT som du själv har skapat har exakt de scopes du kryssade i; en utvecklings-bench har en uppsättning som plattformen har skapat, som medvetet är snävare och förnyas när benchen vaknar.

OIDC-claim för miljön

Arbetsflöden som deklarerar environment: <name> får ytterligare ett OIDC-claim – sub blir repo:<owner>/<repo>:environment:<name>. Det är detta som förtroendepolicyer i molnet matchar mot vid kortlivad federation (AWS STS AssumeRoleWithWebIdentity, Azure WIF, GCP Workload Identity Federation). Se OIDC-federation för hur förtroendepolicyerna ser ut.

Felsökning

Arbetsflödet har fastnat på ”Review pending” och ingen avisering skickades. → Kontrollera antalet i miljöns Required reviewers. Godkännanden görs på administrationssidan Pending deployments; fremforge mejlar inte granskarna (ännu). Lägg till sidan i teamets morgonmöte.

En driftsättning nekades med deploy_gate_D_slo_burn, men jag har inte konfigurerat grind D. → Grind D stänger när fremforge inte har något aktuellt tillstånd för ett listat larm. Om du har LISTAT ett larmnamn som aldrig har rapporterat något tillstånd nekar grinden automatiskt. Ta bort larmnamnet ur grindens konfiguration, eller se till att larmet är kopplat så att dess tillstånd rapporteras.

Texten i pull requesten matchar ett ärendemönster men grind H fallerar ändå. → Driftsättningsförsöket skapades INNAN pull requesten öppnades. fremforge sparar texten i pull requesten vid första utvärderingen och hämtar den inte igen. Pusha en tom commit för att utlösa en ny utvärdering.

Jag vill tillfälligt kringgå grindarna. → Det finns ännu inget gränssnitt för förbikoppling per organisation. Kontakta support@frem.sh för att tillfälligt kringgå en grind. Pausflaggornas nivåer är bara av/på-reglage.

Granskningshändelser

Varje beslut i en grind skickar strukturerade granskningshändelser: