This hands-on course walks through the process of integrating a Dockerized app into a DevOps style automated workflow that includes Continuous Integration (CI) and Continuous Delivery (CD) elements. The course will include configuring Docker Hub Automated Build repositories and Docker Hub Webhooks.
This course walks through the process of integrating a Dockerized app with DevOps style automated workflows. A small node.js web app (and small test) will be uploaded and tracked on GitHub. GitHub will be configured to inform the CircleCI platform whenever code updates are committed and pushed. CircleCI will perform test builds. Upon successful test builds, CircleCI will inform Docker Hub, which in turn will trigger a new Automated Build and inform the Tutum container platform. Tutum will then pull the new Docker image and deploy it as a container on the Amazon Web Service platform. The entire end-to-end workflow will be described and implemented in extensive demos, as well as demonstrating bugs in the app code and pushing fixes to production.
Configuring Test Builds All right then, we've got our project uploaded to GitHub. Time to put it to the sword and see if it actually works. Now, the CI tool that we're going to use for this course is CircleCI, a hosted platform for automated testing and continuous integration. The thing is though, it's obviously not the only tool out there that does this job, there's a ton. The actual platform itself here isn't important, well in real life obviously it is, I mean it's really important, but for this course it's not. Pick your favorite CI platform and roll with that if you want. So, if you're following along, but you're already a legend with another CI tool and it's the bizo and it hooks into Docker Hub and you have no intention of ever changing it, then sure thing, you can use that, the hooks and things on the Docker side, they're going to be the same. Anyway, CircleCI, so we're going to log on, give it access to our GitHub repo, select our project, our app, and perform a build, let's go.
Breaking and Fixing the App All right then, so we've got our workflow all up in place, the whole shebang, and we've seen it delivering the goods, I think it's fair to say it's the bizo. But a vital part of the flow is the build test we've got configured in Circle, and if that test fails, then the broken build absolutely must not leak through to production. For us, production is AWS. But I just need to be clear, the whole thing, which I've already declared as the bizo, well it's actually worthless if it can't stop an error leaking through and breaking production. In fact, if the break that we're going to introduce here makes it through to production, then I should be sacked. In fact, I'll come and wash your car for you for free. So what we're going to do in this module is break our app, or cause the test to fail, same thing, kind of. We're going to introduce an error into our code and we'll push it to GitHub, this will trigger a test build on Circle, and unless I fancy coming and washing everyone's cars, that test had better fail and our workflow had better grind to a halt. And as part and parcel of this, we'll check and verify and make sure that yeah, it does fail, and that no, our workflow doesn't continue any further. Then after that, we'll fix it, get it all green again, and because everything's automated, well not everything, but everything we need for this course, but because all of that's automated, the fix is just going to sail right through to production without any effort from us. And I am properly looking forward to this module, I mean not that I didn't look forward to the others, but I don't know, there's just something about breaking and fixing stuff that I enjoy. Anyway, let's get started.