Change Management and Release Process for Microservices
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
- Take changes as whole and freeze the code at the end of the development cycle, regardless of when they are fully done.
- Maintain same version for all the services.
- Having lengthy integration testing running for each and every minor change.
- No having dedicated personnel to handle frequent releases. Resource constraint can lead to minimize release frequency.
- There is a single product manager or one QA team that defines requirements for new features and implements tests for the system.
- The current release requires a downtime.
- Non maintenance of API versioning…