Feature Name Description
A common approach: one microservice, one repository
  1. Apply Domain-Driven Design to plan how to break up the monolith into services.
  2. A separate repository is created for each microservice (where the “multi” in multirepo comes from).
  3. 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
  1. In each repo, tag the versions of microservices that will go into the release.
  2. For each microservice, build a Docker image and map the microservice version to the image tag.
  3. Test the release candidate in a separate test environment. This usually involves a mix of integration testing, acceptance testing, and perhaps some manual testing.
  4. Go over every repository and compile a list of changes for the release changelog before updating the documentation.
  5. Identify hotfixes required for older releases.
  6. 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