Last updated Dec 8, 2017

Introduction to 5.0 - Deployments

In Bamboo 5.0 we introduced deployments.  Deployments was developed as a separate component from builds and plans, but with various integration points between them. This page will provide you with a basic overview on Deployments from a developers perspective and how to make your plugins work.

Concepts

For an overview on using deployments please visit: https://confluence.atlassian.com/display/BAMBOO/Deployment+projects

Deployments have three major components.  Deployment Project, Environment and Deployment Project Version.  Users create a Deployment Project that defines WHAT is going to get deployed.   Each project contains environments, representing both the WHERE and HOW the deployment will happen.  At the time of deployment, a version is created representing a snapshot of the WHAT.  This version then gets deployed to an environment.  Environments use Tasks, the same as Jobs to define how a version gets deployed. 

When a user creates a Deployment Project they select a plan.  From this plan Bamboo creates Deployment Project Items representing each artifact the plan is sharing.  At version creation Bamboo will takes these Items and grab the appropriate artifacts from the plan  to create the Deployment Version and the deployment version items.

Deployments whilst different in the UI so use the same execution/agent mechanisms as regular plans.

Tasks

Tasks are still a big component of deployments defining each individual step to get a version deployed.  Tasks are fully pluginable.  You can find a full tutorial on developing Tasks for Bamboo on the Bamboo Tasks API page.  All existing tasks should work with Bamboo 5.0 builds, but need adjusting to support deployments.  The following section highlights the differences between Deployment tasks and Build tasks and the changes you might need to make.

Interfaces

To maintain backwards compatibility with existing tasks, the original task interfaces have been left alone.  We have introduced two new interfaces, a super-interface to be used when supporting BOTH builds and deployments and a Deployment specific interface

Pre 5.0:

  • TaskType
  • TaskContext
  • BuildContext
  • BuildTaskRequirementSupport
  • CurrentBuildResult

Post 5.0:

  • Supports both Build And Deployment
    • CommonTaskType
    • CommonTaskContext
    • CommonContext
    • TaskRequirementSupport
    • CurrentResult
  • Support Just deployments
    • DeploymentTaskType
    • DeploymentTaskContext
    • DeploymentContext
    • DeploymentTaskRequirementSupport
    • CurrentResult
  • Support Just Builds
    • TaskType
    • TaskContext
    • BuildContext
    • BuildTaskRequirementSupport
    • CurrentBuildResult
TaskType

Which task type interface you implement determines where users will see your task and where they can be executed.  If your plugin implements CommonTaskType it will be available to use in both jobs and deployments.  If you implement DeploymentTaskType or TaskType, your task will only show in deployments or builds respectfully.  If you would like to support both builds and deployments but need slightly different behaviour your plugin can implement both DeploymentTaskType and TaskType.

Each interface takes in a different type of TaskContext

TaskContext

There are currently no tangible differences between the different task context classes. They exist purely to provide plugins with the correct type of Build context

BuildContext

This is where the biggest pain points will exist when converting over your task to Deployments.  Deployments do not support many of the features that Jobs do, so we have had to create a new cut down context, that provides access just to the common components of both Deployments and Builds.  So for a task to be compatible with both deployments and builds you need to ensure you only use methods on the CommonContext. 

What deployments don't have

  • Build Definition
  • Tests
  • Revisions/Checkouts/Build Changes

Task Configuration

Configuration behaviour and classes have not changed at all.  Just double check that you are not referencing the plan or plan key from your edit templates

Other deployment plugin points

Repositories

Bamboo has provided a very cut-down checkout capability in Deployments, expecting that the majority of work should be done in a plan then transferred into deployments via artifacts.  This cut-down functionality only works for a subset of repository types.  If you have a repository plugin that also needs to be available for deployments, you will need your repository to also extend DeploymentAwareRepository.

Notifications

Deployments use the same notification infrastructure as plans.  Note that while the event system for deployments is not as advanced as builds (at the time of writing), you may still want to introduce your own notification types.  Follow the guide on Building a Notification Plugin and set the scope of your notificationType plugin to

1
2
<scope>deployment</scope>

Rate this page: