TICKET TRACKING
Wolfpack werkt bij alle projecten standaard met Atlassian Jira als issue tracking systeem. Jira is een wijd gebruikte projectmanagement tool die een agile werkwijze perfect ondersteunt. IT development gebeurd op basis van zogenaamde tickets waarmee kleine afgebakende blokken werk gedefinieerd worden. Binnen Wolfpack wordt als uitgangspunt een ticket template gebruikt. Per project wordt de meest geschikte workflow vastgesteld, waarin gekeken wordt naar diverse controle stappen, reviews en Q.A.s die nodig zijn in het proces. Hierdoor zijn alle ontwikkelaars gewend op dezelfde manier te werken, ongeacht met wie of aan welk project ze werken.
werkwijze tickets
Er wordt altijd gewerkt vanuit een BACKLOG, dit is een geprioriteerde lijst van werkzaamheden voor het development team die is afgeleid van de roadmap en de bijbehorende eisen. De belangrijkste items worden bovenaan de BACKLOG getoond, zodat het team weet wat de meeste prioriteit heeft. Voordat er gestart wordt met de ontwikkeling worden de tickets van de BACKLOG uitvoerig besproken en afhankelijk van de capaciteit uit de BACKLOG gehaald.
Zo worden tickets aan de start van elke sprint vanuit de BACKLOG naar de TO DO kolom verplaatst. Per sprint worden tickets van inschattingen voorzien. Tickets die opgepakt worden door developers komen in de IN PROGRESS kolom en worden na afronding verplaatst naar de REVIEW / QA kolom. Middels Jira wordt geforceerd dat developers eigen tickets niet naar STAGING kunnen verplaatsen. Afgeronde tickets worden namelijk eerst inhoudelijk gereviewed en getest door een collega, doorgaans de lead developer. Tijdens een review wordt gekeken naar de code quality, of standaarden juist gebruikt zijn, en of de code voldoet aan beveiligingseisen. Goedgekeurde tickets worden verplaatst naar STAGING en komen beschikbaar in de testomgeving. Tickets die vervolgens zijn goedgekeurd en naar DONE versleept worden komen in productie bij de eerstvolgende release.
ontwikkelstraat
Wolfpack werkt standaard met drie ontwikkelomgevingen:
DEVELOPMENT
STAGING
Productie
Deze drie omgevingen worden gehost op separate servers met gescheiden databases.
De staging omgeving is een bijna exacte replica van een productieomgeving voor het testen van software. Onze staging omgevingen zijn gemaakt om codes, builds en updates te testen om de kwaliteit te waarborgen in een productie-achtige omgeving voordat de daadwerkelijke release plaatsvindt. De staging omgeving vereist een kopie van dezelfde configuraties van hardware, servers, databases en caches. Alles in een staging omgeving moet zo dicht mogelijk bij de productieomgeving liggen om ervoor te zorgen dat eventuele problemen opgelost worden voordat er naar productie wordt geupdate.
releaseproces
Middels standaard Gitflow, uitgebreid met een staging branch, wordt de code beheerd. Elke ontwikkelomgeving haalt respectievelijk code van de development, staging en master branch. Het mergen van code met deze branches kan alleen met goedkeuring van de lead developer die alle merge requests controleert en moet accepteren.
