DevOps Corner: How I use Jenkins

Jenkins is a "continuous integration" utility that is widely used for testing code to make sure no bugs are introduced.  It obviously works great in this regard... but I use it for a different function.  I am the resident DevOps person here at RDG.  This involves a lot of server managment.  Much of this server management is centered around shell scripts of one kind or another.  These shell scripts may invoke chef or run drush among many, many other things.  

While I enjoy doing server management and automation, I don't want to be the only one that does this on the team, or be involved for every single thing that needs to happen regarding a deployment.  This is where I leverage Jenkins.  Even though Jenkins is structured in a way that is optimal for continuous integration it is great and just running shell commands and our various servers.  All that is required is a little configuration to make sure the jenkins server can communicate with the other server via SSH.  Once this is in place a job can be created, and anyone that has access to your Jenkins instance can run that command without having to understand the nitty gritty of what goes on at the command line.  

This also enforces consitency.  For example... say every time I deploy a new Drupal website I need to 

• Log into the production server
• cd to the site's home directory
• issue a git pull from the master branch
• run 'drush cc all' which clears the cache for the website making sure all new code is in use and ready to go.

If we just rely on each person having the ability to SSH to the server and take care of these tasks, there is bound to be some variation.  Maybe user permissions? Or not running the drush command at the end to clear caches?  

By creating a Jenkins project that simply SSH's to the server and executes these commands we can ensure that we have consistency every time the site is released to the production server.

The various servers can be set up in Jenkins config. And ssh keys will help make the process smoother.

If you are completely new to Jenkins... remember that this is a java application that demands a fair amount of memory at times.  It doesn't have to be on it's own server, but that certainly helps. 

If you wish to create a more customized deployment system you can still leverage Jenkins and create an app in the language of your choice that simply makes RESTful calls to the Jenkins instance.  Just about anything done in Jenkins, can be done with a REST service request.

There are endless ways to improve this process, some of which I've done.  Utilities like chef help keep the different environments in check.  Then Jenkins can invoke the chef processes rather than the specific shell commands for a deployment.