Changes are made to the information technology systems in a seven-step process.

1. Change Initiator Identifies Feature Requirement (Need for Change)

The requirement for a change or new feature can be initiated by “the business” or an end-user; the “change initiator”. The requirement is captured in the shared “backlog” (GitHub issues) with as much detail as possible.

Preferably the requirement should be described in the form of a “user story” or “bug report” to ensure adequate detail is captured.

Occasionally an opportunity for change/improvement will be identified by a member of the development team. In this case at least one other member of the team must confirm the opportunity for change/improvement has business/user value before it can proceed to prioritisation.

2. Confirmation of Need & Requirement from Stakeholders

Once the change/feature/bug has been identified and described (in step 1) we require confirmation from at least one other stakeholder. This is to ensure that non-essential changes cannot be made on a whim.

3. Work Prioritisation

All features are prioritized by “product owner” (or “the business” / management team).

4. Change Performed by Technical Team

The work of building the feature or preparing the change is performed by a member of the development team.

Developer Checklist

  • Unit, End-to-End and/or Acceptance Test is written
  • Feature/change is built according to precise requirements and no other additions/removals made
  • Descriptive Git Commit Message with reference (link) to issue
  • Ensure all pre-commit checks/tests pass locally before pushing to Continuous Integration (CI) Environment
  • Push to CI
  • Create “Pull Request” (with batch of changes)
  • Assign for request for peer review

5. Peer Review

The code is reviewed by peers (a distinct team member) and improvements suggested. When code is deemed good, approval is given.

6. Quality Assurance Review

QA reviews the change and either requests changes or approves and merges into the staging branch. All these merged changes get automatically deployed to our staging environment. During QA the reviewer will take following points into account:

  • Code quality (complexity, readability, …)
  • Does the solution cover the entire use case as described in the issue
  • Security
  • Documentation
  • Health checks if needed

7. Release to Production

Once all preceding steps are complete, a member of the management team must sign off on the release and the release is deployed to Production. All new product improvements and features also get published on our SaaS product changelog.

Client impacting changes

If we are planning to do changes that impact the service of one or more of our clients, the clients will be notified by email about this event at least one week before the change.