What is Continuous Delivery?
Continuous Delivery is the automation of not only the build and test lifecycle, but also the software development delivery lifecycle, in which customers receive the software that you're building. Everything that can be automated is automated, and this process is practiced often - with the goal of getting working software into the hands of the user as soon as possible.
Automating and repeating these lifecycles accelerate software delivery and reduce the chance of errors. A traditional release might contain 500 changes that a customer never uses, but a release in the Continuous Delivery model might only contain 5 to 10 changes. This difference reduces the risk involved in giving the customer a new version of the software. If errors exist, you can quickly release a new fixed version of the software, because the building, testing, and final delivery to the customer are all an automated process.
What is the difference between Continuous Delivery and Continuous Deployment?
In Continuous Deployment, the deployment phase of the development lifecycle happens automatically after the testing phase without any human interaction and irrespective to business concerns such as versioning, marketing, etc.
The Continuous Delivery method allows teams to automate the whole lifecycle, but teams get to choose when the deployment phase is executed. This methodology can be more preferable as it allows organisations to choose when software is released, in order to meet business concerns such as marketing launches, versioning schemes, or availability dates of the release.
Turn Your Build into a Lean, Clean, Delivery Machine
Most Continuous Integration builds commonly begin with a single step that builds the software, tests it, and packages it. In the beginning, small builds are easy to set up and are very quick to execute. Over time though, as the team adds more unit and functional tests, these builds begin targeting multiple platforms and start packaging steps, becoming more complex and increasing build times. The time between changes made and feedback received also increases, which forces development teams to spend valuable time maintaining the build rather than spending time working on features or other tasks.
In order to solve this problem, Bamboo allows developers to separate the building and testing phases into different Bamboo Stages. Bamboo can have a Stage with a single Job that compiles and packages the software. This packaged software is then passed on to another Stage, which executes the tests. Because Jobs can be executed in parallel, splitting tests into different Jobs means that they can run in parallel, significantly reducing the amount of time required to run test suites.
As a rule of thumb, each Job should not take more than 10-15 minutes to execute. Once this threshold has been exceeded, we recommend splitting the Job into 2 or more Jobs to cut down the execution time.
Sharing Files Between Stages
To Transfer files between Stages, Bamboo provides a feature called Artifact Sharing. Artifacts are files that are produced as a result of the build. In order for Bamboo to capture and share these files, you will need to create an Artifact Definition for the Job that the artifact is created.
To create an Artifact Definition, find the Artifacts section on the Jobs configuration page. Click Create Definition; give the artifact a recognisable name; and define where the artifact will be on the file system. To share it with other Stages, ensure you click the Shared checkbox.
When the Job builds, the artifact will be saved against the Plan result. In order for Jobs contained in later Stages to use these artifacts, they must subscribe to the artifact by using an Artifact Dependency.
To create an Artifact Dependency, go to the Artifacts section of the Jobs configuration and click Create Dependency. Pick the artifact from the list of available shared artifacts and provide a destination path. When the Job executes, Bamboo will automatically download the specified artifact generated by a previous Stage and place it in the directory specified.
A manual Stage only executes when the user directs Bamboo to do so. They are useful in situations like Continuous Delivery, where not every build should be delivered to the customer - leaving the decision to the discretion of the business. Multiple Manual Stages are possible too, in case each step needs to be manually confirmed and signed off.
Adding a manual stage is easy. Navigate to the Stages tab of your Plan configuration and click the Create Stage button. Then give your Stage a name and tick off the Manual checkbox.
Within the Manual Stage, you can now add a Job that:
- Deploys your web application to an Application Server (such as Tomcat or JBoss)
- Uploads files using sftp or ftp to your website
- Applies a Puppet or Chef configuration to your server machine
- Executes any other scriptable action that gets your software in the hands of users.
With the Manual Stage and its Job in place, whenever your build executes, it will stop at the Manual Stage you created. The status icon will no longer show the success icon but will display the partial success icon, denoting that the build has stopped to wait for manual intervention by the user.
To continue the execution of the Manual Stage, navigate back to the build result you wish to deploy and hit the start button in the Plan Navigator. The build will continue from that point. If everything is automated correctly, your software should now be in the hands of your customers.
Release in JIRA with a Single Click
Continuous Delivery is not just for developers; project managers can find good use for the practice as well. If an Application Link exists between the JIRA and Bamboo server, you can execute the deployment step of the process in Bamboo directly from JIRA.
In JIRA, navigate to the Version you wish to release, pick the Release tab, and click the Release button. JIRA will provide multiple options to release the JIRA Version, either by running a new Bamboo build, continuing a build from a Manual Stage, or running no build at all. Once the build has successfully finished, the JIRA Version will change from unreleased to released.