Behöver ert företag hjälp med att implementera AI? Kontakta oss och få prisoffert här →
AI Skolan
January 22, 2026

Azure DevOps + GitHub för strukturerad ärendehantering

Rickard Andersson Partner, Nodenordic.se

Du skapar en Story i Azure DevOps, och sedan öppnar någon en ”matchande” GitHub Issue… kanske. Några dagar senare dyker Tasks upp utan länk tillbaka, ägarskapet är otydligt och din statusrapport förvandlas till detektivarbete.

Det här slår hårdast mot projektledare, men team leads och utvecklare känner av det också. DevOps GitHub sync ska inte bygga på minnet, skärmdumpar och ”uppdaterade du issuet?”-meddelanden.

Det här arbetsflödet speglar Azure DevOps Stories till GitHub Issues och spårar kopplingen i Google Sheets så att Tasks aldrig tappar sin parent. Du får se hur det fungerar, vad du behöver och var team oftast snubblar.

Så fungerar den här automatiseringen

Hela n8n-flödet, från trigger till slutresultat:

n8n Workflow Template: Azure DevOps + GitHub för strukturerad ärendehantering

Problemet: Stories och Tasks tappar spårbarhet mellan verktyg

När arbetet ligger i Azure DevOps men samarbetet sker i GitHub får du två ”single source of truth” – och ingen av dem är pålitlig. En Story skapas, någon glömmer att spegla den och nu saknas kontext på GitHub-sidan. Sedan börjar Tasks staplas under den Storyn, men personerna som lever i GitHub ser dem aldrig. Även om teamet försöker vara disciplinerat faller manuell synk sönder så fort sprinten blir intensiv. Och kostnaden smyger sig på: statusuppdateringar tar längre tid, överlämningar blir stökigare och buggar slinker igenom eftersom ingen kan följa tråden.

Det eskalerar snabbt. Här är var det brukar gå fel.

  • Du lägger cirka 10 minuter per Story på att kopiera detaljer till en GitHub Issue, och gör sedan om det igen när Storyn ändras.
  • Tasks skapas i Azure DevOps och syns aldrig där teamet faktiskt diskuterar arbetet (GitHub), vilket gör att blockers blir osynliga.
  • Länkar mellan objekt försvinner, så ingen kan svara på ”vilket Issue matchar den här Storyn?” utan att gräva.
  • Rapportering blir spreadsheet-arkeologi eftersom det saknas konsekvent ID-mappning mellan verktygen.

Lösningen: spegla DevOps work items till GitHub och logga mappningen

Det här n8n-flödet lyssnar på Azure DevOps-händelser (Stories och Tasks) via webhooks och håller sedan GitHub och Google Sheets synkade automatiskt. När en Story skapas eller uppdateras i Azure DevOps rensar arbetsflödet payloaden (så att du inte får stökiga fält), skapar en GitHub Issue i rätt repo och hämtar listan över repo-collaborators. Därefter tilldelar det Issuet till en slumpmässigt vald collaborator (du kan ändra logiken) och skriver mappningen till Google Sheets: DevOps Story-ID, GitHub Issue-nummer och Issue-URL. Senare, när en Task skapas under den Storyn, slår flödet upp parent-Storyn i Google Sheets, hämtar motsvarande GitHub Issue och uppdaterar Issue-texten med en klickbar länk till Tasken så att GitHub-tråden förblir komplett.

Arbetsflödet startar med två Azure DevOps-webhooks: en för Story create/update och en för Task create. Därefter använder det GitHub och HTTP-förfrågningar för att skapa och tilldela Issues, medan Google Sheets fungerar som referenslager som gör parent/child-länkning pålitlig.

Det du får: automatisering vs. resultat

Exempel: så här ser det ut

