Installing and Configuring Jenkins

Published on May 07th, 2017

This weekend's technological adventure was trying to configure my personal site to use Jenkins, the automated Continuous Integration/Continuous Deployment server.

Background

I wanted to add Jenkins to this site for a few reasons outside of learning a new thing. We use Jenkins at work for confirming that new changes don't break the site. Jenkins periodically scans Git for new pull requests. When we make a new one, Jenkins automatically runs our test suite and then leaves a little badge on the side of the PR saying whether tests passed or not. We then review the code, and developers approve/reject the PR accordingly. We could set up Jenkins to also handle merging in the pull request, updating the code base on our servers, and restarting the application to push these changes live to the site. Instead, we still do deployments manually for a few good reasons:

  1. Our test suite is not yet an ironclad assurance that nothing will break with this new change
  2. We want our changes reviewed by multiple people, including the Product Managers who ensure that requirements are met, and developers who offer code reviews.
  3. Historically, deployments have been a rocky time for us, so it'll be a while before we trust a robot to handle it during times when we don't have all hands on deck.

For my personal site, none of these reasons are deal-breakers, so I'm going to go ahead with my personal ideal setup

How It'll Work
  1. Working on a local branch, I make changes to my site and push them up to a remote branch.
  2. Within GitHub, I create a new pull request to merge my branch into master.
  3. I go play video games.
  4. Jenkins picks up from there, running my test suite to affirm that I haven't broken anything.
  5. If there are mistakes, Jenkins marks the PR in GitHub as containing issues, and refuses to merge it into master. Jenkins then interrupts my video game session with a carefully worded email assuring me that he's not mad, just disappointed.
  6. If there are no mistakes, Jenkins merges the pull request into master.
  7. He then conducts a deployment script to bring my changes live.
  8. The site is updated, masses rejoice, and Richard Stallman personally delivers a fruit basket to congratulate me on a successful deployment. 

*I haven't figured out how to automatically trigger Step #8, since I don't think there's a webhook for Richard Stallman to deliver fruit baskets. Maybe I can set up an IFTTT for "masses rejoicing"

Assumptions

If you're just along for the ride, sit back and enjoy. If you're trying to set up something similar for yourself, here are few notes about my project:

  • Running a Django project via Gunicorn, managed by Supervisor
  • Version control is through GitHub, and changes are made via pull requests into the master branch.
  • Jenkins is running on the same server as the project, or with an existing proxy configuration to keep Jenkins's address private.

Let's Get Started!

For this guide, I closely followed this step-by-step guide, written by Michal Karzynski (whose blog posts should be bookmarked, read, and reread by every self-respecting Django developer). I would have followed it to the letter, and kept this blog post short, but I had a few issues that warranted walking through since the original post is now 4 years old.

I started by installing Jenkins as per the instructions on the official Jenkins-CI wiki

wget -q -O - https://pkg.jenkins.io/debian/jenkins-ci.org.key | sudo apt-key add -
sudo sh -c 'echo deb http://pkg.jenkins.io/debian-stable binary/ > /etc/apt/sources.list.d/jenkins.list'
sudo apt-get update
sudo apt-get install jenkins


About Me

See More Posts Tagged With:

Most Recent Posts:

Things I Write About