Planer

En plan är en ordnad uppsättning uppgifter indelade i faser. Du godkänner den innan koden skrivs.

Använd en när arbetet kräver flera ändringar i en viss ordning, eller när du vill se hela upplägget innan du bestämmer dig för något av det.

Livscykeln#

Planering är ett eget steg, inte en omedelbar omvandling.

1. Planeringen börjar. När förfrågan har passerat Kvalificering utforskar arkitekten källkoden och tar fram utkast till faser och uppgifter. Planeringen börjar av sig själv om inte förfrågan innehöll bilagor eller använde SDLC-arbetsflödet; då börjar den när du skapar planen eller slutför förberedelserna.
2. Du granskar utkastet. Det här är det minst kostsamma tillfället att ingripa i hela systemet.
3. Godkänn, ändra eller återställ. När du godkänner planen kan den köras; om du ändrar den skickas den tillbaka med din feedback; om du återställer den börjar planeringen om.
4. Körning. Uppgifterna körs i ordning och följer fasgränserna.

Du kan godkänna och köra planen i ett steg, eller godkänna den och starta den senare.

Ändra i stället för att återställa#

När en plan nästan är rätt bevarar en ändring det arkitekten har lärt sig om din källkod och tillämpar din feedback. Om du återställer planen går det förlorat och planeringen börjar om.

Återställ när hela upplägget är fel. Ändra när upplägget är rätt men detaljerna inte stämmer. Det är mycket billigare att ändra, och innehållet i en avvisad plan går inte förlorat – det blir underlag för nästa försök.

Styra en plan som körs#

En plan som körs kan pausas, återupptas eller avbrytas, och du kan följa förloppet i alla faser. Planer kan också klonas, vilket är ett praktiskt sätt att återanvända en struktur som fungerade – till exempel en migrering som tillämpas på en andra tjänst.

Slutförda planer kan arkiveras så att vyn över aktiva planer förblir användbar.

En pull request, inte en per uppgift#

Uppgifterna i en plan öppnar inte varsin pull request. De arbetar på egna brancher och mergas till en gemensam lane branch; den branchen skickas vidare som en enda pull request mot din base branch när arbetet uppfyller kraven.

Du granskar alltså den färdiga funktionen en gång, med hela ändringen synlig, i stället för att godkänna halvfärdiga faser en i taget.

Planer som omfattar flera projekt är undantaget: en uppgift som tillhör ett annat projekt än det för lane-branchen skickas vidare separat, så du får en pull request per repository. En pull request kan inte omfatta två repositories.

När basgrenen ändras#

En plan kan köras i flera timmar medan teamet fortsätter att sammanfoga ändringar till basgrenen. Planen har byggts, testats och granskats mot basgrenen så som den såg ut när planen startade. När dess pull request är klar kanske den grenen inte längre är den som ändringen sammanfogas till.

När en plan börjar köras registrerar Coroid basgrenens senaste commit som planens utgångsläge. Innan planens pull request kan sammanfogas kontrollerar Coroid basgrenen igen. Alla ändringar i filinnehåll räknas, även i filer som planen inte har ändrat. Ett nytt autentiseringssystem eller en ny säkerhetsregel kan göra korrekt kod felaktig utan att orsaka en mergekonflikt, så Coroid väntar inte på en sådan.

Om basgrenen har ändrats Godkänn och sammanfoga är inaktiverat och granskningen inför vidarebefordran visar de nya commits och vilka filer de ändrat. Du väljer vad som ska hända:

• Godkänn ny main (namnet kommer från din basgren) – ändringarna påverkar inte det här arbetet. Coroid registrerar vem som godkände vilken commit och varför, och den committen blir det nya utgångsläget. Om grenen ändrades igen medan du läste vägrar Coroid och visar först de nyare committarna. Inget godkänns utan att visas.
• Sammanfoga och verifiera igen – Coroid sammanfogar basgrenen med lane-grenen och löser eventuella konflikter. Därefter körs lane-grenen återigen genom utvecklaren, QA och granskaren, som kontrollerar den mot planens godkännandekriterier och uppströms-committarna. Godkännandet hålls inne tills det är klart. Först då blir den nya committen utgångsläget. Om sammanfogningen eller verifieringen misslyckas får du fatta beslutet igen.

Som standard pausas arbetet. Ett projekt kan i stället välja att sammanfoga och verifiera igen, så att Coroid sätter igång utan att vänta på dig. Se Inställningar för repository och grenar. Verifiering på nytt förbrukar agenttimmar.

En plan som startas om från början får ett nytt utgångsläge och körs därmed mot basgrenen som den ser ut då. Underlaget från det tidigare försöket finns kvar i historiken, men gäller inte för det nya försöket.

Tvinga sammanfogning hoppar också över den här kontrollen och registrerar den skriftliga motivering som krävs. Se Sammanfogning.

Faser och parallellkörning#

Faser anger ordningsföljd, inte samtidighet. Uppgifter inom en fas kan köras parallellt om kapaciteten räcker till; nästa fas väntar tills den aktuella är klar.

En plan med tio uppgifter som kan köras parallellt och en agentplats kör ändå uppgifterna en i taget. Strukturen skapar inte kapacitet – se Kapacitet och agentplatser.

Plan eller uppgift?#

I formuläret Nytt arbete väljer du Plan eller Uppgift under Skapa som, eller låter det stå kvar på Automatiskt så får Kvalificering välja. Arbete som omfattar mer än ett projekt blir alltid en plan. Om du väljer ett alternativ och Kvalificering rekommenderar det andra får du se rekommendationen innan något skapas.

Bedömningen handlar om hur lätt arbetet är att granska: en pull request som en kollega kan läsa igenom på en sittning är en uppgift; allt som kräver flera ändringar i en viss ordning är en plan.

Att välja uppgift för arbete som faktiskt är omfattande är det mer riskabla misstaget – uppgiften kan ta slut mitt i arbetet, så körningen går till spillo. Att välja plan kostar dig ett godkännandesteg som du egentligen inte behövde.

Leveransgrindar#

En plan kan ha en leveransgrind som styr vad som måste vara uppfyllt innan resultatet går vidare. Se Kvalitetsgrindar.

Relaterat#

• Uppgifter, planer, sprintar och lanes
• Sprintar
• Specifikationer
• Beviskedja