| A common approach: one microservice, one repository |
- Apply Domain-Driven Design to plan how to break up the monolith into services.
- A separate repository is created for each microservice (where the “multi” in multirepo comes from).
- Each repository has an independent CI/CD pipeline to continuously deploy the microservice to production.
|
Maintaining multiple microservices releases
|
Ability to rollback the whole release
- In each repo, tag the versions of microservices that will go into the release.
- For each microservice, build a Docker image and map the microservice version to the image tag.
- Test the release candidate in a separate test environment. This usually involves a mix of integration testing, acceptance testing, and perhaps some manual testing.
- Go over every repository and compile a list of changes for the release changelog before updating the documentation.
- Identify hotfixes required for older releases.
- Publish the release.
|
| Blue-green Deployment |
Pivotal/Google. Master version is Blue, new version is green.
- Deploy green version with different path. Test
- Share path between Blue and Green. Test.
- Stop the blue, Green becomes blue
|
| Rolling Updates in Kubernetes |
- Creates new Replica Set in Deployment
- Crete new pods - one pod at a time
- Decrease number of pods in the old Replica Set
- Continue until all pods up and running sucess
- In case of error - no new pods created, old app is in place
|
| Liveliness and Readiness probes |
To avoid Downtime during update you can configure probes provided by Actuator (after 2.3):
- Liveliness - if probe is not successful, pod is restarted /health/liveliness
- Readyness - if probe is not successful, no traffic is sent to pod /health/readiness
Configured in deployment.yaml
|