Det här är sidan som resten av dokumentationen hänvisar tillbaka till. Här namnges varje steg i körningen, så att andra artiklar kan vara precisa om var något händer.
Vägen
- 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.
De här 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 läget Coordinator 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 varje steg med sina egna kontroller. Se Agentroller för att se hur de två lägena skiljer sig åt.
Specifikation
Coroid utgår inte från din mening. Först omvandlar det din beskrivning till en specifikation: vad som ska byggas, vad som uttryckligen inte ingår och acceptanskriterierna som avgör om arbetet lyckades.
Det här spelar roll eftersom verifieringssteget senare testar arbetet mot acceptanskriterierna. En otydlig specifikation ger arbete som är svårt att bedöma.
Du kan läsa och redigera specifikationen på uppgiftens flik Specifikation innan arbetet börjar.
En guide 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, implementering och granskning.
Planera
För allt utom mindre ändringar blir specifikationen en plan: en ordnad uppsättning steg, indelade i faser. Du godkänner planen innan koden skrivs.
Det kostar lite att avvisa en plan, och det är rätt beslut när tillvägagångssättet är fel. Att avvisa den efter att koden skrivits kostar mer. Det är i det här steget ditt omdöme gör störst skillnad.
Bygg
En agent klonar repot till en isolerad arbetsyta och arbetar där. Den läser koden, gör ändringen och skriver eller uppdaterar tester.
Arbetsytan är tillfällig och avsedd för en enda uppgift. Inget en agent gör påverkar din standardbranch, 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 ditt team redan har bestämt är viktigt.
Dessutom kvalitetsgrindar kör det som din organisation har konfigurerat: täckningsgränser, lintning, säkerhetsskanning och webbläsartester mot en förhandsvisning av driftsättningen. En blockerande grind stoppar uppgiften; en rådgivande grind registrerar en iakttagelse och låter arbetet fortsätta.
Granskning
En granskningsagent läser diffen som en kollega skulle göra och tar fram iakttagelser. Sådant som går att åtgärda skickas tillbaka för omarbetning; resten kopplas till pull request så att du kan se det.
Därför kommer en Coroid pull request redan granskad – inte för att ersätta din granskning, utan för att du inte ska behöva vara den första som granskar den.
Pull request
Grenen pushas upp och en pull request öppnas mot din basgren, med ändringen, testerna, verifieringsresultaten och granskningsresultaten. Om koden redan gör det uppgiften efterfrågar finns det inget att pusha: QA verifierar i stället den oförändrade koden, och uppgiften slutförs utan en pull request.
Coroids uppgiftsautomatisering slutar här. Du ansvarar för att merga.
Efter mergningen
Öppna Versioner för att förbereda den exakta commit du tänker
släppa. En version kan innehålla flera mergade pull requests, en direkt commit eller
arbete som mergats utanför Coroid. Versionsgrinden och godkännandena gäller den committen
och en specifik miljö. Din pipeline distribuerar den; Coroid registrerar en
observerad lyckad distribution eller en uttrycklig attestering innan den visas som levererad. En uppgift
med statusen COMPLETED eller en mergad pull request räcker inte i sig för att bevisa att distributionen har skett.
Uppgiftsstatusar
En uppgifts status visar var i förloppet ovan den befinner sig:
| Status | Betydelse |
|---|---|
PENDING | Accepterad, väntar på en ledig agentplats |
IN_PROGRESS | Arbetas aktivt med |
PENDING_REVIEW | Arbetet är klart och granskat, väntar på integrering eller godkännande |
COMPLETED | Arbetet med uppgiften är klart; distributionen 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 | Körningen kunde inte slutföras |
CANCELLED | Stoppad av dig |
WONT_FIX | Avslutad medvetet utan att arbetet utfördes |
Vad som avgör genomströmningen
En agentplats kör en uppgift åt gången. Antalet platser avgör hur mycket arbete som kan utföras parallellt; det gör inte att en enskild uppgift blir 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 arbetsmoment. Läs sedan om Versioner för arbetsflödet efter mergning genom dina miljöer.