In this blog post, I'll tell you about my Jenkins build server setup. I'm learning new things as we go along, but here I'll write the stuff I've done so far. We are a Java eCommerce development shop, in serious need of some upgrading to the 2000's and above. I'm pretty new to this organization, and I am in charge of making things better. So, I new we could use some continuous integration, so Jenkins it is. Jenkins can be as easy as 1, 2, 3, ... however there are many little things to think about when setting all of this up. Hope my story helps you.
First Steps:
To begin with, I started with a left over windows desktop we had laying around, put it under my desk, and threw Ubuntu on it. I just wanted a server to start playing around with. I was able to install the tomcat version of Jenkins on there, and had it running pretty quickly. At work, we have about 35 projects going on at one time, and each one may have more than one active branch of development. This means the total number of builds to be configured could possibly reach about 100 after it's all said and done (that's with a CI build and a Nightly build only). Once I tried to get connectivity to a CVS repository, I quickly figured out that I'm going to need a better solution. That connection required SSH keys, and my managed services department really didn't like me accessing that stuff from a random box under my desk using generic logins.
We need a bigger box...
So, I enlisted the help of my managed services group and we put a box in a secure location with some decent hard drive space. Cool, now that I had their support, I can now start to get some SSH keys set up so I can grab CVS and SVN repositories for building. (We have a hodge podge of repositories all over the place. That is a mess I need to clean up as well, but that's for another blog post.) Spending a good afternoon looking at all the repositories, managed services was able to hook Jenkins up to almost all the repositories so we can start grabbing source code! YaY!, real progress. Now, the next issue to tackle is getting the ANT scripts to actually build the code in Jenkins. Ha, of course it's never that easy. Just about every script needed to be modified. However, I needed to be careful, because I can't mess up the manual build process. Many people with torches and pitchforks would be at my office door screaming if I did that. So, a ci-build.xml was necessary. This did things crazy like create the build directory before trying to clean it because build.xml didn't check to see if there was a build directory before trying to delete it. When developers saw that kind of error before, they just created a build directory. Ugh. So, anyway, after some adjustments, an actual build took place!
Wow, we can actually build some software now! What next...
Since we don't actually have any unit tests to run, we needed to start writing some. What to write them in is the question: JUnit, TestNG, some BDD framework? Yes, all of the above. So, engineers went off in many directions, with new energy. Some built JUnit tests, some did BDD using Gradle, and all of it is cool to me. Whatever they feel comfortable with is good. No sense in stoping the train at this point. Maybe later, we can standardize when we see something that is the clear winner. For now, use groovy to test Java, or scala, or whatever you want. Just test! And make sure Jenkins can run your tests and email you when it fails. That's all I ask! So, once we get some tests and some knowledge on how to test, we can talk standardization and TDD and all that.
So, in the meantime, I want to do some static analysis. Findbugs is great, and I stumbled upon Sonar, which is like PMD and Findbugs and other stuff all rolled into one with a great dashboard for the MBA types. Awesome, lets do this. Sonar is relatively simple to setup. No big issues there. They have some great documentation.
to be continued...
First Steps:
To begin with, I started with a left over windows desktop we had laying around, put it under my desk, and threw Ubuntu on it. I just wanted a server to start playing around with. I was able to install the tomcat version of Jenkins on there, and had it running pretty quickly. At work, we have about 35 projects going on at one time, and each one may have more than one active branch of development. This means the total number of builds to be configured could possibly reach about 100 after it's all said and done (that's with a CI build and a Nightly build only). Once I tried to get connectivity to a CVS repository, I quickly figured out that I'm going to need a better solution. That connection required SSH keys, and my managed services department really didn't like me accessing that stuff from a random box under my desk using generic logins.
We need a bigger box...
So, I enlisted the help of my managed services group and we put a box in a secure location with some decent hard drive space. Cool, now that I had their support, I can now start to get some SSH keys set up so I can grab CVS and SVN repositories for building. (We have a hodge podge of repositories all over the place. That is a mess I need to clean up as well, but that's for another blog post.) Spending a good afternoon looking at all the repositories, managed services was able to hook Jenkins up to almost all the repositories so we can start grabbing source code! YaY!, real progress. Now, the next issue to tackle is getting the ANT scripts to actually build the code in Jenkins. Ha, of course it's never that easy. Just about every script needed to be modified. However, I needed to be careful, because I can't mess up the manual build process. Many people with torches and pitchforks would be at my office door screaming if I did that. So, a ci-build.xml was necessary. This did things crazy like create the build directory before trying to clean it because build.xml didn't check to see if there was a build directory before trying to delete it. When developers saw that kind of error before, they just created a build directory. Ugh. So, anyway, after some adjustments, an actual build took place!
Wow, we can actually build some software now! What next...
Since we don't actually have any unit tests to run, we needed to start writing some. What to write them in is the question: JUnit, TestNG, some BDD framework? Yes, all of the above. So, engineers went off in many directions, with new energy. Some built JUnit tests, some did BDD using Gradle, and all of it is cool to me. Whatever they feel comfortable with is good. No sense in stoping the train at this point. Maybe later, we can standardize when we see something that is the clear winner. For now, use groovy to test Java, or scala, or whatever you want. Just test! And make sure Jenkins can run your tests and email you when it fails. That's all I ask! So, once we get some tests and some knowledge on how to test, we can talk standardization and TDD and all that.
So, in the meantime, I want to do some static analysis. Findbugs is great, and I stumbled upon Sonar, which is like PMD and Findbugs and other stuff all rolled into one with a great dashboard for the MBA types. Awesome, lets do this. Sonar is relatively simple to setup. No big issues there. They have some great documentation.
to be continued...