Eddie Blomkvist
Ja, monday.com går att koppla till GitHub. Kopplingen gör att en bugg som rapporteras i monday.com blir en issue i rätt repo, att statusen på objektet följer pull requesten från öppnad till mergad, och att projektledare och kundansvariga ser var en leverans står utan att öppna GitHub. monday.com har en egen GitHub-integration i Integrations Center, och den räcker för de vanligaste flödena. Behöver ni mer, till exempel releaser som uppdaterar kundens objekt eller villkor som beror på fler system, byggs resten i Make. Den här artikeln går igenom vad kopplingen gör, hur den byggs och vad ni ska tänka på innan ni sätter igång.
- Ett ärende markeras som bugg i supporttavlan
- En issue skapas i rätt repo med ärendets beskrivning
- Utvecklaren tar issuen i GitHub
- Status på ärendet följer issuen
Supporten rapporterar i monday.com, utvecklarna arbetar i GitHub, och supporten ser när buggen är åtgärdad.
- Utvecklaren skapar en pull request med objektets id i titeln
- Status i monday.com blir I granskning
- Router · Mergad?JaStatus blir Klar och objektet märks med versionNejStår kvar tills granskningen är klar
- Projektledaren ser läget utan att öppna GitHub
Statusen ändras när något faktiskt händer i koden, inte när någon kommer ihåg att uppdatera tavlan.
- En release publiceras i GitHub
- Kopplade objekt får releasens version
- Kundansvarig får listan över vad som ingår
Kundansvarig kan berätta för kunden vad som levererats, byggt på det som finns i releasen.
- En kund begär en funktion via CRM-tavlan
- Produktägaren godkänner
- En issue skapas och kopplas till objektet
- Kunden får besked när issuen stängs
Önskemål går från sälj via produkt till utveckling, och tillbaka till kunden, utan att tappas bort.
Flödena ovan är bara exempel. Varje koppling byggs efter er process: vilka steg som ska finnas, vad som ska hända i varje läge och vem som ansvarar för vad.
Kort svar
monday.com har en egen GitHub-integration i Integrations Center. Med den kan ni skapa issues från objekt, ändra status när en issue skapas, märks eller byter status, när en pull request skapas eller mergas och när en gren skapas, och koppla objekt till pull requests och issues via objektets id. I monday dev visar GitHub-appen pull requests, issues, grenar och commits direkt på objektet. För flöden som går utanför recepten, till exempel releaser som uppdaterar kundens objekt eller villkor som beror på fler system, byggs kopplingen i Make, som har moduler för både monday.com och GitHub. Det är den kombinationen vi oftast bygger.
Vad kopplingen kan göra
Här är fyra vanliga exempel. Er koppling kan göra mer, mindre eller något helt annat.
En bugg eller ett önskemål i monday.com blir en issue i rätt repo, med beskrivning, etiketter och koppling tillbaka till objektet. Supporten eller produktägaren behöver inte ha tillgång till GitHub.
När en issue byter status eller en pull request skapas eller mergas ändras statusen i monday.com. Tavlan visar hur det faktiskt ser ut i koden.
I monday dev syns kopplade pull requests, issues, grenar och commits direkt på objektet, så att den som undrar varför något står still ser det utan att fråga.
När en release publiceras kan kopplade objekt märkas med version, och kundansvariga kan se vad som ingår i det som levererats.
Varför koppla ihop monday.com och GitHub?
- Utvecklarna slipper dubbelrapportera. Arbetet sker i GitHub, och tavlan uppdateras av det som händer i koden.
- Resten av bolaget ser läget. Support, sälj och ledning följer leveransen i monday.com utan att behöva konto eller vana i GitHub.
- Inget tappas mellan systemen. Buggar och önskemål som rapporteras i monday.com kommer fram till utvecklingen, och svaret kommer tillbaka.
- Bättre underlag. Ledtider, antal öppna buggar och vad som ingår i en release bygger på verkliga händelser, inte på manuella uppdateringar.
Så byggs kopplingen
Det finns tre vägar, och vilken som passar beror på hur avancerat flödet är.
| Väg | Passar när | Att tänka på |
|---|---|---|
| monday.coms GitHub-integration | De vanliga flödena: issue från objekt, status som följer issues och pull requests, koppling via objektets id | Snabbt att komma igång och ingen tredje part, men recepten är fasta och kräver att GitHub-appen installeras på era repon med rätt behörigheter |
| Make | Flöden utanför recepten, till exempel releaser som uppdaterar kundens objekt, issues som skapas med villkor från CRM eller flera repon med olika regler | Flexibelt, men kräver ett genomtänkt flöde: hur objekt och issues matchas, hur undantag hanteras och hur fel upptäcks |
| Egen kod mot GitHubs API | Stora volymer, egna byggkedjor eller krav som plattformarna inte klarar | Mest flexibelt, men kräver att någon äger och förvaltar koden |
För de flesta bolag räcker monday.coms egen integration för grunden, med Make för det som går utanför. Men verktyget är bara verktyget. Det som avgör om kopplingen håller är hur den byggs: hur objekt och issues kopplas ihop så att rätt objekt uppdateras, hur statusar i monday.com översätts till det som händer i GitHub, vad som händer med objekt som har flera pull requests, och hur fel upptäcks. En koppling som fungerar på ett repo men tyst missar det andra kostar mer än den sparar. Därför bygger vi med loggning och larm från början, och förvaltar kopplingen när arbetssättet ändras. Integrationer i monday.com kräver en plan med integrationer, och GitHub-appen behöver läs- och skrivrättigheter till de repon som ska kopplas.
Det här ska ni bestämma innan ni bygger
En koppling blir aldrig bättre än processen den automatiserar. De här frågorna avgör om den fungerar i praktiken:
- Vad ska bli en issue? Alla buggar, bara godkända, eller bara de som produktägaren släpper vidare? Bestäm vilken status i monday.com som skapar issuen och vem som får sätta den.
- Hur kopplas objekt och kod? Objektets id i pull requestens titel eller beskrivning är det monday.com stödjer. Bestäm att utvecklarna alltid använder det, annars hamnar ändringar på fel objekt eller inget alls.
- Vilka statusar ska följa koden? Översätt öppen, i granskning, mergad och släppt till era statusar, och bestäm vad som händer när ett objekt har flera pull requests.
- Vilka repon ingår? Olika produkter kan ha olika regler. Bestäm per repo vad som ska kopplas och till vilken tavla.
- Vad händer när något går fel? Ett bra flöde loggar varje körning och säger till om en issue inte kunde skapas eller ett objekt inte hittades.
monday dev och GitHub delar på ansvaret
monday dev är monday.coms produkt för utvecklingsteam, med sprintar, roadmap och buggspårning, och det är där GitHub-kopplingen gör mest nytta. Utvecklarna arbetar i GitHub, sprintplanering och prioritering sker i monday dev, och objektet visar pull requests, grenar och commits från GitHub. Hur vi sätter upp monday dev beskriver vi på monday dev. Kopplingen blir ännu starkare när support och sälj är med: ärenden från monday service blir issues, och det som levereras syns i CRM-tavlan. Ledningen följer leveransen i dashboards som bygger på verkliga händelser i koden, vilket vi beskriver i Dashboards ledningen tittar på. Många team kompletterar med Slack för besked när något mergas. Alla kopplingar vi bygger finns under alla integrationer.
Straviont bygger kopplingen
Vi är officiell monday.com-partner och certifierade CRM-specialister hos monday.com, och vi sätter upp monday dev och kopplingen till GitHub, med Make där recepten inte räcker. Vi börjar i processen: vad som ska bli en issue, hur objekt och kod kopplas och vilka statusar som ska följa koden. Först därefter byggs flödet, med loggning och felhantering, och vi förvaltar det när arbetssättet ändras.
Vanliga frågor
Går det att koppla monday.com till GitHub?
Ja. monday.com har en egen GitHub-integration i Integrations Center som skapar issues, följer issues och pull requests och kopplar objekt till kod via objektets id. För flöden utanför recepten byggs kopplingen i Make eller med egen kod mot GitHubs API.
Kan en bugg i monday.com bli en issue i GitHub automatiskt?
Ja. När ett objekt får en viss status kan en issue skapas i det repo ni valt, med objektets beskrivning. Issuen kopplas till objektet, så att statusen i monday.com följer issuen.
Kan statusen i monday.com följa en pull request?
Ja. När en pull request skapas eller mergas kan statusen på det kopplade objektet ändras. Kopplingen sker via objektets id i pull requestens titel eller beskrivning.
Syns pull requests och commits i monday.com?
Ja, i monday dev. GitHub-appen visar pull requests, issues, grenar och commits som är kopplade till objektet, med status, författare och granskare.
Behöver alla ha konto i GitHub?
Nej. Support, sälj och ledning arbetar i monday.com, och det som är relevant från GitHub syns där. Bara utvecklarna behöver GitHub.
Vad behövs för att koppla ihop systemen?
Ett monday.com-konto på en plan med integrationer, GitHub-appen installerad på de repon som ska kopplas med läs- och skrivrättigheter, och ett Make-konto om ni behöver flöden utanför recepten.
Så går ni vidare
Börja med att beskriva flödet från rapporterad bugg till levererad release: vem som rapporterar, vem som prioriterar och vilka statusar som ska följa koden. Därefter går det snabbt att bygga. Vill ni ha hjälp går det bra att boka en kostnadsfri kartläggning, så går vi igenom det tillsammans.