Re:The Tools We Use To Stay Afloat
by jameshart on Saturday May 13, 2017 @04:05PM
(#14332732)
We're doing the same for microservice deployments to kubernetes, using Jenkins' multibranch pipeline - Jenkins just watches the git repo, and any commit to a branch that contains a Jenkinsfile gets built. At the end of the build process, we publish a docker image tagged with the branch and build number, and then use helm to upgrade or create a deployment in a kubernetes cluster, tagged to run the just-published docker image. Our cluster's running in AWS and has a package deployed to it called 'area53' which can set up route 53 DNS records for kubernetes services automatically.
Upshot of all that is that if you create and push a new branch called 'foo', a few minutes later that branch's code is up and running in AWS, under the name 'service-foo.dev.example.com'. We can then automatically run integration tests against that endpoint.
Best part is that the build process defined by the jenkinsfile, and the deployment defined by the helm chart, all live in the source, so you can play with them on a branch. Want to add another testing step to the build process? Branch, add it to the jenkinsfile, and your build pipeline change gets executed just for your branch, without stopping other branches from building. Once you're happy with the addition, merge the change and now every future branch gets that extra deployment step. Likewise if you modify the deployment chart, you can test it in a branch.
Upshot of all that is that if you create and push a new branch called 'foo', a few minutes later that branch's code is up and running in AWS, under the name 'service-foo.dev.example.com'. We can then automatically run integration tests against that endpoint.
Best part is that the build process defined by the jenkinsfile, and the deployment defined by the helm chart, all live in the source, so you can play with them on a branch. Want to add another testing step to the build process? Branch, add it to the jenkinsfile, and your build pipeline change gets executed just for your branch, without stopping other branches from building. Once you're happy with the addition, merge the change and now every future branch gets that extra deployment step. Likewise if you modify the deployment chart, you can test it in a branch.