Det här är sidan som resten av dokumentationen hänvisar till. Den beskriver varje steg i arbetsflödet så att andra artiklar kan vara tydliga med när något händer.
Arbetsflödet
- 1
SpecifikationVad som ska byggas och hur du vet att det fungerar
ArkitektDu kan redigera - 2Plan
Steg i rätt ordning, granskade innan någon kod skrivs
ArkitektDu godkänner - 3
ByggKod och tester skrivs i en isolerad arbetsyta
Utvecklare - 4
VerifieraDin testsvit, tillsammans med kontroller och kvalitetskontroller
QA - 5
GranskningAutomatisk granskning av diffen
Granskare - 6Pull request
På en branch i ditt repository, i väntan på dig
Du mergar
Misslyckad verifiering och granskningsfynd som går att åtgärda skickas tillbaka till utvecklaren för omarbete, innan någon pull request öppnas.
Stegen är desamma oavsett vilket av de två sätten en uppgift kan köras på. I standardläget flyttar plattformen uppgiften från ett steg till nästa. I samordnarläget stannar planeringsagenten kvar vid uppgiften som samordnare, tilldelar varje steg till rätt agent och avgör vad som händer efter varje resultat, inklusive att skicka tillbaka arbete. Oavsett läge avslutas ett steg med sina egna kontroller. Se Agentroller om hur de två lägena skiljer sig åt.
Specifikation
Coroid utgår inte från din mening. Först omvandlas din beskrivning till en specifikation: vad som ska byggas, vad som uttryckligen inte ingår och vilka acceptanskriterier som avgör om arbetet lyckades.
Det här är viktigt eftersom verifieringssteget senare testar arbetet mot acceptanskriterierna. En vag specifikation gör arbetet svårt att bedöma.
Du kan läsa och redigera specifikationen under uppgiftens flik Specifikation innan arbetet börjar.
Den guiden till specifikationsdriven utveckling förklarar hur du skriver testbara kriterier, sätter gränser för omfattningen och använder samma definition av framgång genom planering, implementation och granskning.
Planera
För allt utom en liten ändring blir specifikationen en plan: en ordnad uppsättning steg, indelade i faser. Du godkänner planen innan koden skrivs.
Det är enkelt och klokt att underkänna en plan om tillvägagångssättet är fel. Att underkänna efter att koden har skrivits kostar mer. Det är i det här steget som ditt omdöme har störst påverkan.
Bygg
En agent klonar repot till en isolerad arbetsyta och arbetar där. Den läser koden, skriver ändringen och skapar eller uppdaterar tester.
Arbetsytan är tillfällig och unik för varje uppgift. Inget en agent gör påverkar din standardgren, och två uppgifter som körs samtidigt kan inte se varandras pågående arbete.
Verifiera
Din egen testsvit körs först – det är den starkaste tillgängliga signalen, eftersom den kodifierar det som teamet redan har bestämt är viktigt.
Dessutom kvalitetsgrindar kör allt som organisationen har konfigurerat: täckningsgränser, lintning, webbläsartester mot en förhandsvisning och Säkerhet -skydd. En blockerande grind stoppar uppgiften; en rådgivande grind registrerar en iakttagelse och låter arbetet fortsätta.
Granskning
En granskaragent läser diffen som en kollega skulle göra och rapporterar iakttagelser. Iakttagelser som går att åtgärda skickas tillbaka för omarbetning; resten bifogas till pull request så att du kan se dem.
Därför kommer en Coroid pull request redan granskad – inte för att ersätta din granskning, utan för att den inte ska vara den första.
Pull request
Grenen pushas och en pull request öppnas mot din basgren med ändringen, testerna, verifieringsresultaten och granskningsiakttagelserna. Om koden redan gör det uppgiften kräver finns det inget att pusha: QA verifierar då den oförändrade koden i stället, och uppgiften avslutas utan en pull request.
Coroids automatisering av uppgifter slutar här. Du ansvarar för mergningen.
Efter mergningen
Öppna Versioner för att förbereda den exakta commit du tänker
leverera. En release kan innehålla flera mergade pull requests, en direkt commit eller
arbete som mergats utanför Coroid. Releasegrinden och godkännandena gäller den
commiten och en specifik miljö. Din pipeline distribuerar den; Coroid registrerar en
observerad framgång eller ett uttryckligt intyg innan den visas som levererad. En uppgift
med status COMPLETED eller en mergad pull request bevisar inte i sig att en distribution har skett.
Uppgiftsstatusar
En uppgifts status visar var i arbetsflödet ovan den befinner sig:
| Status | Betydelse |
|---|---|
PENDING | Godkänd, väntar på en ledig agentplats |
IN_PROGRESS | Arbetet pågår |
PENDING_REVIEW | Arbetet är klart och granskat, väntar på integrering eller godkännande |
COMPLETED | Uppgiften är klar; distribution följs upp separat |
NEEDS_HUMAN_REVIEW | Coroid kan inte fortsätta på egen hand och ställer en fråga till dig |
PAUSED | Tillfälligt stoppad, kan återupptas |
FAILED | Arbetet kunde inte slutföras |
CANCELLED | Stoppad av dig |
WONT_FIX | Avslutad med avsikt utan att arbetet utfördes |
Vad som påverkar kapaciteten
En agentplats hanterar en uppgift åt gången. Antalet platser avgör hur mycket arbete som utförs parallellt; det får inte en enskild uppgift att bli klar snabbare. Hur lång tid en uppgift tar beror på ändringens omfattning och hur lång tid din testsvit tar.
Nästa
Agentroller – vilken agent som hanterar varje arbetssteg. Se sedan Versioner för arbetsflödet genom dina miljöer efter mergning.