Continuous Integration in the workflow

[Cryptophobia]

From @pdoreau on August 24, 2016 10:36

Hi. How to include an automated test phase (CI-like) in the workflow ? Would that be possible, recommended or not ?

Copied from original issue: deis/workflow#470

[Cryptophobia]

From @bacongobbler on August 24, 2016 15:32

Hey @pdoreau, are you interested in introducing this as a new feature, or just looking for advice on how to roll out CI with Workflow on your own? If the latter, how most users have been accomplishing a CI workflow with Workflow (heh) is by using their CI/CD pipeline of choice to build, test and publish their docker image to a registry, then once it has passed through QA they use deis pull to use that image release as the new image for the application.

Does that give you a general idea how to accomplish this? Always happy to help!

[Cryptophobia]

From @pdoreau on August 24, 2016 19:52

Well, I'm discovering Workflow so I can't say if this would be an interesting feature or not. Thanks @bacongobbler it does give me a general idea. Is such a thing documented somewhere ?

[Cryptophobia]

From @bacongobbler on October 12, 2016 15:57

Sorry for not getting back to this question sooner. There's no explicit documentation on getting this set up, however you can take a look at our current infrastructure and see how we set up our jenkins jobs for deployments!

https://ci.deis.io/ https://github.com/deis/jenkins-jobs

Let me know if you have any more questions.

[Cryptophobia]

From @olalonde on October 20, 2016 3:45

@bacongobbler a blog post or official documentation on this would be really great.

Here's some things I'd like to see addressed:

1) I've got a few apps that don't have a Dockerfile and some use .buildpack files. How do I tell my CI/CD tool to build the image similarly to how deis-builder does.

2) How to avoid duplicating configuration (environment) variables between my deis app and the CI/CD tool. For example, I have a JavaScript/Node.js app that needs access to GOOGLE_ANALYTICS_CODE at both build and run time. Maintaining configuration variables in both the CI/CD tool and deis app is prone to error.

3) If the CI/CD tool requires access to a Docker registry, is it possible to re-use the deis-registry for this purpose?

The more I think about it, the more I feel like moving to a CI/CD workflow would eat into much of what Deis has to offer (except perhaps for routing + scaling) and I'm left wondering if I shouldn't just use CI/CD tool + Kubernetes directly.

[Cryptophobia]

From @seanknox on October 20, 2016 4:39

2) How to avoid duplicating configuration (environment) variables between my deis app and the CI/CD tool. For example, I have a JavaScript/Node.js app that needs access to GOOGLE_ANALYTICS_CODE at both build and run time. Maintaining configuration variables in both the CI/CD tool and deis app is prone to error.

@olalonde A common practice is use an .env file containing all of your app's required configuration with development-only/test settings. On your deployed (live) apps, you'll use a different configuration set.

3) If the CI/CD tool requires access to a Docker registry, is it possible to re-use the deis-registry for this purpose?

Short answer: yes. Slightly longer answer: Deis's internal registry manages the images generated from the builder component (e.g. from a git push), so you probably don't want to use it directly as your primary image store. Instead, use an off-cluster registry like quay.io, Docker Hub, ECR, etc. CI can then build images and push them to your registry service, followed by deploying the image to your Deis apps using deis pull.

[Cryptophobia]

From @bacongobbler on October 20, 2016 14:51

To add onto this, when we're usually talking about implementing a CI/CD pipeline for apps on Workflow, we're usually talking about deis pull for one reason:

How do I tell my CI/CD tool to build the image similarly to how deis-builder does.

There is no tooling around how to build the image similar to the builder. You could try to write tooling around https://github.com/deis/slugbuilder, but it's usually easier to write tooling around a docker image to test/QA before pushing via deis pull, especially since the artifact you test in QA is the same artifact deployed in prod.

a blog post or official documentation on this would be really great.

We're planning on publishing a blog post on how our current CI infrastructure is set up. It's on the roadmap!

[Cryptophobia]

From @olalonde on October 24, 2016 20:32

FWIW, I ended up setting up CI/CD for all my apps (with CircleCI) 👍 thanks to @jchauncey for the help. To answer some of my own questions:

1) I've got a few apps that don't have a Dockerfile and some use .buildpack files. How do I tell my CI/CD tool to build the image similarly to how deis-builder does.

The easiest is to forget about deis-builder and just write Dockerfiles for each app.

2) How to avoid duplicating configuration (environment) variables between my deis app and the CI/CD tool. For example, I have a JavaScript/Node.js app that needs access to GOOGLE_ANALYTICS_CODE at both build and run time. Maintaining configuration variables in both the CI/CD tool and deis app is prone to error.

It's much easier to avoid requiring configuration variables at build time but for my webpack build, I just added a few ENV statements to my Dockerfile. I would like eventually to get all my configuration at run time from the environment variables set by deis config but it's a bit tricky to achieve with a webpack build.

3) If the CI/CD tool requires access to a Docker registry, is it possible to re-use the deis-registry for this purpose?

I realized that AWS ECR registry was really cheap (you pay for S3 storage and bandwidth only I think) so it turns out to be actually the same cost (or less) as running deis-registry. I'm still using deis-registry for the platform but eventually, I'd like to use the external AWS ECR registry instead.

The more I think about it, the more I feel like moving to a CI/CD workflow would eat into much of what Deis has to offer (except perhaps for routing + scaling) and I'm left wondering if I shouldn't just use CI/CD tool + Kubernetes directly.

Setting up CI/CD definitely makes it easier to move away from Deis because the build phase is independent and you get a registry with all your app images. You could deploy those images somewhere else if needed (e.g. could be useful for running a full development environment locally). Still using Deis though because it's awesome :)

[Cryptophobia]

From @bacongobbler on March 27, 2017 22:5

Adding onto the pile: TravisCI's dpl has support for deploying apps to Workflow. This has been available since v1; I've just completely forgotten to mention it.