Developing for the cloud means embracing new processes that streamline each step, from initial design to eventual deployment. If you’re used to agile development and a DevOps environment, switching to cloud should feel natural.
If you use traditional development practices and habits (longer development cycles and building monolithic applications that conclude with you throwing your build over the wall to Operations) you may need some time to adjust.
Either way, an investment in these new development tools will save you time in the long run. Many developers are adopting a practice that is perfectly suited for the cloud: Continuous Integration.
Continuous Integration (CI) is the process by which code can be automatically and incrementally built, tested and deployed. Developers make smaller, more incremental changes to a code base that is updated many times a day. Ideally, each time the code is updated, an automated process will begin that builds the project, runs a suite of tests and merges it into the main branch of the code repository. Upon an update of the main branch, the automated process should begin the code deployment.
What Can You Do With CI?
Automate
Automating the entire build, test and deployment process will make you much more efficient. You’ll no longer need to spend time running individual tests or waiting for a build to complete.
Avoid Hell
Integration Hell happens when a horde of developers make many changes to the same part of the code base simultaneously. Avoid this mess by making smaller code changes, incrementally.
Fix Fast
Bugs happen. Having an automated process to build, test and deploy can greatly reduce the amount of time and effort needed to get a crucial fix out to users. An added benefit is that new updates can be deployed on a timely basis.
Try These CI Tools
There are several popular CI solutions out there. Here’s a look at Bamboo and Jenkins.
With Bamboo, a developer can design and implement a Bamboo Plan that can go through the entire process of building code, testing it, then deploying it. Plans are divided into Stages which represent one step of the process (compiling the source code, for example). A Stage contains one or more Jobs. When a Plan begins to execute a Stage, all Jobs within that Stage are executed in parallel. Each Job is composed of one or more Tasks. A Task represents a small workload necessary for the Job that it is contained in. Examples of Tasks include running a shell command or the execution of a script to start a unit test. Each Task within a Job will be run in sequence.
When a Bamboo Plan is triggered (whether manually or automatically), the first Stage begins to execute. The Plan will not move on to the next Stage unless all Jobs complete successfully. Stages can be also configured so that they can only begin after the user manually presses a button. This structure gives the developer the flexibility to design a fully-automated build and deploy process.
Now for Jenkins. A developer can create a Jenkins Job that can check out source code from a repository and build it, or deploy built code to a production environment. The developer can chain these Jenkins Jobs together to create a CI workflow that automates the entire process.
Jenkins is extremely customizable – there are many plugins available that allow the developer to create many different types of jobs or to provide additional features. One such plugin that is used regularly here at RightBrain Networks is the S3 Jenkins Plugin, which allows the developer to publish build artifacts to an AWS S3 bucket.
Both Jenkins and Bamboo have been very useful to our team in different ways. Personally, I don’t prefer one over the other. I find that if you’re looking to do something really specialized (like the AWS plugin mentioned above) then Jenkins makes sense. Bamboo provides a more structured process for setting up a CI plan, has a prettier UI, and is easily adaptable for subsequent projects.
What CI solution works for you, and why? Please post your comments below.