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…

--

--

Ishan Liyanage
Ishan Liyanage

Written by Ishan Liyanage

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

No responses yet