Coroid avslutar med att öppna en pull request på en egen branch, mot din basbranch. Den mergar aldrig på egen hand. Det är alltid en person som beslutar om merge, antingen hos din leverantör eller med Godkänn och mergea i Coroid. Se Merging.
Det här ingår
- kodändringen
- tester som har skrivits eller uppdaterats tillsammans med den
- resultatet av att köra din befintliga testsvit
- resultatet av eventuella kvalitetskontroller som din organisation har konfigurerat
- en granskning av diffen, där upptäckta problem antingen redan har åtgärdats eller listas
Poängen är inte att ersätta din granskning. Det handlar om att din granskning inte ska vara den första.
main- Kodändringen4 filer
- Tester som skrivits eller uppdaterats2 filer
- Din befintliga testsvitGodkänt
- Kvalitetskontroller1 informativ anmärkning
- Granskningsrunda2 åtgärdade, 1 kvar på listan
Vad du faktiskt ska kontrollera
De mekaniska kontrollerna är redan gjorda. Lägg din uppmärksamhet på sådant som bara du kan bedöma:
- Löser ändringen rätt problem? Jämför den med specifikationens acceptanskriterier, inte med minnet av vad du bad om.
- Passar den in i kodbasen? Konventioner, namngivning och abstraktionens utformning. Coroid läser din kod för att härleda detta och får det oftast rätt – men oftast är inte alltid.
- Vad påverkas som du inte hade väntat dig? Titta på fillistan innan du granskar diffen.
- Är de nya testerna meningsfulla? Ett godkänt test som inte kontrollerar något är sämre än inget test alls.
Skicka tillbaka arbetet
Du har tre alternativ, från minst till störst insats:
- Kommentera och begär omarbetning – uppgiften går tillbaka till utvecklaragenten med dina synpunkter och agenten behåller sitt sammanhang. Passar bäst när ”det här är rätt, men ofullständigt”.
- Avvisa planen och kör igen – när angreppssättet är fel, inte utförandet.
- Avbryt uppgiften – när arbetet inte alls ska utföras. När du avbryter stoppas körningen och agentplatsen frigörs.
Var specifik i kommentarer om omarbetning, precis som du skulle vara med en kollega. ”Det här hanterar inte fallet när parseRange” leder till en lösning; ”behöver åtgärdas” leder till en gissning.
Merging
Coroid mergar aldrig på egen hand. Det finns ingen inställning som gör att den mergar när en uppgift är klar. Merge sker på ett av två sätt, och båda börjar med att en person beslutar att mergea.
Det här gäller även arbete som startats under ett mandat . Coroid registrerar vad den skulle ha beslutat om varje merge för att mäta sitt eget omdöme, men agerar aldrig utifrån den registreringen. Se Vad Coroid beslutar och vad du själv ansvarar för.
I GitHub eller GitLab
Mergea pull request hos din leverantör med dina vanliga regler för branchskydd, obligatoriska kontroller och godkännanden. pull request är en vanlig sådan – med flit – så den följer de gransknings- och CI-processer du redan litar på.
Från Coroid, med Godkänn och mergea
Granskningsvyerna i Coroid har en knapp för Godkänn och mergea . Du får bekräfta, sedan mergar Coroid pull request åt dig via GitHub eller GitLab med projektets repoanslutning. Det är samma merge som när du trycker på mergeknappen hos din leverantör, så reglerna för branchskydd, obligatoriska kontroller och godkännanden gäller. Om de blockerar merge visar Coroid leverantörens orsak, och inget mergas.
Vad som händer före merge beror på vad du godkänner:
- En uppgift. Uppgiften behöver först en pull request. Om den inte har någon ännu erbjuder granskningsvyn Skapa PR före Godkänn och mergea. När du godkänner pushar Coroid uppgiftens branch så att pull request innehåller de senast granskade commitarna, och mergar sedan pull request. För att godkänna en uppgift behöver du skrivrättigheter till projektet.
- En plan. Uppgifter som ingår i en plan kan inte mergas en i taget. Planens enda pull request godkänns i planens granskningsvy för driftsättning. Coroid kontrollerar först att basbranchen inte har ändrats sedan planen startade (se När basbranchen ändras), att de obligatoriska kvalitetskontrollerna godkänns, att pull request inte har mergekonflikter och att ingen lane-gate blockerar. Därefter mergar den pull request. För att godkänna en plan behöver du skrivrättigheter till projektet.
- Tvinga merge. I planens granskningsvy för driftsättning finns också alternativet Tvinga merge. Det hoppar över Coroids kontroller av basbranch, mergekonflikter och lane-gate, men inte de obligatoriska kvalitetskontrollerna eller reglerna hos din leverantör. Du måste ange en skriftlig motivering, som registreras tillsammans med driftsättningen, och ha administratörsåtkomst till projektet.
Den chattassistenten och MCP-klienter kan också godkänna eller tvinga fram merge av planens pull request. De agerar som du, så samma kontroller och projektåtkomst gäller. Assistenten ber dig alltid bekräfta först. En tvingad merge från en MCP-klient väntar alltid i Godkännanden på en person. Om ett godkännande från en MCP-klient väntar där beror på dina automatiseringsprinciper. Inget av alternativen kan mergea en enskild uppgift.
Förbered det som ska levereras
När du har mergat öppnar du fliken Versioner och väljer Ny release. Välj den mergade commit du vill leverera; Coroid listar pull requests som ingår. På releasesidan går varje miljö sedan igenom fyra steg: kontroller, godkännande, driftsättning och hälsa. Det är fortfarande ditt repository och CI/CD som sköter driftsättningen. Coroid markerar en release som driftsatt först när din pipeline bekräftar det, eller när en Ägare eller Administratör registrerar en verifierad extern driftsättning.
Nästa
Versioner – förbered den mergade commiten och följ den genom varje miljö. Vad du kan göra härnäst listar de andra arbetsflödena.