Continuos Integration

Recently I have been playing with a way to easily setup build automation for many small projects Continuos Delivery workflows are perfect for the smaller projects I have so settings up test / build automation is super useful and is even better when it can be spun up for a new project in a matter of minutes so I decides to work with Tutum to run docker-based Jenkins that connects into Github repositories.

In this post I explore setting up continuous integration using the Tutum.co platform using amazon AWS, a Jenkins Docker image, and a simple repository that have a C program that calculates primes numbers as an example of automating the build process when a new push happens to Github.

What I haven’t done for the post is explore using a jenkins slave as a docker engine, but hopefully in the future I can update some experiences I have had doing so which basically allows me to have custom build environments by publishing specialized docker images as what Jenkins creates and builds within. This can be helpful if you have many different projects and need specialized build environments for continuos integration.

Tutum, Docker and Jenkins

What I did first was setup a Tutum account, which was really simple. Just go to https://dashboard.tutum.co/accounts/login and sign in or create an account, I just used my github account and it got me going really quickly. Tutum has a notion of Stacks, Services and Nodes.

Node

A node is an agent for your service to run on. This can be a VM from Amazon, Digital Ocean, Microsoft Azure, or IBM Softlayer. You can also “bring your own” node by making a host publicly reachable and running the Tutum Agent on it.

Service

A service is a container, running some process(s)

Stack

A stack is a collection of Services that can be deployed together. You can use a tutum.yml file which looks and feels just like a Docker Compose yml file to deploy multiple services.

Deploy Jenkins

To deploy Jenkins you must first create a Node, then head to Services and click “create service” Jenkins will be our service.

We can search the Docker Hub for Jenkins images, I’ll choose aespinosa/jenkins because its based on ubuntu, and running the build slave directly on the same node this makes things easy since I am farmiliar.

Fill out some basic information about the Service, like published ports, volumes, environment variables, deployment strategy etc. When your finished, click “Create and Deploy”

Once this node is deployed, as you made sure you forwarded/published a port, we can see our Jenkins endpoint under “Endpoints”

To configure this inside of Jenkins, create a new build item and under the SCM portion click Git and add your repository URL as well as your credentials.

We also can add a trigger for build to happen on new commits.

Our build steps are fairly simple for this, just install the dependencies and run configure, make, and make install.

Now to test our new build out, make a change to a file and push to the master branch.

Your should see an active build start, you should see it in your Build History

You can dig on that build # and actually see the commit that it relates to, making it really nice to see which changes broke your build.

This should let us add the build status to our Github page like the below.

Jenkins also allows us to view build trends.

Conclusion

I wanted to take a bit of time to run through a Continuous Integration example using Jenkins, Tutum, and GitHub to show how you can quickly get up and running with these cloud native platforms and technologies. What I didn’t show it how to also add Docker Engines as Jenkins Slaves for custom environments, if you would like to see that let me know. I might get some time to update this with an example in the future as well.

What is continuous integration?

If your wondering, here is a great article by Martin Fowler that does a really great job explaining what CI is, the benefits of doing so, drivers for CI and how to get there. Continuous Integration