Page tree

This documentation page is for Golive 7.3 (Server & Data Center) | Older versions | Golive CLOUD

Skip to end of metadata
Go to start of metadata

Learn how to integrate Atlassian Bamboo CI with Apwide Golive with particular focus on:


Relationships between Bamboo and Apwide concepts

Bamboo conceptDetailGolive equivalenceDetail
ProjectGroup logically build plan together.--
Build PlanDefine the build process of your software and usually result in output binaries named artefacts--
ArtefactsOutput result of a build, usually a "physical" binary (jar, zip, war...) of your application that can be added to a release for being deployed on an environment--
StageRepresents a specific step in your build plan. It's composed of jobs that can be run in parallel. Plan can be composed of several stages and you can trigger different action on its successful execution (eg: deployment, trigger another plan...). A stage could be used to group the different jobs used to compile your software, and another stage could be used to group all the testing jobs.--
JobA job contains the sorted list of tasks (shell scripts, ant, maven, command) used to build your software.--
TaskAn atomic operation. Could be a shell script, an ant or maven command, a git operation...
Tasks are used to publish data from Bamboo to Apwide Golive using the REST API that can be called by a script task (eg: curl)

Releases are used to track exactly what software was deployed to an environment. In essence, a release is a snapshot of any number of artifacts that will be used in the deployment process.

Releases are versionned and they follow a naming convention that can be used by Bamboo to automatically generate the next available version number when the full chain is fully automated.


In Apwide Golive, current version of a specific application on a specific environment is tracked by a Deployment object.

Apwide Golive provides a Rest API that can be called to create a new deployment and update the deployed version of an environment.

By synchronising Bamboo releases with Golive deployments, your Jira users will be able to always get the current up to date deployment information + all history of past deployments.

Deployment Project

Deployment project is the container that holds:

  • Environments that represent the physical environments, such as QA, Staging and Production
  • Releases.

In some ways, you can see Bamboo deployment projects and projects as something that can be easily mapped with Apwide Golive application concept, more details below.


An environment is the mapping of a deployed release on a specific subset of machines.

Environment contains its deployment plan (similar to build plan but to deploy a release on a specific machine/environment) which defines how a specific release (a set of artefacts) will be published on its environment (that can be composed of several machines).

It's in this deployment plan that we are going to add additional steps to publish/synchronise the release version between Bamboo and Apwide Golive

Environment (Application-Category)

Golive Environment is the equivalent of Bamboo Environment. It's defined by the combination of an Application (eg: eCommerce) and a Category (eg: Prod, QA, Demo...). An environment can have one status and one release number deployed at a time.

In Bamboo, even if an environment is described as "Staging", it may be composed by several applications. In Apwide you may split this environment into several environments per application (ex: eCommerce Staging and ERP Staging) if you want to easily differentiate their technical requirements, lifecycle,...

That's why in Golive environments are defined by the combination of a category (eg: Staging, Prod...) and an application (eg: eCommerce, ERP...). 

You can naturally freely decide how you want to model and map environments in both tools.


Apwide Golive provides to Jira the concept of Application, that you can use to map your applications to your Jira projects and Jira versions.

Continuous Integration Use Case

In our use case, you will learn how to automatically push deployment information to Apwide Golive when a deployment is triggered in Bamboo.

To achieve this, you have to add one task to your existing build process. This task will publish new release version to Apwide Golive using the Apwide REST API.

Screen flow

In Bamboo, we can see how project and environment have been structured:

Here the equivalent environment structure in Apwide Golive:

Now, if we look at the deployment plan in bamboo for the dev environment, we can see the following tasks:

We have added a curl script to call the Apwide Golive REST API.

Script samples to call Golive Rest API from Bamboo:

Update status to "deploy"

curl --user ${bamboo.apwide.user}:${bamboo.apwide.password} -X PUT \
  '${bamboo.apwide.url}/status-change?application=${bamboo.deploy.project}&category=${bamboo.deploy.environment}' \
  -H 'Accept: application/json' \
  -H 'Content-Type: application/json' \
  -d '{
	"name": "Deploy"

Update deployed version

curl --user admin:admin -X PUT \
  'http://localhost:8080/rest/apwide/tem/1.1/deployment?application=${bamboo.deploy.project}&category=${bamboo.deploy.environment}' \
  -H 'Accept: application/json' \
  -H 'Content-Type: application/json' \
  -d '{
	"versionName": "${bamboo.deploy.release}",
	"deployer": "bamboo"

Update environment attributes

curl --user ${bamboo.apwide.user}:${bamboo.apwide.password} -X PUT \
  '${bamboo.apwide.url}/environment/${}' \
  -H 'Accept: application/json' \
  -H 'Content-Type: application/json' \
  -d '{
	"url": "${bamboo.application.url}",
	"attributes": {
		"Last Deploy Result URL": "${bamboo.resultsUrl}",
		"Bamboo Environment URL": "${bamboo.bamboo.url}/deploy/viewEnvironment.action?id=1245188",
		"Bamboo Application URL": "${bamboo.bamboo.url}/deploy/viewDeploymentProjectEnvironments.action?id=1146883",
		"Owner": "${bamboo.environment.owner}",
		"Database": "${bamboo.environment.database}",
		"OS": "${bamboo.environment.OS}",
		"# servers": "${bamboo.environment.servers}"

Update status back to "up"

curl --user ${bamboo.apwide.user}:${bamboo.apwide.password} -X PUT \
  '${bamboo.apwide.url}/status-change?application=${bamboo.deploy.project}&category=${bamboo.deploy.environment}' \
  -H 'Accept: application/json' \
  -H 'Content-Type: application/json' \
  -d '{
	"name": "Up"

Bamboo variables

You can use variables from:

Build and Deployment Process Example

  1. A commit is triggered on an SCM
  2. Build plan, located in a specific project (eg: eCommerce) is triggered
  3. When build is successful, artefact is generated and made available to other build/deploy plans
  4. In a deployment project (eg: eCommerce), a trigger is configured to trigger deployment to an environment (eg: Dev) when the corresponding project build plan was successfully built
  5. A release (following the naming convention scheme) is generated containing the artefacts
  6. The deployment plan deploy the release to the environment
  7. The last task of the deployment plan updates de the deployed version of the corresponding environment in Apwide Golive


  • In Bamboo, if a deployment plan is triggered several times with the same release on the same environment (with the same version number), Apwide Golive will not consider this deployment as a new deployment. You should add something different (ex: build number) in the name of the deployed version in order to track this kind of change in Apwide Golive deployment history.
  • If you proceed with the following mapping, you can easily reuse Bamboo variables to complete the call to the Apwide Golive REST API:
    • Bamboo deployment project to a Golive application
    • Environment name to Category Name
    • Release name to deploy version name
  • Apwide Rest API credentials should never be declared in clear in the tasks (use global variables).


  • No labels