Hi, I'm Eric Minick with IBM Cloud. I want to tell you a little bit about continuous integration today. This is a development practice that just about everybody thinks they're doing, but it's widely misunderstood. So, I want to start by talking about the bad old days before we had it, what problem we're trying to solve, and what this does for us and what it's really about. So, let's start with our old school approach where we've got a couple of developers, they're probably on a team of 30 or 50, we got Alice and Bob and they're working on their own features, and they're going to keep separate on their own features for a long time. They're writing some bits of new code here. Maybe they're deleting a line of code here or there, what have you. And their plan is that they're going to get their features to work against the code base, then in a couple of weeks, or months, later they're going to integrate their work together. They're going to merge their work together. They're going to say: "My code, your code, it's got to come together, it's all got to work". Now, in this world, you could have a situation where Alice & Bob, they changed the same line of code here, right? And maybe Alice changed this code, but then Bob deleted it. And so, this gets really awkward, really fast when you just try to algorithmically combine it. You get what's known as a merge
conflict. This gets worse because it might be that some code up here, interferes with some code down here, they just don't work together and you've got bugs. And this will happen here within just one
file, but in the real world, it's not just two developers working on the same file it's thousands of files, or millions, in an application. There's tens of developers involved and they're doing this over weeks and weeks. And so, reconciling all of these problems, it's big mess. It's called "merge hell". And so, they say, "What do we do to avoid merge hell? This is how we got here". Well, we start, and we'll have Alice writing
some code again, right? Alice writes her code. Cool. As soon as she has something that works even a little bit, her feature is not done, but she's got code that works, it doesn't break things. She submits that in the source control, Bob pulls down the same code before he starts working, right? He always is working off the latest. Alice is always submitting hers in. Bob makes his change right? Maybe he deletes a line of code, great. Alice comes back, she's working another part of a feature, she's working on another feature, she grabs Bob's code. Cool. And now they're working on these things together. And the likelihood that they're both working on the same thing, at the same time, and that they conflict is pretty small. And if they do hit that, it's all on code
they've worked on in the last day, right? they can sit together, they can reconcile
this thing, it's no big deal. And so, the core principle that we're seeing here, one of my favorite things in software development, because it is so counterintuitive, is that if it hurts, do it often and it won't hurt so much. And that helps us get rid of the big, big bogey here, right? Which is, we're going to not have merge hell. We don't like merge hell. Get rid of that. OK, so that's fix number one. Now, this does create a new problem though, right? They have a whole bunch of people constantly checking in code into the code base. Things are going to break, right? It's not going to compile. There's going to be bugs that weren't there yesterday. And you have this kind of, "continuous integration led to continuously broken" problem. And that's sad. So, what do we do? Well, we put some automation in, right? And it's always watching the code. Keeping an eye on it, and whenever a change happens, It says, "OK, let me grab that code. I'm going to build it." "And then I'm going to test it." "Alright, I'm going to run my unit tests". So, if there's any change, build it, test it. If anything in here fails, then we email the team. We let Alice, Bob, the whole team know, say "Hey, there were 2 new changes since last time I did a build, looks like both Alice and Bob touched this thing. It's broken now. They need to go fix the code base." Good. So, now we've got a safety net that enables continuous integration. Good. The other thing that we're getting though, is that we always have this build. Right? So, whenever the test team wants to go test it in more depth, to run a heavier level of tests than the unit testing that we're doing here, they've got a build they know compiles - and it's the newest stuff, right? So, that's our other key benefit coming out of continuous integration is that we always have a testable build. So, there you go. Continuous integration was addressing the old way of infrequent integration, saying, "If it hurts, we're going to do it continuously, we're going to do it a lot." That avoids merge hell, keeps our developers productive, and it gives us a constantly testable build. So that's continuous integration in a nutshell. Thank you. If you have questions, please drop us a line. If you want to see more videos like this in the future, be sure to like and subscribe.
