Pull requests ska vara enkla att granska. I stället försvinner de mellan Azure DevOps-notiser, stökiga gruppchattar och “såg du min PR?”-påminnelser som drar alla ur flow.
Utvecklingschefer märker det när granskningsköerna stannar. Team leads ser det när fel personer blir pingade. Och om du driver ett litet produktteam vet du att automatiserade PR-notiser är skillnaden mellan stabil leverans och att ständigt jaga folk.
Det här arbetsflödet skickar ett direktmeddelande i DingTalk när en ny PR skapas i Azure DevOps, och det taggar rätt granskare genom att mappa Azure-konton till DingTalk-användare. Du får lära dig vad det gör, vad du behöver och hur du kan anpassa det på ett säkert sätt.
Så fungerar den här automatiseringen
Här är hela arbetsflödet du kommer att sätta upp:
n8n Workflow Template: Azure DevOps till DingTalk: PR-varningar till rätt dev
flowchart LR
subgraph sg0["Flow 1"]
direction LR
n0["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/mysql.dark.svg' width='40' height='40' /></div><br/>LoadDingTalkAccountMap"]
n1["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/webhook.dark.svg' width='40' height='40' /></div><br/>ReceiveTfsPullRequestCreated.."]
n2["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/code.svg' width='40' height='40' /></div><br/>BuildDingTalkWebHookData"]
n3["<div style='background:#f5f5f5;padding:10px;border-radius:8px;display:inline-block;border:1px solid #e0e0e0'><img src='https://flowpast.com/wp-content/uploads/n8n-workflow-icons/httprequest.dark.svg' width='40' height='40' /></div><br/>SendDingTalkMessageViaWebHook"]
n0 --> n2
n2 --> n3
n1 --> n0
end
%% Styling
classDef trigger fill:#e8f5e9,stroke:#388e3c,stroke-width:2px
classDef ai fill:#e3f2fd,stroke:#1976d2,stroke-width:2px
classDef aiModel fill:#e8eaf6,stroke:#3f51b5,stroke-width:2px
classDef decision fill:#fff8e1,stroke:#f9a825,stroke-width:2px
classDef database fill:#fce4ec,stroke:#c2185b,stroke-width:2px
classDef api fill:#fff3e0,stroke:#e65100,stroke-width:2px
classDef code fill:#f3e5f5,stroke:#7b1fa2,stroke-width:2px
classDef disabled stroke-dasharray: 5 5,opacity: 0.5
class n0 database
class n1,n3 api
class n2 code
classDef customIcon fill:none,stroke:none
class n0,n1,n2,n3 customIcon
Varför detta är viktigt: PR-granskningar stannar när notiser missar
En ny PR dyker upp, men notisen hamnar på fel ställe. Eller så går den till alla, så ingen känner ansvar. Sedan går tiden. Författaren börjar puffa folk i chatten. Granskare öppnar till slut PR:en timmar senare, kontexten är borta och du får ett lågkvalitativt “LGTM” bara för att unblocka. Det är ärligt talat frustrerande, eftersom jobbet redan är gjort. Det enda som saknas är att rätt person ser det vid rätt tillfälle.
Och det är sällan ett enda stort haveri. Det är de små friktionerna som staplas och bromsar hela leveransloopen.
- Azure DevOps-notiser är lätta att missa när folk sitter i DingTalk hela dagen.
- Att sända PR-notiser till en hel gruppchatt skapar brus, vilket gör att framtida notiser ignoreras.
- Manuella “kan du granska?”-pings stjäl fokus och lägger i det tysta på ungefär en timmes avbrottstid per vecka.
- När granskartilldelning finns i folks huvuden faller täckningen direkt när någon är sjuk eller ledig.
Det du bygger: Azure DevOps PR-notiser i DingTalk (korrekt taggade)
Det här arbetsflödet lyssnar på en “Pull Request Created”-händelse från Azure DevOps som skickas in i n8n via en webhook. Så fort händelsen kommer in slår det upp vem som ska notifieras genom att fråga en enkel MySQL-mappningstabell som kopplar ett Azure-konto till en DingTalk-användare (via mobilnummer). Sedan bygger det en välformaterad payload för DingTalk-roboten i kod, så att du kan styra formatering, länkar och omnämnanden. Till sist postar det meddelandet till din DingTalk-gruppchatt via robotens webhook-URL. Resultatet: rätt personer blir pingade, i verktyget de faktiskt bevakar, utan att spamma alla andra.
Arbetsflödet börjar med en inkommande webhook som du kopplar till en Azure DevOps Service Hook. Därefter returnerar MySQL DingTalk-mottagarna för PR-författaren eller de granskare du bryr dig om. Efter det bygger n8n exakt den JSON som DingTalk förväntar sig och skickar den till DingTalk via en HTTP-request.
Det du bygger
| Vad som automatiseras | Det du uppnår |
|---|---|
|
|
Förväntade resultat
Säg att teamet skapar cirka 10 PR:er i veckan. Om varje PR triggar två manuella aktiviteter (posta en länk i DingTalk och sedan tagga rätt personer), och varje aktivitet tar kanske 5 minuter, blir det runt 100 minuter ren koordinering. Med det här arbetsflödet skapar författaren PR:en som vanligt, Azure DevOps anropar webhooken direkt och DingTalk-meddelandet postas automatiskt inom en minut. Du får tillbaka ungefär 1–2 timmar i veckan, plus färre “sorry, såg den inte”-förseningar.
Innan du börjar
- n8n-instans (prova n8n Cloud gratis)
- Alternativ för egen hosting om du föredrar det (Hostinger fungerar bra)
- Azure DevOps för att skapa en Service Hook för PR-händelser.
- DingTalk för att skapa en robot-webhook för en gruppchatt.
- MySQL-databas (skapa mappningstabellen och inloggningsuppgifter).
Kunskapsnivå: Mellan. Du ska vara bekväm med att skapa en Service Hook i Azure DevOps och klistra in webhook-URL:er, samt grundläggande databaskonfiguration.
Vill du att någon bygger detta åt dig? Prata med en automationsexpert (gratis 15-minuters konsultation).
Steg för steg
En pull request skapas i Azure DevOps. Azure DevOps skickar en “Pull Request Created”-Service Hook till din n8n-webhook-URL (arbetsflödets inkommande trigger).
Arbetsflödet hittar rätt personer att nämna. n8n frågar MySQL för att hämta mappningen mellan Azure-kontot (till exempel PR-skaparen eller specifika användarnamn) och DingTalk-mobilnumren som används för omnämnanden.
Meddelandet sätts ihop med rätt kontext. Ett kort kodsteg formaterar PR-titel, repo-/projektinfo, författare och PR-länk till en DingTalk-robotpayload som kan nämna användare på ett snyggt sätt.
DingTalk tar emot notisen. n8n skickar en HTTP-request till din DingTalk-grupprobots webhook och postar det färdiga meddelandet i chatten där granskningar faktiskt uppmärksammas.
Du kan enkelt ändra vem som taggas och hur meddelandet ser ut utifrån dina behov. Se hela implementationsguiden nedan för anpassningsalternativ.
Steg-för-steg-guide för implementation
Steg 1: konfigurera webhook-triggern
Konfigurera den inkommande webhooken som tar emot PR-notiser och startar arbetsflödet.
- Lägg till en Inbound PR Webhook-nod och ställ in HTTP Method på
POST. - Ställ in Path till
pr-notify-template. - Kopiera den genererade webhook-URL:en från Inbound PR Webhook och konfigurera ert PR-system att skicka POST-förfrågningar till den.
Steg 2: anslut MySQL för reviewer-mappning
Hämta DingTalk-mappningar från MySQL så att arbetsflödet kan översätta TFS-konton till DingTalk-mobilnummer och användarnamn.
- Lägg till en Fetch DingTalk Mapping-nod.
- Credential Required: anslut era mySql-inloggningsuppgifter.
- Ställ in Operation på
select. - Ställ in Return All på
true. - Ställ in Table på
tfs_dingtalk_account_map. - Säkerställ att körflödet kopplar Inbound PR Webhook → Fetch DingTalk Mapping.
TfsAccount, DingTalkMobile, UserName) kommer notisen inte att innehålla omnämnanden.Steg 3: konfigurera payload-bearbetningen
Transformera webhookens payload och mappningsdata till ett DingTalk-anpassat meddelande.
- Lägg till en Compose DingTalk Payload-nod (Code).
- Klistra in den tillhandahållna JavaScript-koden i Code så att den läser från
$node["Inbound PR Webhook"].json.body. - Bekräfta att scriptet skriver ut
isAtAll,textochatMobilesi slutlig JSON. - Koppla Fetch DingTalk Mapping → Compose DingTalk Payload.
Steg 4: konfigurera utskick av DingTalk-alert
Skicka den formaterade markdown-alerten till DingTalk via en robot-webhook.
- Lägg till en Dispatch DingTalk Alert-nod.
- Ställ in Request Method på
POSToch aktivera JSON Parameters. - Ställ in URL till
https://oapi.dingtalk.com/robot/send?access_token=[CONFIGURE_YOUR_TOKEN]. - Ställ in Body Parameters JSON till
={ "at": { "atMobiles": [{{$json["atMobiles"]}}], "isAtAll": "{{$json["isAtAll"]}}" }, "msgtype": "markdown", "markdown": { "title": "New PR Notify", "text": "{{$json["text"]}}" } }. - Koppla Compose DingTalk Payload → Dispatch DingTalk Alert.
[CONFIGURE_YOUR_TOKEN] med en riktig DingTalk robot access token, annars kommer förfrågan att misslyckas.Steg 5: testa och aktivera
Verifiera hela körvägen från webhook till DingTalk och aktivera arbetsflödet för produktion.
- Klicka på Execute Workflow och skicka en test-POST-förfrågan till URL:en för Inbound PR Webhook.
- Bekräfta att Fetch DingTalk Mapping returnerar mappningsrader och att Compose DingTalk Payload skriver ut
isAtAll,textochatMobiles. - Verifiera att Dispatch DingTalk Alert returnerar ett lyckat HTTP-svar och att meddelandet visas i DingTalk.
- Växla arbetsflödet till Active för att aktivera PR-notiser i realtid.
Felsökningstips
- MySQL-inloggningsuppgifter kan gå ut eller kräva specifika behörigheter. Om det skapar fel, kontrollera först användarbehörigheter (grants) i MySQL och de sparade inloggningsuppgifterna i n8n.
- DingTalk-robotwebhooks kan begränsas av säkerhetsinställningar (nyckelord, IP-allowlists eller signaturer). Om HTTP-requesten misslyckas, bekräfta att roboten är aktiverad och att din webhook-URL matchar gruppchattens robotinställningar.
- Azure DevOps Service Hooks är petiga med webhook-URL:ens sökväg. Om du ändrar n8n-webhookens path, uppdatera Service Hook direkt, annars slutar du ta emot PR-händelser utan att det märks.
Snabba svar
Cirka 30–60 minuter när du väl har DingTalk-roboten och MySQL på plats.
Nej. Du kan använda mallen som den är och bara redigera textfält. Om du vill ha ett väldigt specifikt meddelandeformat kan du justera kodsteget “Compose DingTalk Payload”.
Ja. n8n har ett gratis alternativ för egen hosting och en gratis provperiod på n8n Cloud. Cloud-planer börjar på 20 USD/månad för högre volymer. Du behöver också räkna in kostnader för MySQL-hosting (ofta 5–20 USD/månad om du inte redan har en databas).
Två alternativ: n8n Cloud (hanterat, enklast setup) eller egen hosting på en VPS. För egen hosting är Hostinger VPS prisvärd och hanterar n8n bra. Egen hosting ger dig obegränsade körningar men kräver grundläggande serverhantering.
Ja, och det är hela poängen. Du kan ändra MySQL-mappningslogiken i “Fetch DingTalk Mapping” för att mappa på PR-författare, repo, team eller till och med regler baserade på branch-namn. De flesta team anpassar också “Compose DingTalk Payload” för att inkludera PR-länken, checklistpåminnelser eller en kort “vad ändrades”-sammanfattning hämtad från webhook-datan.
Oftast beror det på en ogiltig robot-webhook-URL eller att en säkerhetsregel för roboten blockerar anropet. Bekräfta att webhooken i DingTalk inte har genererats om, och kolla sedan HTTP-svaret i n8n efter ledtrådar (401/403 är vanligtvis behörigheter eller säkerhetsinställningar). Verifiera också att din payload matchar det DingTalk förväntar sig, eftersom ett litet JSON-misstag kan ge ett hårt fel.
Ett typiskt team kan köra hundratals PR-notiser per dag utan problem, så länge MySQL och din n8n-instans mår bra.
Ofta, ja, för en setup som den här. Den svåra delen är inte “skicka ett meddelande”, utan att mappa identiteter (Azure-konto → DingTalk-användare) och formatera omnämnanden pålitligt, och n8n gör den logiken enkel. Du får också möjlighet till egen hosting, så du inte betalar per litet steg när meddelandevolymen sticker iväg. Zapier eller Make kan fortfarande fungera om behoven är enkla och du är okej med bredare notiser till en kanal i stället för riktade omnämnanden. Om du är osäker, prata med en automationsexpert så hjälper vi dig att välja snabbt.
När detta väl kör är PR-notiser inte längre ett socialt problem som teamet måste hantera. Arbetsflödet sköter den repetitiva delen, så att granskningar går snabbare med färre avbrott.
Kontakta oss
Hör av dig, så diskuterar vi hur just din verksamhet kan dra nytta av alla fantastiska möjligheter som AI skapar.