A decade ago, the objective was to have a build farm and do continuous integration (on each commit, build the application and run unit tests). Now, the objective is continuous delivery. This means that the new build is directly put into production. All the major applications are doing this, from Chrome to Spotify. You may not get every version on your machine, but you should consider a build as something you could deploy.

The nice thing is that there are tools to ease this workflow.

Discussion

Jenkins is one of the most known build farms. Previously known as Hudson, it’s heavily Java oriented, but can handle any kind of application. Docker is also a leader tool to create lighter virtual machines (that’s why Docker instances are not full virtual machines). So this book is about putting these two tools together to deliver Continuous Delivery. Does it manage to cover 2 non overlapping tools?

There are nine chapters in this book, starting from Continuous Integration and ending up with problems that can arise with Continuous Delivery.

The first chapter covers the definition of Continuous Delivery as well as a few tools that will be used on top of Docker and Jenkins. The common “project” between all chapters is written in Java, so the build tools and the example code are in Java, but that’s not really a problem. Once more, Jenkins doesn’t care about the underlying build system as long as there is a way to build the app as a command line, and then Docker takes over to distribute the resulting package.

Then comes the second chapter tackling Docker. It’s a quick exploration of what Docker really is (what I meant by “lighter” VMs) and then the basic operations. It doesn’t really go into any details, any good practices or Dockerfile command exploration. How to parametrize Docker is also completely skipped, so this is a simple explanation, but anything more complex will require reading the documentation or another book on Docker (for instance if we want to share some data across instances).

The third chapter introduces Jenkins. Jenkins is pretty much easy to install. But there may be some caveats when you are deploying Jenkins slaves on your own machines and you need to use password-less SSH. This is where I struggled one day, for instance, as the master was deployed on a Docker instance, with local disk access, and a custom additional disk space. And that hurt. Unfortunately, as I’ve said, the second book won’t talk about this, and the third one doesn’t really show you how to configure things in details. Still, the chapter does expose the main good practice of using declarative pipelines stored on your version control system, and it also explains that your slaves (themselves possibly running in a docker instance) can run your pipeline steps inside another docker container.

Then we move to an example of a continuous integration pipeline for the small Java app. The first stage is the checkout stage, but actually by default, if I remember correctly, Jenkins will call git for you, so you don’t have to do it yourself. The missing piece is that the pipeline instructions here are very shallow, no real exploration of the advanced features like functions, exception safety… Still, we can see also the different development workflows possible with git, and we clearly see that Jenkins can handle anything we throw at it.

The fifth chapter tackles the first step after Continuous Integration, and this is acceptance testing. We start by looking at Docker repositories (setting your own is tackled too rapidly, once again) and we see what acceptance tests are and the architectures that can be used to run these tests, for instance with docker-compose that can orchestrate different images that need to communicate together.

We now have a chapter about Ansible, which is a tool I never heard of (I heard of Chef and Puppet, but not that one). I like the way it’s set up (no local agent, only need to SSH access), and it can properly install the required tools on a box and configure it, for instance changing the Docker config. But as we have not explored the Docker config that much, I feel this chapter as really optional, everything that is tackled here can be done inside Docker directly through dedicated images.

Anyway, chapter 7 finishes the loop of Continuous Delivery with more tests and explains what we should test. I think these are relevant, but should be known by any serious DevOps.

Before closing with an advanced chapter, we have one last chapter on Docker Swarm. This is an interesting chapter when you never worked more with Docker (but it is covered in more details in other Docker books) and want to deploy scalable applications (like a web server) and have a load balancer but you don’t want to install something else. Of course, on the cloud, where you will actually deploy your app (probably), you will have access to other tools like Kubernetes than will handle this as well. It is introduced, so that’s good. But I would have liked to see an example on AWS, Azure or Google cloud.

The last chapter is names Advanced Continuous Delivery. It builds on the previous chapter that tackled container updates by tackling database updates, but the solution is quite simple, there is no magic bullet, it’s just common sense. Prepare a way of downgrading. That’s it. There is a small part on more advanced Jenkins (parallel pipelines), but it’s also very common sense, and when I started using Jenkins, the first thing I did was to use a parallel pipeline, so I don’t see it as advanced, really just a basic pattern when you have more than one platform or app to build. There are a few chapters on releases, and this is something that anyone reading blogs will know as well. For instance, progressive deployment is what everyone does (Microsoft, Google…), but you could also do all or nothing (switching between 2 environments). I would say that the progressive one makes more sense and is more adapted to testing and doesn’t require two independent systems, but one system morphing to another, possibly with fixed pieces. Finally, there are some talks about handling legacy systems, I don’t see anything more than what has been said in previous books.

Conclusion

If you want good practices with Jenkins and Docker, you will have to look in dedicated books. If you don’t need to know a lot about Jenkins and Docker, or if you need to jumpstart with these tools and plan to only read the documentation and tutorials for more advanced features, if you just want an introduction, this book is for you.