This article is also available in:
We distinguish three types of changes: bugs, features and infrastructure or system maintenance changes. The initial stage is different for each change but they share all the same development, test, and deploy process.

Customer reported bugs
Whenever a bug is reported to our customer service, that bug is reported in our internal service desk. From the internal service desk the bug is validated by the QA team. Valid bugs are then escalated to our devsupport1 team which handles bugs. From that moment on, they follow the same development process as new features.

Features from the road map that are selected for development are written out in acceptance criteria by the product manager. Before the feature is implemented the feature is discussed and refined by all involved teams.

Infrastructure and/or system maintenance
There are several reasons that cause a change in our infrastructure/system.

There are security updates for third party software our product depends on.
There are new versions for third party software our product depends on.
Changes in infrastructure/system are needed to improve our product or work processes.

These changes that are selected for development are then discussed and then implemented by our development team, in the same fashion as features are done. Given our secure development policy we give a priority to security updates.

Development process
The process has the following stages:

Discussion: The acceptance criteria are written out/improved for the intended change. This ensures that everyone who is working on the feature/change knows what is the intended end result. We aim to make many small improvements over large changes.
Development: at least two developers work on the code. We use test driven development. We test our code with automated unit, integration, functional and acceptance tests. All new and existing tests are required to pass before going to the code review step.
Code review: all changes are reviewed by at least one other developer who didn’t work on the code. Here we verify whether the code is up to the standards. We use the OWASP top102 to check for vulnerabilities. The change cannot pass into the next stage until all feedback is resolved and all code changes have been re-reviewed.
Quality Assurance: The changes are tested by the QA team. If the changes fail to meet the acceptance criteria, accessibility standards or has other problems, the whole process returns to the development stage.
Merge: All changes are merged into the development version of our product.
Release: We release a new version of our software daily:
We put the latest development version on our staging environment for testing.
We run the acceptance test on the whole application.
If everything passes, we deploy all changes to production.

The devsupport team is a team of developers that helps with the support of our product. Most of our bugs are solved by this team.
The OWASP top10 is a list of the most common vulnerabilities. An list can be found on the OWASP website:||
Was this article helpful?
Thank you!