This short article will give you good reasons and best practices to have always up-to-date deployment information in Golive.

Why should you do this?

Because Golive is really good at sharing deployment information with the relevant people.

You can easily browse the deployments history of your environments from the different types of environment views, issue page and environment details right in Jira.

Example of information you can get automatically in Golive from your deployment tool
(Jenkins, in this example)

Golive users can also individually choose to watch an environment in order to automatically receive email notification when a deployment is performed.

You can also use automations to send new deployment information to Slack or Teams channels or any other destinations using custom webhooks.

What is the challenge?

Golive is good to communicate and to track deployments but it is not performing the deployments by itself. The deployment workflow is intrinsically tied with the type of apps to deploy and your target infrastructure.

Update deployment information manually

One solution could be to update manually the deployment information in Golive once the job is performed. It is still better to use a spreadsheet… but this manual process will quickly become error prone and tedious when the number of apps and deployments will start increasing.

Integrate with your existing deployment jobs

A much better “DevOps” solution would be to adapt your deployment tool/scripts in order to automatically inform Golive about the deployment progress and environment state evolution.

This can easily be performed by people who know how to call a Rest APIor react to webhooks.

This is the best approach for applications and environments that have a fully automatic deployment process.

Check our integrations with main stream build and deployment tools: here

Get deployment information from the target environment/deployed app

When deployment can be executed manually (ex: user installs himself a new version of the app on a smartphone, installation of a new plugin/add-on from the UI,…) there are no automatic deployment job you can safely use to get up-to-date deployment states.

Except if you want to rely on a manual process, you should find a way to retrieve this information from the target environment or the deployed app:

Target environment

Managed environments often provide API (or webhooks) in order to retrieve (or push) information of their deployed components.

For example, Kubernetes (K8s) API could be used to retrieve the versions of the deployed containers and to push this information to Golive using the Rest API.

Deployed App

The app itself may expose an endpoint to retrieve its configuration and version information. If you are developing custom apps it may be a good idea to include this kind of endpoint in your api. This would give the possibility to retrieve the up-to-date deployment information from your environments and to push it to Golive using the Rest API.

Practical Examples

Send deployment information from a Jenkins pipeline

Here are examples of steps you can re-use in your Jenkins pipelines to send deployment information from Jenkins to Golive:


pipeline {
    agent any
    environment {
    // APW_JIRA_BASE_URL = ''
    // APW_JIRA_CREDENTIALS_ID = 'jira-credentials'
    // Better to define above environment variables globally

        VERSION_NAME = ""
        BUILD_NUMBER = currentBuild.number

        DEV_ENV_ID = 6 // identifies the target environment

    parameters {
          name: 'PROMOTE_TO_ENV', 
          choices: ['Dev', 'Demo'], 
          description: 'Should the output be promoted to an environment ?'
    stages {
        stage('Build & Test') {
            steps {
                script {
                    sh 'sleep 2s' 
                    // this simulates a build stage
        stage('Deploy on Dev') {
            when {
                equals expected: 'Dev', actual: params.PROMOTE_TO_ENV
            steps {
                sh "sleep 5s" // this simulated a deployment execution
                  environmentId: env.DEV_ENV_ID, 
                  version: env.VERSION_NAME, 
                  buildNumber: env.BUILD_NUMBER
                // this pushes the deployment information to Golive
                // N.B. This also automatically adds the list of Jira tickets 
                // found in commit history (since the last successful build),
                // to the deployment description

This example uses the open source Apwide Golive Jenkins Shared Lib

Automatically get the versions of the apps installed on your Jira servers

At we use several testing environments to deploy and test the various versions of our Jira apps. As we are installing our apps manually on certain Jira environments (ex: on our DEMO environment), we had to find a solution to retrieve this information directly from our test Jira instances.

Following the “eating your own dog food” principle, we are using Golive to track the versions of our apps that are deployed to our various Jira testing environments.

Model our testing environments in Golive

First step was to store all information (required to query our testing environments) in Golive:

Some of our apps testing environments modeled in Golive

Jenkins job retrieving and pushing current deployment state of our apps to Golive

This pipeline is executed every 5 minutes by Jenkins to update status and deployment information of your Jira apps:

pipeline {
    agent {
        label 'monitoring'
    options {
        buildDiscarder(logRotator(numToKeepStr: '1'))
    triggers {
        cron('*/5 * * * *')
    environment {
//        APW_JIRA_BASE_URL = 'https://your-jira-data-center-base-url'
//        APW_JIRA_CREDENTIALS_ID = 'jira-jenkins-user'
        APW_GOLIVE_CLOUD_CREDENTIALS_ID = 'golive-cloud-api-token'
    stages {
        stage('Apwide Jira Applications Monitoring') {
            steps {
                apwCheckEnvironmentsStatus criteria: [
                        'jira-plugin-key': '*'
                ], checkStatus: { environment ->
                    def pluginKey =['jira-plugin-key'], "UTF-8")
                    def baseUrl = environment.attributes['base-url']
                    echo "baseUrl: ${baseUrl}"
                    def credentialsId = credentialsMapping[]
                    def pluginInformation = apwCallJira(
                        jiraBaseUrl: baseUrl,
                        jiraCredentialsId: credentialsId,
                        path: "/rest/plugins/1.0/${pluginKey}-key" //
                    def pluginVersion = pluginInformation.version
                    echo "Plugin version: ${pluginVersion}"