CODEWITHSUNDEEP
dockerjenkinsmicroservicescontinuous-deliverykubernetes-helm
Jack
Jack

Reputation: 427

Continuous Delivery - Microservices Release/Versioning

We are developing Microservices using Spring Boot which are than packaged up as Helm Charts and deployed onto a Kubernetes cluster. Each service has a Jenkinsfile and we have been releasing each service individually below:

This approach is fairly straight forward but it doesn't actually give you a shippable artifact and you end up with inconsistencies.

What we would like to do is group the release using an umbrella Helm chart shown below (Parent A):

I'm struggling to think of a way to do this without having to manually release each service, then update the versions in the parent chart. Is anyone doing this in an automated way?

Upvotes: 1

Views: 1600

Answers (2)

itaysk
itaysk

Reputation: 6236

I can share a simplified view on how we ship code Codefresh:

  • each microservice has it's own git repo and helm chart.
  • each service codebase is versioned (regardless of the chart), for example in package.json.
  • each helm chart is also versioned.
  • When devs update services, they must bump the version in the code.
  • We also have one Helm uber-chart that lists all of the microservices charts as chart requirements.
  • CI pipeline on the code repo builds a docker image (tagged with the code version) and a helm chart (tagged with the code version). This doesn't deploy anything yet.
  • If a dev wants to deploy, they edit the requirements file in the uber-chart, requiring the new version.
  • CD pipeline on the uber-chart does a helm upgrade.

This is a very simplified description. In reality the pipeline also does stuff like:

  • auto handling of npm and github releases
  • gates based on semver scope of update
  • automatic provisioning of ad-hoc environments on PR/branch (spin up a new environment to test/share your change)
  • secret management

To be honest this is not a simple pipeline, but hey, we are a CI/CD company so this is our bread and butter.
We are often asked by customers to share more about the work we've done, and even replicate it for a customer, which we happily do. Feel free to ping me.

Upvotes: 2

Luc
Luc

Reputation: 1433

If I understand well your problem, you could solve it by using the Jenkins multijob plugin. And without updating your current existing job.

Your workflow would look like:

Parent Job
    Service A --> Build --> Package --> QA --> Staging --> Production
    Service B --> Build --> Package --> QA --> Staging --> Production
    Service C --> Build --> Package --> QA --> Staging --> Production

Where your parent job trigger all your child jobs.

I have seen a similar problem solved this way. Also sometime your child service must be released together, or one of your service must always be ahead (server). You can add some python/shell validation scripts in your parent job in order to make sure that your final product is always releasable.

https://wiki.jenkins.io/display/JENKINS/Multijob+Plugin

Upvotes: 0

Related Questions