Hi,
I’m looking for some advice on whether Exalate can support an Azure DevOps → Jira integration that is slightly different from the usual one-to-one work item synchronization.
What we’re trying to achieve
We have an Android build pipeline running in Azure DevOps.
When the pipeline creates a new APK, we want to update a custom Build information field (customfield_1234) in all Jira issues related to that build.
The purpose is simple: testers looking at a Jira ticket should be able to see the latest Android build containing that change and download it.
Azure DevOps is the source of the update, and this is one-way only: Azure DevOps → Jira.
Information produced by the pipeline
For each build, the pipeline already determines:
- The affected Jira issue keys, for example JIR-123, JIR-124, JIR-125
- Build name, for example 1.2.0-5678
- A link to the APK in Azure Artifacts
- Environment, for example Development, Integration, or Production
The pipeline already contains the logic for identifying which Jira issues are associated with the build.
Updating the Jira field
Each affected Jira issue has a rich-text custom field called Build information (customfield_1234).
For the purposes of this question, assume that this field contains a single table such as:
| Environment | Build |
|---|---|
| Development | 1.2.0-5677 |
| Integration | 1.2.0-5676 |
| Production | 1.2.0-5677 |
If a new build is generated for Integration, for example:
- Build: 1.2.0-5678
- Environment: Integration
- APK: https://…
we want to update only the Integration row in each affected Jira issue.
The build name in the second column should also be a hyperlink to the APK.
If the Integration row doesn’t already exist, it should be added. If the field/table doesn’t exist yet, it should be created.
The current implementation already does this successfully by reading customfield_1234 through Jira’s REST API, manipulating its Atlassian Document Format JSON, and writing the updated value back.
The complication: we don’t use Azure DevOps work items
Our development teams use Jira for work tracking, not Azure DevOps Boards.
Therefore, there isn’t an Azure DevOps work item corresponding to each Jira issue.
The event we effectively want to process is a pipeline/build run, and one build can apply to multiple existing Jira issues.
For example:
Azure pipeline
|
| Build 1.2.0-5678
| Environment: Integration
|
+--> JIR-123
+--> JIR-124
+--> JIR-125
Possible Exalate approach
One option we’ve considered is having the pipeline create an Azure DevOps work item representing the build event, with information along these lines:
{
“ticketIds”: [
"JIR-123",
"JIR-124",
"JIR-125"
],
“buildName”: “1.2.0-5678”,
“buildLink”: “https://…”,
“environment”: “Integration”
}
Exalate would then somehow need to use that information to update the existing Jira issues listed in ticketIds.
Once processed, the Azure DevOps work item could simply be marked as completed.
We’re not committed to this design. It’s just one possible way we thought of providing the pipeline-generated information to Exalate.
Questions
What we’d like to understand is:
- Can Exalate use one Azure DevOps work item/event to update multiple existing Jira issues?
- Can the list of target Jira issues be determined dynamically from Jira issue keys supplied in an Azure DevOps field, rather than having a predefined one-to-one Exalate relationship?
- On the Jira side, can an Exalate script read the existing value of a rich-text custom field, modify it (by updating the row or creating a new one) of an Atlassian Document Format table, and save the updated field?
- If this architecture doesn’t fit the way Exalate is intended to work, is there a better Exalate-supported pattern for passing pipeline-generated information to multiple existing Jira issues when there are no corresponding Azure DevOps work items?
Our main requirement is essentially:
Pipeline produces build → pipeline identifies Jira issues → latest build for an environment is added/updated in the Build information table of each Jira issue.
We currently achieve this by calling Jira’s REST API directly from the pipeline, but we’re investigating Exalate so that we don’t have to manage Jira API credentials within our Azure DevOps pipeline. That aligns with our internal preference for centrally managed integrations rather than independently created API credentials.
Any advice on whether this is possible with Exalate, and what the recommended architecture would be, would be greatly appreciated.
Thanks!