In this interview, process coach Jared Richardson defines continuous integration and testing, explains how they lead to a continuous deployment environment, and covers why Jenkins has become such a popular and standardized open source continuous integration tool.
Josiah Renaudin: Welcome back to another TechWell interview. Today I am joined by Jared Richardson, a principal consultant and a member of the core team at Agile Artisans. He'll be giving a tutorial at our Better Software West conference titled, “Continuous Testing to Drive Continuous Integration and Deployment.” Jared, thank you very much for joining me today.
Jared Richardson: Hey, thanks for having me, Josiah.
Josiah Renaudin: Absolutely, and first, before we get rolling into the content, tell us a little bit about your experience in the industry.
Jared Richardson: Oh, wow.
Josiah Renaudin: Big question, I know.
Jared Richardson: Let's see. Well, I was in college back in the late '80s, early '90s, sold my first program, which was one of my data structures classes back in '91, so I've been writing software for a while. I got started in the Smalltalk arena, moved from Smalltalk to Java, Java to Ruby on Rails, and landed in the right place at the right time, with a few different opportunities. Now I'm a full-time agile coach, and working with Andy Hunt on the GROWS methodology.
Josiah Renaudin: Yeah, and when we get into topics like the continuous integration and continuous testing, sometimes we forget to even define exactly what these terms are. For you, can you quickly define both CI and continuous testing?
Jared Richardson: Well CI, I like to call it ... It's the gateway drug for a lot of the agile technical practices. It's usually a software process that watches your code repository. You want something that will works GETS, Aversion, whatever you happen to be using. When anybody touches the code, developer, tester ... I've had document teams break code before. When anybody touches it, for any reason, it's going to notice it, every five minutes, ten minutes, it's going to look, see the change, check out the code, and build it, just to make sure it still compiles in what we're taking to production.
If you're in a progressive team, and you're really moving forward in maturation, we'll then have a series of unit tests that can be run. For years, that was the gold standard. Let's make sure it compiles, and if we have unit tests, let's see if they run. Eventually, people figured out the end users don't really care if it compiles. They don't care about unit tests particularly. They care if the product can be installed and run.
When you talk about continuous deployment, and continuous testing, that's the process of taking that successfully compiled code, and running the installer in an automated fashion, installing it to something that looks like production, and then running your integration tests against it.
We go from getting feedback to those testers and developers. Rather than waiting days, weeks, or months, we get that feedback in tens of minutes, twenty, under an hour, you know if everything works on your app. It's a very, very efficient way of getting feedback into the hands of the people that are working.
Josiah Renaudin: How do continuous integration and continuous testing both lead to a continuous deployment environment? To branch off of that, too, are these feedback loops only really found in agile teams, or can they be found everywhere?
Jared Richardson: I have brought continuous integration into mainframe teams, I've brought them into waterfall teams. This type of feedback loop is very valuable no matter the methodology. I like to tell people, I've had clients before that tell me, "Hey, we're not doing agile here anymore. The command has come down from on high, senior VP, C-levels have said, ‘No agile,’ so we can't work with you." My response is always, "I don't care if we do agile, I care if we drive solid engineering practices. Now I happen to pull a lot of those from the Agile space, and here's one. This isn't agile, or not agile. This is just rapid feedback for the people writing code, and so it fits in any methodology that I'm aware of."