Säg att ditt team skapar 15 Stories i veckan och att varje Story vanligtvis behöver en matchande GitHub Issue. Om manuell spegling tar cirka 10 minuter per Story är det ungefär 2,5 timmar i veckan bara på kopiering och länkning. Lägg till 30 Tasks i veckan, och även 2 minuter per Task för att hitta parent och klistra in en länk bränner ytterligare en timme. Med det här arbetsflödet är ”arbetet” i princip noll: triggern sker direkt och uppdateringarna körs i bakgrunden efter att webhooken har triggat. Du får tillbaka de där timmarna, och länkarna förblir konsekventa även när sprinten blir kaotisk.

Det här behöver du

  • n8n-instans (prova n8n Cloud gratis)
  • Självhosting om du föredrar det (Hostinger fungerar bra)
  • Azure DevOps för att skicka service hook-webhooks för Story/Task
  • GitHub för att skapa och uppdatera Issues i ett repository
  • Google Sheets för att lagra DevOps↔GitHub-mappningstabellen

Kunskapsnivå: Medel. Du klistrar in webhook-URL:er i Azure DevOps service hooks och kopplar konton i n8n.

Vill du inte sätta upp det här själv? Prata med en automationsexpert (gratis 15-minuters konsultation).

Så fungerar det

Azure DevOps triggar arbetsflödet. En service hook triggar när en Story skapas eller uppdateras, och en separat triggar när en Task skapas. Den uppdelningen är viktig eftersom Tasks behöver en parent-uppslagning.

Story-payloaden rensas. Arbetsflödet normaliserar inkommande fält (titlar, beskrivningar, ID:n) så att GitHub Issue-innehållet blir läsbart och konsekvent i stället för en rå dump.

GitHub får Issuet och en ägare. n8n skapar Issuet i ditt valda repo, hämtar collaborators via HTTP-förfrågan och sätter sedan en assignee baserat på logiken ”slumpmässig collaborator”.

Google Sheets blir uppslagslagret. Arbetsflödet skriver mappningen efter att Issuet skapats, och använder senare arket för att hitta rätt Issue när en Task dyker upp, och uppdaterar sedan Issue-texten med en klickbar Task-länk.

Du kan enkelt ändra tilldelningslogiken för att använda labels eller arbetsbelastning i stället för slumpmässigt urval. Se hela implementationsguiden nedan för anpassningsalternativ.

Steg-för-steg-guide för implementering

Steg 1: konfigurera webhook-triggern

Konfigurera de två inkommande Azure DevOps-webhooks som startar arbetsflödet för Stories och Tasks.

  1. Öppna Incoming Story Hook och ställ in HTTP MethodPOST.
  2. Ställ in Path3006842c-5f13-4147-8d78-9ee73ac78e34.
  3. Öppna Incoming Task Hook och ställ in HTTP MethodPOST.
  4. Ställ in Pathcfecf4f6-b82d-4dd0-af5b-bd231130b272.
  5. I Azure DevOps skapar ni två service hooks som POST:ar till respektive webhook-URL.

Tips: Håll de två webhook-URL:erna separata i Azure DevOps (en för Story-händelser och en för Task-händelser) så att den nedströms mappningen fungerar korrekt.

Steg 2: anslut GitHub och Google Sheets

Anslut autentiseringsuppgifterna som används för GitHub-anropen och mappningskalkylbladet.

  1. I Generate GitHub Issue väljer ni Authentication som oAuth2 och väljer ert repo i Repository.
  2. Inloggningsuppgifter krävs: Anslut era githubOAuth2Api-uppgifter i Generate GitHub Issue.
  3. Inloggningsuppgifter krävs: Anslut era githubOAuth2Api-uppgifter i Fetch Repo Collaborators, Apply Issue Assignee, Retrieve Issue Details och Update Issue Body.
  4. Inloggningsuppgifter krävs: Anslut era googleSheetsOAuth2Api-uppgifter i Append Issue Mapping och Lookup Story Mapping.
  5. I Append Issue Mapping och Lookup Story Mapping ställer ni in Document till ert ark och Sheet till IssuesMap.

