MCET-SEC 4: Build server
All right, all right! I will look into at the Docker while building my cost-efficient toolchain for a small Windows minded software engineering organization. Docker was the immediate feedback I’ve got from my developer at CODEFUSION. “Are we building our toolchain using containers?” – they’ve asked. “Nee!” – I’ve replied. Not because I have something against. It’s actually the other way around. It is because I do not have any experience with containers. I’m a Windows person. I know that Microsoft is all about Docker, but I have no time to learn I thought. Then I’ve started to set everything up on Windows. Repository with pull-request functionality based on Gogs was a dream to set up. TestLink was not. Now came the time to renew the build server. It should be an easy task. Since I’ve written “Continuous Integration in .NET” in 2011 I try to be up-to-date on everything concerning CI. But yesterday I’ve spoken to a friend, whos opinion matters to me a lot, about the MCET-SEC and he told me a story how they’ve are running build server at the company he is working for using Docker and Kubernetes. All right I thought. Enough. I have to learn. So Pluralsight beware I’m coming to learn Docker and Kubernetes!
But in the mean time my developers need to have a new build server. The one we are using now is a bit rusty. Our C3PO (yes, we are naming out servers after famous robots – yea, it is embarrassing for serious business – but we do it nevertheless 😉 is an almost 10 years old Windows Server 2008 R2 VM. It was held in an vanilla state for the early years like it should be (we’ve tried not to install anything that was not important for the build process on the machine to keep it from the external influences). But 10 years is a lot of time in IT. We went over many, many projects in those 10 years. There is a lot of rust gathered on our C3PO. It is time to renew.
Build server matured since I’ve written my book. Back then it was almost always a dedicated machine with a piece of software that done a very simple thing. Check(or was told about the fact) if there is anything new in the code repository and spin the build process running. It was something similar to that what you can see below.
It is still something like that today but the “server” is moving. It is moving into the cloud. We still have the old standalone build server, but we are getting more and more cloud based services. There are still the old servers around:
1. Jenkins
2. TeamCity
3. Travis CI
4. Bamboo
But there is a lot of SaaS service out there hosting the build servers ready to utilize. A prominent example here is Buddy. I’m mentioning Buddy not only because it is build in Poland (where I’m from). I’m mentioning them as a perfect example of continuous integration / continuous delivery service out there. They are cloud native. Ready to set up in a matter of minutes. If your software is as modern as they server is, it will be a magic. If not. Well, you are trapped.
What do I mean? I mean what if the software you are building is not a new and shiny modern web application based on microservices? What if you are building and maintaining Windows based desktop applications that are partly build using C++ and partly in WPF. What if you are still maintaining WCF web services for a customer and have a set of running SOAPUi testes. What if you are also developing mobile applications? What if you are using PHP and a build server as a static code analyzer and deployment machine? Well then services like Buddy are not enough. You will need to maintain your own CI server. That is what we do. That was what I’ve done.
I set a newest Jenkins server on the new machine. I’ve grabbed the latest Windows installer and used the MSI. The installation was even easier then 9 years ago. I’ve added some addons I’ve needed. LDAP configuration was a bit different than everywhere else (user search filter is ={0} and not =%s – there should be a price for someone that will make the LDAP configuration general). The SSL configuration did not changed in the last 9 years. You sill need to have the jks Java style keystore there and edit the jenkins.xml file to add a proper command line parameter for Jenkins to find the jks store.
Last thing I’ve done is to set up a SSD disk for the builds. It was one of the main feedback points from the developers. That the build need to be faaaast. They are of course right. The time spent waiting on feedback from the CI server is wasted. So I’ve created a VHD on the server. Put it on the SSD volume and mounted it to the CI server. Then I’ve configured the working directory in Jenkins config.xml like this:
<workspaceDir>e:/jenkins/jobs/${ITEM_FULL_NAME}</workspaceDir>
<buildsDir>${ITEM_ROOTDIR}/builds</buildsDir>
The new IC server is up and running!