Dit artikel is ook beschikbaar in:
Dit artikel is vertaald met behulp van machinevertaling. Hierin zijn mogelijk foutieve of vreemde vertalingen aanwezig. Vooralsnog denken we dat het waardevol is om dit hulpartikel in jouw moedertaal te kunnen lezen. Laat ons onderaan het artikel weten of het artikel nuttig was en of je nog andere feedback voor ons hebt.

We onderscheiden drie soorten veranderingen: bugs, features en veranderingen in infrastructuur of systeemonderhoud. Het beginstadium is voor elke verandering verschillend, maar ze delen allemaal hetzelfde ontwikkelings-, test-, en ontplooiingsproces.

Door klanten gemelde bugs
Telkens als een bug aan onze klantendienst gemeld wordt, wordt die bug in onze interne servicedesk gemeld. Vanuit de interne servicedesk wordt de bug gevalideerd door het QA team. Geldige bugs worden dan geëscaleerd naar ons devsupport1 team dat bugs afhandelt. Vanaf dat moment volgen ze hetzelfde ontwikkelingsproces als nieuwe functies.

Features
Features van de routekaart die voor ontwikkeling geselecteerd worden, worden door de product manager uitgeschreven in acceptatiecriteria. Voordat de eigenschap wordt uitgevoerd wordt ze door alle betrokken teams besproken en verfijnd.

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

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

Deze veranderingen die voor ontwikkeling worden uitgekozen, worden dan besproken en vervolgens door ons ontwikkelingsteam uitgevoerd, op dezelfde manier als functies worden gedaan. Gezien ons veilige ontwikkelingsbeleid geven we prioriteit aan beveiligingsupdates.

Ontwikkelingsproces
Het proces kent de volgende fasen:

Discussie: De acceptatiecriteria worden uitgeschreven/verbeterd voor de beoogde verandering. Dit zorgt ervoor dat iedereen die aan de eigenschap/verandering werkt weet wat het beoogde eindresultaat is. We streven naar veel kleine verbeteringen boven grote veranderingen.
Ontwikkeling: minstens twee ontwikkelaars werken aan de code. We gebruiken testgestuurde ontwikkeling. We testen onze code met geautomatiseerde unit, integratie, functionele en acceptatietests. Alle nieuwe en bestaande tests moeten slagen voor ze naar de code review stap gaan.
Code review: alle veranderingen worden nagekeken door minstens één andere ontwikkelaar die niet aan de code gewerkt heeft. Hier controleren we of de code aan de normen voldoet. We gebruiken de OWASP top102 om op kwetsbaarheden te controleren. De verandering kan niet naar de volgende fase overgaan voordat alle feedback is opgelost en alle code veranderingen opnieuw zijn bekeken.
Kwaliteitsborging: De veranderingen worden getest door het QA team. Als de veranderingen niet voldoen aan de acceptatiecriteria, de toegankelijkheidsnormen of andere problemen hebben, gaat het hele proces terug naar het ontwikkelingsstadium.
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.
We voeren de acceptatietest uit op de hele toepassing.
Als alles slaagt, zetten we alle veranderingen in productie.

Opmerkingen
Het devsupport team is een team van ontwikkelaars dat helpt bij de ondersteuning van ons product. De meeste van onze bugs worden door dit team opgelost.
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 !