⚠️ Vanlig fallgrop: Om Google Sheet saknar kolumnerna AzureID, IssueID och Url kommer mappningen och task-uppdateringarna att misslyckas.

Steg 3: konfigurera bearbetning av payload

Rensa Azure DevOps webhook-payloads och förbered val av GitHub-tilldelad person.

  1. I Cleanse Story Payload behåller ni standardinställningen för Mode som runOnceForEachItem och klistrar in den tillhandahållna JavaScript-koden för att extrahera story-fält.
  2. I Cleanse Task Payload behåller ni standardinställningen för Mode som runOnceForEachItem och klistrar in den tillhandahållna JavaScript-koden för att extrahera task-fält inklusive parent och ticketUrl.
  3. I Select Random Assignee behåller ni JavaScript-koden som väljer en slumpmässig collaborator och returnerar assignee.
  4. Verifiera flödet: Incoming Story HookCleanse Story PayloadGenerate GitHub Issue, och Incoming Task HookCleanse Task PayloadLookup Story Mapping.

Steg 4: konfigurera skapande och tilldelning av GitHub issue

Skapa GitHub issue för en Story och tilldela en slumpmässig collaborator.

  1. I Generate GitHub Issue ställer ni in Title till ={{ $json.title }} och Body till ={{ $json.description }}.
  2. Ställ in Owner och Repository till mål-repot i GitHub.
  3. I Fetch Repo Collaborators ställer ni in URL till ={{ $json.repository_url }}/collaborators.
  4. I Apply Issue Assignee ställer ni in URL till ={{ $('Generate GitHub Issue').first().json.url }} och Method till PATCH.
  5. Ställ in JSON Body till { "assignees": ["{{ $json.assignee }}"] } och aktivera Send Body.

Tips: Ordningen är kritisk — Generate GitHub Issue måste köras före Fetch Repo Collaborators och Apply Issue Assignee för att säkerställa att issue-URL:en finns.

Steg 5: konfigurera issue-mappning och task-uppdateringar

Lagra mappningen mellan Azure Story och GitHub Issue och uppdatera issue-beskrivningar när tasks skapas.

  1. I Append Issue Mapping ställer ni in Operation till append och mappar kolumnerna: Url, AzureID och IssueID.
  2. Säkerställ att mappningarna använder uttryck: ={{ $json.url }}, ={{ $('Cleanse Story Payload').first().json.id }} och ={{ $('Generate GitHub Issue').first().json.number }}.
  3. I Lookup Story Mapping ställer ni in filtret till att slå upp AzureID med ={{ $json.parent }}.
  4. I Retrieve Issue Details ställer ni in Issue Number till ={{ $json.IssueID }}.
  5. I Update Issue Body ställer ni in Operation till edit och Issue Number till ={{ $('Lookup Story Mapping').first().json.IssueID }}.
  6. Ställ in Body till det tillhandahållna HTML-listformatet som infogar {{ $('Cleanse Task Payload').first().json.ticketUrl }}, {{ $('Lookup Story Mapping').first().json.AzureID }} och {{ $('Cleanse Task Payload').first().json.title }}.

⚠️ Vanlig fallgrop: Om fältet parent från Cleanse Task Payload inte matchar ett AzureID i ert ark kommer Lookup Story Mapping inte att returnera några rader och issue-texten uppdateras inte.

Steg 6: testa och aktivera ert arbetsflöde

Verifiera båda vägarna (skapande av Story och uppdateringar av Task) innan ni slår på arbetsflödet.

  1. Använd test-URL:en för Incoming Story Hook för att skicka en exempel-payload för Story och kör arbetsflödet manuellt.
  2. Bekräfta att en GitHub issue skapas, att en collaborator tilldelas och att Append Issue Mapping lägger till en ny rad i IssuesMap.
  3. Använd test-URL:en för Incoming Task Hook för att skicka en Task-payload med ett giltigt Azure-ID i parent.
  4. Bekräfta att Update Issue Body lägger till task-länken i den befintliga GitHub issue:n.
  5. När allt fungerar växlar ni arbetsflödet till Active för att aktivera automationskörning i produktion.
