Sådan finder du flaskehalse i en software release-proces
Tegn release-processen som et rutediagram, tæl, hvad der forlader hver beslutning, og vis antallene som et Sankey-diagram. Find den port, hvor builds fejler, vender tilbage eller venter længst.
En flaskehals i en release er den port, hvor arbejde hober sig op, fejler eller kommer tilbage. Guiden tegner først processen, så hver port er en beslutning med navngivne udgange, og tæller derefter releases gennem de udgange.
Kort fortalt
- Tegn processen som beslutninger med labelede udgange, før du tæller noget.
- Tæl releases (eller builds) gennem hver udgang for én periode.
- En port med en bred returgren er en flaskehals, også selv om den er hurtig.
- Vis antallene som et Sankey-diagram, og brug rutediagrammet til at forklare dem.
Start med portene, ikke tallene
Teams leder som regel efter det langsomme trin ved at tage gennemsnit af varigheder. Det finder langsomme opgaver, men ikke de porte, der sender arbejde baglæns. En release kan bruge én dag i test og alligevel miste en uge, fordi en fejlet test sender den tilbage til et rettetrin, og forløbet kører igen. Måden at se det på er at tegne processen med dens beslutninger og tælle, hvor mange releases der tager hver udgang.
Et rutediagram giver strukturen: hver beslutning har labelede grene, og hver gren har et antal. Eksemplet er en release-proces med fire beslutninger: automatiske tests, go eller no-go, produktionens tilstand og fejl i produktion. Når du har antal pr. gren, viser et Sankey-diagram dem som bredder. Se /da/sankey/ci-pipeline-outcomes for build-trinnet og /da/sankey/pull-request-review-flow for det reviewtrin, der kommer før.
Hold påstandene beskedne. Antal viser, hvor arbejdet forlader en port, ikke hvorfor. Årsagen får du ved at læse de fejlede punkter og af de mennesker, der driver porten.
En release-proces, bygget i trin
Tyve trin og fire beslutninger. Hver beslutning er et sted, hvor et Sankey-diagram ville vise arbejde forlade processen i to retninger.
Build og automatiske tests
Processen starter ved Koden er færdig til release, fryser omfanget og kører de automatiske tests. Den første beslutning, "Består de automatiske tests?", har en gren Fejlet, der løber tilbage gennem trinnet "Ret fejl på release-branchen" til buildet. Den løkke er det første sted at tælle.
Staging, godkendelse og go-beslutningen
Et build, der består, går til staging, regression og UAT, og dokumentationen for release-parathed samles og godkendes. "Go eller no-go?" har en gren No-go, der vender tilbage til rettetrinnet, så en release kan komme tilbage sent i processen.
Produktion og vejen tilbage
Releasen deployes i sit vindue og smoke-testes. "Er releasen sund?" deler sig til overvågning eller til en tilbagerulning, der vender tilbage til rettetrinnet. En tilbagerulning er den dyreste udgang, så dens antal betyder mest.
Overvågning og hotfix
Efter soak-perioden sender "Fejl fundet i produktion?" releasen til en hotfix, som går ind igen ved deployment, eller til release notes og lukning. Tæl, hvor ofte hotfix-grenen tages.
Sådan fungerer det
Tegn processen med dens beslutninger
Sæt hver port ind som en beslutning med labelede udgange, fx Bestået og Fejlet. En port tegnet som et almindeligt trin skjuler den udgang, du vil tælle.
Vælg en periode og en enhed
Tag det seneste kvartal, og tæl releases, eller builds, hvis du releaser ofte. Angiv hvilken i datanoten.
Tæl, hvad der forlader hver beslutning
For hver beslutning tæller du, hvor mange punkter der tog hver udgang. Tag tallene fra dit CI-system, dine tickets eller din release-log.
Tegn antallene som et Sankey-diagram
Brug beslutningerne som noder og udgangene som strømme. Kontrollér, at det, der kommer ind i hver node, er lig med det, der forlader den.
Læs den bredeste returgren først
Den bredeste gren, der peger baglæns, er den sandsynlige flaskehals. Læs de punkter igennem for at finde ud af hvorfor.
Faldgruber du skal undgå
Kun at tælle det endelige udfald
Hvis du kun tæller det, der blev leveret, forsvinder løkkerne. Tæl ved hver beslutning, ellers viser Sankey-diagrammet en glat proces, der ikke fandt sted.
At blande enheder
Builds, releases og tickets er forskellige enheder. Vælg én til hele diagrammet, og skriv det.
At læse antal som årsager
En bred gren Fejlet siger, at tests ofte fejler, ikke hvorfor. Se på de fejlede punkter, før du ændrer processen.
Åbn rutediagrammet for software release
Åbn release-skabelonen, tilpas portene til dine egne, og tæl udgangene.
Relaterede guides
Ofte stillede spørgsmål
Hvorfor tegne et rutediagram, hvis jeg kun vil have et Sankey-diagram?
Fordi rutediagrammet afgør, hvad noderne er. Uden det viser Sankey-diagrammet de trin, dit værktøj tilfældigvis eksporterer, og de er ofte ikke de porte, folk beslutter ved.
Hvor mange releases har jeg brug for?
Nok til, at hver udgang har mere end få punkter. Med færre end omkring 20 bør du vise antallene i en tabel frem for et diagram.
Erstatter det måling af gennemløbstid?
Nej. Gennemløbstid siger, hvor lang tid; Sankey-diagrammet siger, hvor arbejdet forlader eller vender tilbage. Brug begge, og sammenlign dem for den samme periode.