Getting Started With Jenkins Continuous Integration
What is Jenkins?
And we’re going to start off by talking about what Jenkins is. You might not be familiar very much with Jenkins. Perhaps you’ve heard of Jenkins, heard that you should use Jenkins but you’re not really sure exactly what does this piece of software do for you. Well, We’re going to talk about what Jenkins is, a little bit about the history of Jenkins and we’re going to introduce you to some of the reasons why you might want to use Jenkins or a similar continuous integration tool in one of your projects.
Now let’s talk a little bit about what Jenkins itself is. You may have heard of Jenkins before, but you might not be quite sure exactly what is this tool and how can I use this. Well, basically Jenkins is a continuous integration software that is going to be run on a server. Typically we call that server a build server and it allows you to do continuous integration. And what I mean by this is that it really automates most of the tasks that you need to do in order to get continuous integration set up in your organization. And if you’re not familiar with continuous integration we’re going to cover the basics of that in a little bit here. But, it’s enough to know that Jenkins is a tool that is going to help you to do that. It’s also one of the most popular tools for doing continuous integration as of today. Now, Jenkins is open source and this typically is a good thing because it means that you can view the source. It means also that the license is free. You don’t have to pay anything for Jenkins and you have the support of a community of developers that are constantly making improvements to the product and are able to answer a lot of questions about the product. And this is really important when you’re talking about a development tool because many of the developers that are contributing to Jenkins are actually using it. They’re very familiar with it. It’s something that helps development teams to be able to stay organized and to ship more frequently. So, the contributions that are usually made are the types of things that you actually need and want and it’s really frequently updated. One surprising thing about Jenkins is that there always seem to be a new version coming out. Now, Jenkins is actually a web based tool and its Java based as well. Now, don’t let this put you off if you’re not a Java shop, because just because it’s written in Java doesn’t mean that Jenkins doesn’t work very well with dot net languages and many other development environments. Pretty much all development environments are supported by Jenkins usually through some plugin. You can even run your builds for android in iOS using Jenkins. Now part of the way that Jenkins is organised is it’s usually deployed in a Java package that is able to self-post. It has its own web server, mini web server built in and so it’s really easy to deploy to get up and running.This is really one of the primary factors that makes Jenkins so popular, because you can very easily try it out and get running. In the next module we’ll see how easy it is to do that install and part of that is because it’s built using Java, which is surprisingly very nice for doing something like this. And, of course, if you are developing with the Java project you’ll find that most of the Jenkins based functionality will work right out of the box with a Java environment. Now, finally the other major thing about Jenkins is that it’s highly extensible. In fact, a large amount of the functionality that you’ll find in Jenkins is found in the form of plugins. There are many, many different plugins that you could find for Jenkins that will allow you to integrate with almost all source control systems that you might be using and to integrate with almost all of the type of continuous integration tools and tooling that you might want to use. And you can even create your own plugins. It’s really not that difficult. There’s so many plugins because so many developers have already done this. You’ll find also besides the plugins that Jenkins has many extensibility points. When you create jobs in Jenkins you have many, many options for setting them up and you can pretty much accommodate any development environment. I haven’t really found a development process or a continuous integration process that I couldn’t get running with Jenkins.
Now, the history of Jenkins is actually pretty interesting. It’s a really interesting tool that seem to have come up very quickly in popularity and really ended up having quite a few disputes and territorial claims within its history. Let’s take a look at how Jenkins got started and some of that history. Now, Jenkins was started by Kohsuke Kawaguchi, who was a developer at Sun back before Oracle had bought Sun and he started this project around 2007 and actually at that time it had a different name. It was called Hudson. And really around the 2008 timeframe there was a rapid increase in popularity in Jenkins. But basically what happened was after Oracle had bought Sun there was some dispute on whether or not to basically continue developing Hudson the way it was being developed. But the basic result was that the Hudson project was renamed and that’s where we get Jenkins today. And even today the Jenkins project seems to be going fairly strong. There’s a lot of commits, a lot of bug fixes every single month and there’s a lot of new features that are always being developed and currently supported.
Splitting of Projects
Now, one interesting thing in the Jenkins history is the whole Jenkins/Hudson controversy that happened. And I’m not going to go into all of the little details of what happened but it is important to understand where Jenkins came from and why the name change and that there is still another tool out there called Hudson, which is the brother, if you will, to Jenkins. So, the basic problem happened after Oracle had taken over Sun and had basically taken over Hudson at the time. And during this time there was a hosting platform called java.net and this was where Hudson was hosted and it’s also where the Hudson developer mailing list and discussion boards were hosted as well. Now, java.net had some problems around this time frame, around 2009–2010 and many of the developers of this open source project, Hudson really wanted to get off of java.net. They wanted to move the discussions to Google groups and they wanted to move the source code to GitHub. And part of this was because of just some of the frustrations of java.net and then also an unfortunate incident that happened where the source control, which was SVN at the time was locked and everyone didn’t realize that a migration was occurring to the new java.net platform. It caused a little bit of a ruckus in the developer community so they decided that they wanted to really be free of these kind of problems and move over to GitHub. Well, it so happened that Oracle didn’t see things quite the same way. They wanted to keep the Hudson project under java.net, which was one of their properties and they felt like this was the best for the community; not just the developer community but for the overall large community that was now using this product. And Oracle basically came out on the mailing list and said, hey we’re going to keep it on java.net and you’re welcome to fork it if you want to, but we think this is best for the development community and for the Hudson community in whole and we also have the Hudson name trademarked. So, if you fork it you can’t use the Hudson name. So this really is what caused the controversy at this point. It was really the catalyst. So, what ended up happening was the development community said well yea, I think we are going to fork it. We do want to go to GitHub and we’ll go ahead and change the name. So, there was a vote and the end result of this vote was to split Jenkins off from Hudson. And part of this was because Kohsuke Kawaguchi had actually left Oracle and had decided to start his own company and to basically go full-time to supporting and developing on Hudson at the time. And so what ended up happening was he ended up really taking the stewardship of this new product Jenkins, which was a split from Hudson and Oracle retained the Hudson name. Eventually they ended up handing Hudson over to the Eclipse project as the stewards of that project and Jenkins continues to this day. And actually both projects still continue to this day. There is a Hudson out there. There is the Jenkins project. Jenkins typically has more development going on on it. It’s more active and Hudson has more corporate involvement. So, you can really choose between the two. Really they’re similar in the features, in the basic features. If you did want to use Hudson you could take many of the things and utilise that to set up your Hudson. If I were going to recommend which one you choose, I would definitely recommend Jenkins just because it’s more active. There’s more development going on there and there’s many more futures. And if you want to read more about this whole fiasco and what happened I’ve include a link here that really summaries exactly what happened in that controversy. And I only bring this up because I think it’s important that you know what happened because when you start Googling for Jenkins and you see Hudson it gets really confusing as to why are there two projects with different names that look very much the same and pretty much do the same thing and this is the story behind that. Okay, now that we understand a little bit about what Jenkins is and the background of how we got Jenkins and how it split off from Hudson let’s talk a little bit about the problem that we have that makes us want to have continuous integration. Well, the big issue with most development shops that don’t have continuous integration is that integrating is painful. What ends up happening is that when you integrate your code you end up having a lot of problems and things can break and that whole merge process can be a real pain. If you have different developers working in different directions and they’re coordinating and they’re not integrating very often then when they do that’s when you find the problem and often times a problem manifests itself much larger just because the development paths have gone in different directions. Now, in addition to that we have problems where the build doesn’t work or unit tests are failing and we’re not aware of that or we really just don’t have a good way to gauge the stability of a product when we have different code paths that aren’t coming together very often. One way to think about this is about developers working in their own little caves. Perhaps you’re down in the code for about a month without integrating with anyone else. And after that month when you finally come out of your cave and other developers are coming out of their cave you have this big problem because all of this code is now being merged together. And many times it’s not just subtle changes in the code. Many times you can have really large changes or changes of direction that end up causing big problems. In fact, when we were working like this we weren’t really able to refactor, because you can imagine what kind of chaos you could cause just by renaming a variable everywhere or changing the way that a class looked or the structure, because when you make a refactoring and you have had that code go on for a long time and someone else may be refactoring something completely different and all of a sudden that code is not even merge-able at all. You really have to dig in and figure out what exactly changed and you can’t even really compare things anymore. So, that’s the big problem with not doing continuous integration or the need for why we need to have continuous integration is to prevent this developing in caves by ourselves.
What is Continuous Integration?
So, if the problem is developing too much in isolation and integrating not often enough the solution is continuous integration. And continuous integration is basically just having all those developers or the coachings that are being made, being integrated almost continuously. What I mean by this is as soon as you check in some code you should be integrating that code with other developers who are checking in code as well and many development organizations due this today. You may not even realize what you’re doing is called continuous integration. This was definitely not a best practice if you go back five to ten years ago; at least it wasn’t nearly as widespread. But, now today most development teams and most software organizations recognize continuous integration as a best practice and typically try to follow it. So, the basic idea here is that we’re going to combine our code very frequently almost continuously and with that we’re going to do some other things like running unit tests and verifying that software. What we’re really trying to do is to prove the stability of the software based on whatever metrics that we’re going to use to judge that software as frequently as possible. Instead of having a build once a day, instead of having a build once a week we’re going to have a build every time someone checks a code or very close to that frequency. Now, we’re not going to go into all the details of continuous integration. There is quite a bit to continuous integration. I’m going to show you how continuous integration works in Jenkins and more of a focus on using Jenkins itself, although in the we’ll get more into some of the bigger ideas that you can do with Jenkins. For example, if you’re in Java shop there is always Java equivalents in most of those dot net tools.But this is definitely a great resource that you should definitely check out if you’re not familiar with continuous integration or you just want to know more about it.
Where Jenkins Fits In
Okay, so now we understand what Jenkins is. We understand what the problem is, which his basically that developers are working in isolation and not integrating enough and we understand the solution, which is continuous integration, which is basically trying to integrate as much as possible. So, where does Jenkins fit into all of this? Well, Jenkins is some software that allows us to do continuous integration. What we’ll typically do is we’re going to set up Jenkins and we’re going to run it on a build server. And that build server is going to be the central place where the build happens and this will be the build of record. We may be building the software on our local machines. We may be running unit tests and doing all kinds of code quality type of things on our local build, but it doesn’t mean anything unless the build came from Jenkins because Jenkins is going to coordinate and automate all of these steps and all of these things and give us some output that we can rely in to know what the result of a particular build was. It’s going to make it easy to integrate all of this code together because it’s always going to be grabbing the latest code and trying it out. And you can look at the basic model here. This is a very simplified model of how continuous integration is going to work with Jenkins.But it shows you what the general flow is. We start off with a developer checking in some code and you’re going to typically check in code in the source control. It doesn’t matter what source code it is. Jenkins is going to work with most source code control systems. And somehow Jenkins is going to get the latest from source control. It may automatically get the latest when the developer does a check-in. That process may trigger something in Jenkins that says, hey go and get the source control. Jenkins can also poll your source control so it could be just looking out there, looking for a change and there’s a few other ways you can set it up, but the basic idea is when the developer checks in some code you want to get that latest code and have it go to Jenkins. Now, Jenkins will then build and it will do whatever else it needs to do to validate your code. It may run some evaluations. It may run some unit tests. It may run automated tests and customer acceptance tests. We’ll talk about more of the options in the last module.But the basic idea is its validating the build in some way and performing the build. Now, it’s going to produce some output and that output is going to be available for you to look at from Jenkins. You can browse the Jenkins. Remember it’s an embedded web server so it can host itself or you can host it on your web server, but basically its going to be a web application that’s going to allow you to see what the results of that build are. And then from that report Jenkins can also notify the developer automatically. So, Jenkins can be configured to send an email, to send a chat message, to alert the developer in many different ways. In fact, many developers have set up blinking lights where the build is set up so that when Jenkins fails a bill it will make your light turn red or it will do some kind of theatrics that will get someone’s attention to let them know that the build is broken. And so we have this cycle, basically this feedback loop and all the developers are working in the same feedback loop. So, it really helps us to know when we’re integrating our code if we’re going to cause a problem and when we cause that problem this is the critical point. We’re able to identify that very quickly, because the quicker we identify an integration problem the easier it is to solve. When we let those integration problems pile up, pile up, pile up, we end up having a much more difficult problem to solve. So, that’s where Jenkins fits into all this.It’s basically going to automate this stuff for you so you as a developer checking in code, you don’t have to worry about what’s going on. You’re just going to check in code and you’re going to look at Jenkins and wait and see what it reports back to you and you don’t have to do all of the steps involved in validating and verifying that code. Although with that said, you should definitely do the best you can to validate and verify your code before you check it in and not just rely on Jenkins to tell you if you have, for example, a compile error that would be hurting everyone on your team and not a valuable use of everyone’s time.