Change Management and Release Process for Microservices

Ishan Liyanage
2 min readJul 20, 2021

One of the main reasons to go with Microservices Architecture is to roll out upgrades with minimum to no-impact for the running system and rolling out upgrade more frequently with Agile way. This could be daily or weekly or may be many times per day depending on criticality of the system.

If we are following Microservices guidelines to architecture, we can embark on more agile release management process. Moving release process to Microservices continuous delivery when each service is ready will speed up the things and help to increase scalability and productivity aspect of the development process.

If you are familiar with below points, then you might still following Monolith change management and release process,

Probable Issues

  1. Take changes as whole and freeze the code at the end of the development cycle, regardless of when they are fully done.
  2. Maintain same version for all the services.
  3. Having lengthy integration testing running for each and every minor change.
  4. No having dedicated personnel to handle frequent releases. Resource constraint can lead to minimize release frequency.
  5. There is a single product manager or one QA team that defines requirements for new features and implements tests for the system.
  6. The current release requires a downtime.
  7. Non maintenance of API versioning and backward compatibility.
  8. Tight coupling of some of the services.
  9. To many environments to maintain i.e dev, integration, staging, preprod, prod.
  10. Not following comprehensive CI/CD process.

How to Improve

  1. We can include product management (in terms of gathering requirements and documenting user stories), proper/dedicated QA and dedicated release/migration team(s). That is to have self-sufficient cross-functional teams.
  2. We have to consider backward compatibility of API and maintain API versioning.
  3. Need to identify tightly coupled services. Need to increase service autonomy. This way we do not need run integration testing involving many cross services. Even we can stub or mock most of the coupled integrations.
  4. We can reduce the number of env e.g we can use one env for…
Ishan Liyanage

Passionate Technical Lead, Senior Software Developer and free and open source software advocate. Based in Singapore.