How Jenkins can work for the Whole Team

UPDATE: Slides available at http://t4k.github.io/drupalcon_2015/

On our team this used to be a common scenario:

Developer: can you do a git pull on dev
SysAdmin: which site?
Developer: oh, example.com
SysAdmin: ok, done
… 30 minutes later …
Developer: ugh, sorry to bug you again…
SysAdmin: AFK
Developer: I need another git pull
SysAdmin: AFK
Developer: ok maybe tomorrow

Enter Jenkins.

Jenkins doesn’t care if the SysAdmin wants nothing to do with the Developers anymore. All deployments are a piece of cake that anyone on the team can handle.

In our setup now we have Jenkins handling a number of tasks. For us it will:

• watch repositories for new commits and trigger builds.
• use different scripts for different types of builds or tasks.
• roll back a build to a previous state upon an error.
• run tasks for automated testing using Behat and Saucelabs.
• provide a nice interface for monitoring build status and history.
• allow for granular permissions for different team members and tasks.
• send optional messages upon success or failure of builds to email or HipChat rooms.
• regularly run a custom script to convert received emails into support tickets.

All in all our team has benefited greatly from having Jenkins as part of our workflow.

In this presentation I will make the case for SysAdmins to give up a little control so that their team can help themselves when it comes to these sorts of tasks. I will show the various pieces of Jenkins that we use along with some of the external components we utilize in our workflows. I’ll also show how Jenkins can be extended using freely available plugins for other integrations.