A practical guide to understanding Java DevOps and continuous delivery with Eberhard Wolff

An interview with Eberhard Wolff

Cameron McKenzie: Eberhard Wolff is one of the experts that the server side follows on Twitter. A software engineer with going on 20 years’ worth of experience, you may have read one of his books on Spring or continuous delivery or micro-services, or you may have seen him speaking on one of those topics at a conference in North America or Europe. We noticed that he’s got a new book out, “A Practical Guide to Continuous Delivery,” so we scheduled an interview, and the first question was, “What is the current state of continuous integration and continuous delivery?”

Eberhard Wolff: I’d say that continuous integration is, nowadays, a commodity up to the point where people actually forgot what it actually means. They start to use continuous integration just to do regular compiles while in fact, they’re doing feature branches, postponing the integration. Oftentimes, people are actually doing feature branches, and that means a team might be doing something for quite a long time and not integrating. They sort of miss the original point about continuous integration. So I think that’s the status that we are in, that people actually forgot about the original ideas behind continuous delivery and are now rediscovering them.

Cameron McKenzie: So when you encounter clients using this feature branch approach, what do you tell them and how do you go about correcting them?

Eberhard Wolff: The first thing I tell them is that if you don’t have a problem, don’t fix it. Feature branches are actually a fine way of doing it. If they do have problems integrating back into the main branch, then I would set up some additional measures like doing regular integrations or maybe even changing it altogether so that you just have the master branch and you do all work on trunk.

Continuous delivery changes the whole thing a little bit because usually, it means that the master branch is special because it’s the one that goes into production. Even if you do feature branches and you branch them off, they are different from the master branch because they are usually not going into production. And that means that I would argue, through continuous delivery, probably it’s not the best idea to combine the feature branches.

Cameron McKenzie: Now, are there any software tools that you recommend for Scrum teams or  Agile organizations doing a continuous delivery type of approach to DevOps, or are you one of those advocates that falls into that camp that says tooling is one of the last things you talk about when you go down this path?

Eberhard Wolff: Concourse CI is an interesting tool because it does everything on Docker. Actually, a colleague of mine is quite an advocate of that, so I found that interesting. Generally speaking, I would argue, in particular, if you talk about continuous delivery and if you look at the book, it’s actually all about testing.

So in the book, I talk about unit tests and acceptance tests and performance testing and all these kinds of things. And usually, if I go to a customer and I need to consult them concerning continuous delivery and also probably micro-services, the first thing that I talk to them about is, “What is it really that keeps you from doing much more frequent releases?” Usually there is some manual sign off or some manual acceptance testing, and I think that is something that’s often forgotten. So, you know, just having a Jenkins and doing deployment automation, I think that’s not the key challenge. The key challenge is to go into production without manual sign-off.

Cameron McKenzie: Now, we’re all familiar with unit test and testing our business logic and, even to a certain extent, integration testing, but what about testing the UI? I mean, how can we do changes to a user interface to the way that a person interacts with their tool and actually test that and validating that? Aren’t there some serious challenges in terms of automating UI testing?

Eberhard Wolff: I would tend to agree that if you talk about UI testing concerning, you know, look and feel and these kinds of things, that’s hard to automate and probably even impossible. Having said that, what I usually see in customers is that they rely on UI. They are doing UI testing, but I think what they are really doing is acceptance testing. So, you know, it’s not about “does the UI work propertly” and it’s also not about “that the UI looks nice.” If they do automated UI testing, it’s usually about does the system do what it’s supposed to do, which, in my opinion, is acceptance testing.

The road that usually leads there is that that’s what testers do, right? They start the application, they take a look at the UI, they do stuff in the UI, they validate that the results are correct, and they automate that. So you have a UI test, which is, in fact, really an acceptance test. And I think that’s bad because that way, you get fragile tests because if you do a minor tweak to the UI, it breaks your test even though the business logic might still be the same. And also, those tests tend to be slow and even sometimes unreliable.

So if you ask me about the main challenge concerning UI tests, I would argue that the main challenge is that they become acceptance tests, and you should look at different ways of doing testing in that regard and, you know, you should do proper acceptance testing using other tools. And that is why I really wanted to include that chapter about behavior driven design because I think it’s key to understand how to do proper automated acceptance testing and how to try to avoid manual sign-offs from the customer.

Cameron McKenzie: Now, you clearly have an issue with manual sign-offs, but what about exploratory testing? I believe you talked about it in your book. What’s the role of exploratory testing and the manual aspect of exploratory testing?

Eberhard Wolff: I think it’s fine to do manual testing. I mean, that’s basically what exploratory testing is about, you know, to have a manual look at specific parts of the application that’s causing problems or something like that. So I would argue it is a tool where you can have a specific focus on specific areas of the application that are somehow the problem, you know, from a performance perspective, from a business logic perspective, etc.

