Release management

Release management is the process of versioning changes and moving new versions through all environments. Each environment has its characteristics and purpose. Additionally it’s important to have good release notes to track all the changes throughout the software lifecycle.

Environments

Production environment

Our production environment is the most important environment. It houses paying customers and holds sensitive data. Security is a great concern here.

The requirements of this environment are

  • Performance: the cluster that supports this environment will be larger and faster to assure smooth and fast operation for our customer
  • Stable software versions: Only stable software will be released here. No alpha, beta or other unofficial software is allowed.
  • Client only: No test, demo, development client frontends are allowed here
  • Backup: Intensive backup strategies will be used to safe guard client data
  • Scalability: The cluster will allow for autoscaling to support even the most intensive workloads
  • Security: Security in this cluster will be tested and improved to provide trust towards our clients
  • Monitoring & alerting: this environment will have extensive monitoring and alerting so smooth operation can be assured
  • Availability: this environment strives towards 99,889% availability
  • Rolling release: Release will be done without downtime

Test/staging/acceptance environment

A test environment is used for end-to-end testing. New releases are prepared through the test environment. This environment will contain meaningful data. Testers will test the application as it would be used by customers.

This environment will contain the latest versions that are considered to be released to production. Therefor it is also ideal for demo environments.

Data management in this environment will be handled differently. To provide a controlled environment the dataset used will be defined as a standard. This dataset will be reset periodically to assure consistency while testing, and provide a standard state for demos.

Characteristics of the environment are:

  • Data:
    • GDPR compliant data will be used
    • Meaning full data is required
    • Data will be reset periodically
    • Data will be provided by business
  • Beta software: beta software will be used when available for a given component. In other cases the latest stable release will be used.
  • Backup: on a data level datasets will be used, those datasets will be backed up and restored on a given interval
  • Clients:
    • No production data is allowed
    • Customer test environments can be hosted here
    • Demo environments must be hosted here
    • Test environments must be hosted here
  • Testing:
    • Automated integration testing will be done continuously
    • Automated smoke testing will be done continuously
    • Testers will manually test and confirm release requirements
    • Testers will expand the automated tests to account for new functionality
  • Scalability / availability: This environment will have limitations on scaling to prevent unnecessary costs
  • Rolling releases: changes to this environment will be created automatically when new beta packages are created

Development environment

When developers create new features and push changes to the develop branch, new alpha releases are automatically created. These releases will make sure the development environment is always in the latest state containing all changes. This allows developers to test their features in the context of other components.

  • Data: data here will not represent real data. Developers use this to test functionality hundreds of times. To maintain and manage realistic data would only slow down the development process. Its the responsibility of the testers to do end-to-end testing.
  • Alpha software: this environment will run only alpha software.
  • Backup: this environment will not be backed up
  • Clients:
    • Developers will setup clients as is needed, conform their development requirements
  • Scalability / availability: This environment will have strict limitations on scaling to prevent unnecessary costs
  • Rolling releases: changes to this environment will be created automatically when new alpha packages are created

Standards

Semantic Versioning

We are using semantic versioning. This technique is used in almost all modern software from your browser, to version of the operating system on your phone.

0%20xsq-RIRjgdBskKwB.png 0%20xsq-RIRjgdBskKwB.png

More information about semantic versioning can be found here:

https://semver.org/lang/nl/

Git-flow

Git flow is a strategy on how to handle code changes and updates to software. To achieve the semantic versioning, git flow is used to handle code in the source control system.

1%209yJY7fyscWFUVRqnx0BM6A.png 1%209yJY7fyscWFUVRqnx0BM6A.png

More information can be found here: https://www.atlassian.com/git/tutorials/comparing-workflows/gitflow-workflow

Git-ops

Git ops is a technique, where code changes result in deployable containers. Secondly the desired state of an environment is defined in code. When there is a delta between the desired state and the actual state in the environment, git ops will reconcile these changes until the desired state is achieved.

Pasted image 20240530155228.png Pasted image 20240530155228.png

Conventional commits

Tracking the changes we make in code and creating meaningful release notes can be very tedious. We will be using a technique called conventional commits to create release notes automatically.

To achieve good release notes, programmers and release managers will add simple keywords to each commit message. These keywords will be parsed on releasing the software and will be converted into meaningful release notes automatically.

1 6NqkGS0Jwv5Pwhv_LOC3yQ.webp 1 6NqkGS0Jwv5Pwhv_LOC3yQ.webp

Information about conventional commits can be found here: https://www.conventionalcommits.org/en/v1.0.0/

Implications

Project management

Every part of the application is managed and released without context to another. Meaning they can be developed separately. This has these advantages:

  • Projects become smaller and more manageable
  • Project teams become smaller and allow for better planning
  • Smaller teams allows for easier alignment
  • Output of an API project becomes the input/analysis for a frontend project
  • Projects can be outsourced more easily
  • Smaller projects have more reliable plannings
  • Backends allow for integrations even when frontend is not ready