Jungle Buzz by Wes Dunn Oct 17, 2016 Behind the Scenes - How Jungle Disk Uses Continuous Integration Software and Slack to Speed Development Cycles When you think about Jungle Disk as a software company, you likely think of our backup application software that you install directly onto a computer or server. While this application is at the core of our business, there is a whole world of applications and services that run behind the scenes and support the functionality of our core software. Much of our development work is focused on these services and we need to be capable of quickly deploying updates to the code that makes everything work. In this post, I will focus on how we have utilized continuous integration (CI) software and our internal communication tools, Slack, to shorten the amount of time it takes for us to release code to our core back end services and our customer control panel. So, what is Continuous Integration? A simple definition would be a software development strategy that automatically integrates code changes into an existing application. Basically, when a developer “commits” their code changes, there is another system that will see those changes and rebuild the application with the new changes. This is very useful because it allows for development teams to notice problems early and before they make it to the “production” servers that customers use. Here’s a breakdown of what we use: Github - Used for version control purposes and general storage of our source code. Jenkins - Industry-leading CI application that watches GitHub repositories for changes and rebuilds applications when changes are made. Slack - Awesome chat application we use for internal communication. Lita - A “chat-bot” platform that we used to build a bot that communicates build statues and can be given commands. Docker Cloud - The “bot” itself is running in a Docker container on Amazon Web Services, we use Docker Cloud to manage and deploy the bot itself. To paint the picture of how all of this technology fits together, I’d like to walk you through the process of making a change to our control panel web site and deploying it to our live production servers that customers use 24/7. A developer writes new code and changes code for our customer control panel. Code is tested on the developer’s computer and is committed to GitHub when all changes are finalized and pass some basic tests. Our Jenkins server notices the newly committed code and kicks off a job that rebuilds the web site and posts the result of the job into a “channel” in slack. Hooray, everything was built successfully! Before we can “ship” the code to our production server, we want to test everything on a testing environment that very closely resembles the production server. We use our Slack “bot” to deploy this code to the testing server. We lovingly call our bot “Deploidberg” (we love Futurama, so why not Deploidberg!?). With a simple command in Slack, Deploidberg works with Jenkins to move the code to the testing server. Once this job is complete, Deploidberg gives us the results and also notes the last code that was committed for this version of the control panel. At this point, we test out the changes and if everything looks good. Then, we’re ready to push the changes out to our live servers. With a quick command to Deploidberg, we trigger a job that deploys the code out to our production servers. Once the job is done, we get confirmation in Slack. At this point, the changes are live and customers are using a new version of the Jungle Disk control panel. Here’s a screenshot of what Deploidberg is capable of doing: These tools have been integral in our ability to speed up our development cycles and improve our capabilities of releasing code at a faster pace. The big advantage here is that we have a more seamless process to shorten the development cycle from the time we get feedback from the customer to implementing enhanced features and finally deploying code that updates the software to include the customer’s feedback.