Dit artikel is ook beschikbaar in:
We onderscheiden drie soorten wijzigingen: bugs, functies en wijzigingen in de infrastructuur of het systeemonderhoud. De beginfase is voor elke verandering anders, maar ze hebben allemaal hetzelfde ontwikkelings-, test- en implementatieproces.

Klant meldde bugs
Wanneer een bug wordt gemeld bij onze klantenservice, wordt deze gemeld in onze interne servicedesk. Vanaf de interne servicedesk wordt de bug gevalideerd door het QA-team. Valideerde bugs worden vervolgens geëscaleerd naar ons devsupport1 team dat bugs afhandelt. Vanaf dat moment volgen ze hetzelfde ontwikkelingsproces als de nieuwe features.

Functies
Functies uit de routekaart die worden geselecteerd voor ontwikkeling worden door de productmanager uitgeschreven in acceptatiecriteria. Voordat de functie wordt geïmplementeerd, wordt deze door alle betrokken teams besproken en verfijnd.

Infrastructuur en/of systeemonderhoud
Er zijn verschillende redenen die een verandering in onze infrastructuur/systeem veroorzaken.

Er zijn beveiligingsupdates voor software van derden waarvan ons product afhankelijk is.
Er zijn nieuwe versies voor software van derden waar ons product van afhankelijk is.
Veranderingen in de infrastructuur/systeem zijn nodig om ons product of werkprocessen te verbeteren.

Deze veranderingen die worden geselecteerd voor ontwikkeling worden vervolgens besproken en vervolgens geïmplementeerd door ons ontwikkelingsteam, op dezelfde manier als de functies worden uitgevoerd. Gezien ons veilige ontwikkelingsbeleid geven we prioriteit aan beveiligingsupdates.

Ontwikkelingsproces
Het proces kent de volgende stadia:

Discussie: De acceptatiecriteria zijn uitgeschreven/verbeterd voor de beoogde verandering. Dit zorgt ervoor dat iedereen die aan de functie/verandering werkt weet wat het beoogde eindresultaat is. We streven ernaar om veel kleine verbeteringen aan te brengen ten opzichte van grote veranderingen.
Ontwikkeling: minstens twee ontwikkelaars werken aan de code. We maken gebruik van testgedreven ontwikkeling. We testen onze code met geautomatiseerde unit, integratie, functionele en acceptatietests. Alle nieuwe en bestaande testen zijn nodig om te slagen voordat we naar de code review stap gaan.
Code review: alle wijzigingen worden beoordeeld door ten minste één andere ontwikkelaar die niet aan de code heeft gewerkt. Hier controleren we of de code voldoet aan de standaarden. We gebruiken de OWASP top102 om te controleren op kwetsbaarheden. De verandering kan niet doorgaan in de volgende fase totdat alle feedback is opgelost en alle codewijzigingen opnieuw zijn bekeken.
Kwaliteitsborging: De veranderingen worden getest door het QA team. Als de wijzigingen niet voldoen aan de acceptatiecriteria, de toegankelijkheidsnormen of andere problemen hebben, gaat het hele proces terug naar de ontwikkelingsfase.
Samenvoegen: Alle wijzigingen worden samengevoegd in de ontwikkelingsversie van ons product.
Vrijgave: We brengen dagelijks een nieuwe versie van onze software uit:
We zetten de nieuwste ontwikkelingsversie op onze staging omgeving om te testen.
2. We voeren de acceptatietest uit op de hele applicatie.
3. Als alles geslaagd is, zetten we alle wijzigingen in de productie in.

Opmerkingen
Het devsupportteam is een team van ontwikkelaars dat helpt met de ondersteuning van ons product. De meeste van onze bugs worden door dit team opgelost.
2. De OWASP top10 is een lijst van de meest voorkomende kwetsbaarheden. Een lijst is te vinden op de OWASP-website: https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project||
Was dit artikel behulpzaam ?
annuleren
Dank je wel !