🔒

Lås upp fullständig steg-för-steg-guide

Få den kompletta implementeringsguiden + nedladdningsbar mall

Vanliga fallgropar

  • Azure DevOps service hooks kan råka peka på fel event-typ. Om Issues inte skapas, kontrollera Projektinställningar → Service hooks först.
  • Om du använder Wait-noder eller extern rendering varierar processtiderna. Öka väntetiden om efterföljande noder fallerar på tomma svar.
  • GitHub-behörigheter spelar större roll än många tror. Om tilldelningen misslyckas, verifiera att din token/OAuth-app kan läsa collaborators och redigera issues i det repot.

Vanliga frågor

Hur lång tid tar det att sätta upp den här DevOps GitHub sync-automatiseringen?

Cirka en timme om dina Azure DevOps service hooks och konton är redo.

Behöver jag kunna koda för att automatisera DevOps GitHub sync?

Nej. Du kopplar Azure DevOps, GitHub och Google Sheets och klistrar sedan in webhook-URL:er i Azure DevOps.

Är n8n gratis att använda för det här DevOps GitHub sync-arbetsflödet?

Ja. n8n har ett gratis alternativ för självhosting och en gratis provperiod på n8n Cloud. Cloud-planer börjar på 20 USD/månad för högre volym.

Var kan jag hosta n8n för att köra den här automatiseringen?

Två alternativ: n8n Cloud (hanterat, enklast att komma igång) eller självhosting på en VPS. För självhosting är Hostinger VPS prisvärt och hanterar n8n bra. Självhosting ger obegränsade körningar men kräver grundläggande serverhantering.

Kan jag anpassa det här DevOps GitHub sync-flödet för teambaserad tilldelning i stället för slumpmässig?

Ja, och det är en vanlig justering. Ersätt koden för ”Select Random Assignee” med regler som ”tilldela efter label”, ”tilldela efter komponent” eller ”tilldela till jour-användarnamnet”. Du kan också hoppa över tilldelning helt och bara sätta en label i GitHub så att triage sker i din vanliga process.

Varför misslyckas min GitHub-anslutning i det här arbetsflödet?

Oftast är det ett token- eller OAuth-scope-problem. Säkerställ att din GitHub-credential kan läsa repository collaborators och har behörighet att skapa och redigera issues. Om repot ligger i en organisation, kontrollera att SSO-godkännande är aktiverat för token – annars kan anrop ”fungera” i tester men fallera vid riktiga körningar.

Hur många work items klarar den här DevOps GitHub sync-automatiseringen?

Ett typiskt mindre team kan köra hundratals Story/Task-händelser per vecka utan att behöva tänka på det.

Är den här DevOps GitHub sync-automatiseringen bättre än att använda Zapier eller Make?

Ofta, ja – eftersom det här inte bara är ett tvåstegsflöde som ”kopierar en post”. Du hanterar två webhook-triggers (Stories och Tasks), slår upp en parent-mappning i Sheets, uppdaterar sedan en befintlig GitHub Issue och har dessutom egen tilldelningslogik. n8n är helt enkelt bekvämare med den typen av förgreningar och datashaping, och självhosting gör att du inte betalar per liten delsteg när volymen ökar. Zapier eller Make kan fortfarande fungera om behoven är enklare, men många team når gränser när de försöker hålla Tasks korrekt länkade. Prata med en automationsexpert om du vill ha hjälp att välja.

När det här väl rullar slutar Stories och Tasks att falla mellan stolarna. Arbetsflödet håller länkar, ägarskap och rapportering i ordning så att du kan fokusera på att leverera – i stället för att jaga information.

Kontakta oss

Hör av dig, så diskuterar vi hur just din verksamhet kan dra nytta av alla fantastiska möjligheter som AI skapar.

×

Använd mall

Få direkt tillgång till denna n8n-arbetsflödes JSON-fil

Launch login modal Launch register modal