Release-proces van het team
De eerste stap bij het opzetten van een DevOps-oefening is om het huidige proces te beoordelen. Dit betekent analyseren:
- Uw bestaande artefacten, zoals implementatiepakketten en NuGet, evenals uw containeropslagplaatsen.
- Uw bestaande hulpprogramma's voor testbeheer.
- Uw bestaande hulpprogramma's voor werkbeheer.
- Migratie- en integratiestrategieën aanbevelen.
Laten we dat doen met het Tailspin-team, en kijken hoe DevOps daarbij kan helpen.
Nadat Irwin de productmanager weg is gegaan, zegt Amita: "We hebben hulp nodig. Ik weet niet wanneer deze oplossingen klaar moeten zijn, maar ik weet wel dat het al gauw is. We zijn niet berekend op een snelle doorlooptijd. Bovendien moet de nieuwe Space Game-website wachten tot we deze rommel hebben opgelost, en dat spel komt snel naar boven."
Andy kijkt naar Mara. "Dit is veel om in te nemen tijdens uw eerste paar weken."
"Dat is geen probleem", antwoordt Mara. "Misschien kun jij me uitleggen hoe de dingen hier werken. Hoe gaat een game van ontwikkeling naar productie?"
"Dat is een goede vraag", zegt Andy. "Ik weet niet zeker of we u een eenvoudig antwoord kunnen geven, maar laten we het proberen."
Het team besluit om naar een coffeeshop te gaan om te ontspannen en een informele discussie te voeren. Ze gaan samen proberen te achterhalen waarom ze zoveel problemen hebben.
Tijdens het koffiedrinken luistert Mara en probeert ze aantekeningen te maken. Er is veel informatie, en die is niet netjes georganiseerd. Haar algemene ideeën over het team zijn:
- Ze gebruiken een waterval-benadering. Het management stelt de prioriteiten. Ontwikkelaars schrijven code en sturen de build naar de kwaliteitscontrole (QA). QA test, en stuurt de build naar operations voor implementatie.
- De watervalbenadering kan acceptabel zijn voor een klein team, maar hier zijn de doelen niet altijd duidelijk en lijken ze regelmatig te veranderen.
- Testen vindt pas laat in het proces plaats. Dat betekent dat het moeilijker en duurder is om bugs op te lossen en wijzigingen aan te brengen.
- Er is geen duidelijke definitie van wat er gedaan is . Elk teamlid heeft een eigen idee. Er is geen algemeen bedrijfsdoel waar iedereen het mee eens is.
- Sommige code zit in een gecentraliseerd versiebeheersysteem. Veel hulpprogramma's en scripts bevinden zich alleen op netwerkbestandsshares.
- Er zijn veel handmatige processen.
- Communicatie is ongeregeld en is afhankelijk van e-mail, Word-documenten en spreadsheets.
- Feedback is ook weinig frequent en inconsistent.
- Aan de pluszijde lijkt het team goed te zijn en willen ze het beter maken.
Als ze naar haar stapel aantekeningen kijkt, weet Mara dat ze al deze informatie moet ordenen. Door dat te doen, zal het gemakkelijker zijn de processen te evalueren. Ze is ervan overtuigd dat een DevOps-aanpak veel van de problemen van het team zal oplossen, maar ze heeft een manier nodig om haar zaak aan het team te presenteren.
Een DevOps-praktijk begint vaak met het begrijpen van uw bestaande processen. Van daaruit kunt u evalueren wat goed werkt, wat niet, en focussen op wat eerst moet worden opgelost.
Mara vraagt: 'Hebt u ooit een oefening voor waardestroomtoewijzing gedaan?'
Andy rolt met zijn ogen, Amita zucht en Tim zegt: "We hebben geen behoefte aan meer administratie".
Mara zegt: "Ik snap het. Laat het maar aan mij over."
Iedereen laat het graag aan de nieuweling over en gaat weer aan het werk.