It’s something that is going on, you know, to fix problems in specific areas, but it should not be a block on the continuous delivery pipeline, which would clearly be if it required a sign-off.

Cameron McKenzie: Now, there’s no denying the containerization trend that I’m seeing more and more clients being pressured into using Docker and integrating Docker and containers into their architecture. How has containerization and tools like Docker change the way that continuous integration and Agile continuous delivery is done?

Eberhard Wolff: Yeah, I think you are pointing at a very important point. Docker allows different ways of doing integration and continuous integration and so on. And I would agree that there would probably be a new generation of tools. I believe Concourse is one of the tools that’s already mentioned. So I think that is an interesting point, you know, to really rethink continuous integration, to make the continuous integration server aware of Docker containers, to make the continuous integration server itself run in Docker containers and also to obviously create Docker containers. I believe that, how shall I put it, Jenkins is not the greatest tool anyway, right? So I think, for that reason, the additional pressure that you mentioned from the move towards Docker, I sort of welcome it because I’m looking forward to a new generation of CI tools.

Cameron McKenzie: So what are the things that you would like to see in the next generation of continuous integration and Agile continuous delivery tools?

Eberhard Wolff: A more rigid isolation of the different builds of the different projects. If you look at Jenkins, I would argue that it’s been built with the idea of setting up your continuous integration platform, your continuous integration pipeline in the tool itself and in the web UI. Of course, that has changed now because there are now job description languages. But I would argue that ideally, a modern continuous integration tool should be code-based anyway. So, you know, that there’s a job description for the continuous integration pipeline from the very beginning and it should be built with that in mind. So I think those are the points.

What I do like about Jenkins, of course, is the huge ecosystem and all the plug-ins that you have, which, again, are sort of an issue because it means that no Jenkins server looks like the other one and it’s hard to get all those plug-ins to work together. So that’s another shortcoming, probably, but, you know, it’s trade-off because if it wasn’t for those plug-ins  then Jenkins would be much less valuable.

Cameron McKenzie: So I’m assuming that you believe that adopting a DevOps culture is important to making continuous integration and continuous delivery work.

Eberhard Wolff: Oh, yeah, absolutely. So I believe DevOps is all about development and operations working together, which is to say that it’s not about an organizational change, so I think it’s not so important to have dev and ops report into the same managers. What I do think is important is that both share in the responsibility for the application and that there is no finger pointing but true collaboration. So I think that’s the key point. And of course, if you do change the organization, then that might be beneficial for such collaboration.

I think continuous delivery is one way or one thing that you can achieve more easily if you do DevOps. That is to say if I look at the continuous delivery pipeline at one point, it’s about deploying stuff into production, which is usually an operation’s thing. And on the other hand, if the start of the pipeline, just doing the compilation and building the software, unit testing that’s on, that’s more a dev thing. So if you have the whole pipeline, you can only build it if you have a DevOps organization. So let’s say that continuous delivery is one thing that you can enable by having a DevOps organization. That’s sort of how it fits together in my opinion.

Cameron McKenzie: Now, one of the reasons we got together today was so we could talk about your latest book, “A Practical Guide to Continuous Delivery.” What is it that you wanted to achieve by writing this book and what is the takeaway that readers will have once they finished reading it?

Eberhard Wolff: What I want to achieve with my book, and that is actually something that also sets it apart from the original “Continuous Delivery” book, is  that it is the practical introduction. So I actually talk about specific tools. I give advice about how to use them. I have some examples how to use the tools. People can learn from that and build their own experiments. So that’s basically how it works in my opinion.

Cameron McKenzie: Now, if that conversation doesn’t convince you that Eberhard Wolff knows what he’s talking about, I don’t know what will. I strongly suggest that you, like the server side, follow him in Twitter. That’s @ewolff. That’s with two Fs. And more importantly, go pick up his book, “A Practical Guide to Continuous Delivery.” I know you’ll enjoy it.

You can follow Cameron McKenzie on Twitter: @cameronmcnz
You can follow Eberhard Wolff, too: @ewolff

How to become a Jenkins expert

Struggling to learn Jenkins? Check out these great, step-by-step Jenkins CI tutorials. They’ll make you a Jenkins CI expert in not time.

Step 1 — Download Jenkins and install the CI tool

Step 2 — Create your first Jenkins build job tutorial

Step 3 — Inject Jenkins environment variables into your scripts

Step 4 — Fix annoying Jenkins plugin errors

Step 5 — Put the Jenkins vs Maven debate behind you

Step 6 — Learn to use Boolean and String Jenkins parameters

Step 7 — Do a Jenkins Git plugin GitHub pull

Step 8 — Add knowledge of basic Git commands to your DevOps skillset