K
Q

Continuous Delivery - Microservices Release/Versioning

4/27/2018

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:

  • Service A --> Build --> Package --> QA --> Staging --> Production
  • Service B --> Build --> Package --> QA --> Staging --> Production
  • Service C --> Build --> Package --> QA --> Staging --> Production

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):

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

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?

-- Jack
continuous-delivery
docker
jenkins
kubernetes-helm
microservices

Similar Questions

Kubernetes Engine unable to pull image from non-private / GCR repository
Feasibility of docker Image deploying without dockerhub.com and Using in Jenkins
Kubernetes create private namespace/domain (FQDNs)
salt-master not working yet error while setting up kubernetes cluster on aws ec2 instance
User \"system:anonymous\" cannot get path \"/\"

2 Answers

4/27/2018

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

-- Luc
Source: StackOverflow
5/3/2018

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.

-- itaysk
Source: StackOverflow