Imagine you have a software module whose releases are built via a Jenkins, Hudson or Bamboo job. The basic process to perform such a release build is:
You may want to document time, initiator and outcome of each release build in JIRA to be able to deliver reports to the management. A simple implementation of such a workflow may look like this:
The Service Integration plugin allows to add the postfunction Call a Service to the Start Release transition which starts the build job - eventually using parameters from the JIRA issue fields.
Performing the Start Release transition, any developer can now start the release build without the need to switch to the build server's interface - even without owning an account on the build server, since the credentials for accessing the build server via a technical user can be stored in the plugin configuration.
To implement full automation of the workflow, the build job can be configured to communicate the outcome back to JIRA once the job has finished.
This can be done by adding a post-build action to the job configuration which calls the JIRA REST API to add data like log-messages as comment to the issue and performs different transitions to transfer the issue in another state, depending on the outcome of the job.
The Call a Service postfunction transmits all necessary information (JIRA URL, issue-key, transition IDs) as parameters to the job - for details check the callback documentation page.
To prevent users from performing these transactions before the job has finished, the transitions should be restricted to be performed only by a technical user which is configured in the post-build action. The dotted lines of the Resolve and Fail transitions denote this intention.
Future versions of the Service Integration plugin will provide functionality to configure this technical user in the plugin and/or postfunction configuration.
If the job succeeds the ticket is automatically moved to status Resolved which denotes that the release succeeded and the resulting artifacts are available for deployment.
If the job fails, the ticket is put in status Release Failed and the developer is in charge to fix the build and re-perform the release or to cancel the ticket to communicate a failure.
