What are deployment projects?A deployment project is a container for holding the software project you are deploying: releases that have been built and tested, and the environments to which releases are deployed. Teams typically have QA, staging and production environments. Why use deployment projects?Continuous Integration was not designed for Continuous Delivery. Continuous Integration is designed to keep developers informed about the state of the latest code changes. In Continuous Integration, historical build results (along with information such as issue and commits) are de-emphasised as more changes are made, since only the latest build is important to the developer. Using a traditional Continuous Integration server for Continuous Delivery is less than ideal because: - Deployed builds are difficult to find – Builds that were deployed only a few days ago are de-emphasised by the system. While this is good for a Continuous Integration workflow, the behaviour makes it difficult for team members to identify which builds have been deployed and when, versus which have not. Teams can work around this with a system that uses labelling but it's not immediately obvious how it should work unless team members are trained to use it correctly.
- Difficult to find what changes were made between deployments – Build results report commit and issue data between a specific build result and the one immediately before it. There can be many build results between two different deployments. Often the entire history has to be navigated between the two deployments to build a complete view of the changes between them. Sometimes, even other tools have to be used, such as version control systems.
- Difficult to know what was deployed, and when and where it was deployed – Builds do not have visibility of where code is deployed or what was previously deployed to an environment.
- Lack of insight into the QA process – Given a list of deployment candidates, builds offer no clear way (other than commenting or labelling) for QA to 'sign off' on a tested release or mark a release as broken or un-releasable.
- Poor control over who can deploy – While it can be controlled by permissions who can run, view or edit a build, they do not give enough fine grained control over which people in the team can deploy to production or other sensitive environments. In essence, if someone has permission to run the build they can deploy the software any time they wish.
To solve these issues Bamboo provides the following concepts: - Deployment project – Represents the software you are deploying (such as a web application), the releases of the software deployed and the environments that they will be deployed to throughout the lifecycle.
- Environment – Represents the servers or groups of servers where the software release has been deployed to, and the tasks that are needed for the deployment to work smoothly. Example environments could be named Development, QA, Staging or Production. Environments have permissions that allow fine grained control of who can deploy, edit or view an environment and record the full history of releases deployed to it.
- Release – Identifies a snapshot of artifacts and its associated data such as commits, JIRA issues and the builds that were used to test it. As a release contains the information of the difference between itself and the release beforehand, it's very easy to see the changes between releases or to show the difference between the software deployed on two different environments. Releases also track what environments they have been deployed to.
How do deployment projects work?Consider the following diagram: | 