How-to: Release and Publish Patch XD Versions

When critical or blocker issues are identified that warrant customer systems to be patched, use the following standard practices to ensure customer systems get patched and all subsequent maintenance upgrades include the proper release files.

Workflow

Notify Staff and Leadership of the upcoming patch
1. Team members need to be updated, so they can properly handle incoming CSD tickets, prepare urgent customer communications (if necessary), etc
  1. PLEASE NOTE: If the patch is due to regression test issues and is planned to be used for a scheduled release, all staff do not need to be notified. You will only need to notify the following teams- Engineering, SaaSOps, and Product.
Communicate with Engineering
1. Confirm that Engineering is prioritizing any development tickets that are needed for the patch
2. Get an ETA for when the developments will be ready for testing
Create a new release ticket in Jira with the following summary format “X Dispatch [Version] Release”
1. Example Ticket: XD-46280 that can be cloned and updated to the current patch information
  1. Project = X Dispatch
  2. Issue Type= Release
  3. Fix Version
    1. Add the fix version for the patch
    2. Click on the “+ Create New Version” option if the fix version is not already present
  4. Components
    1. Add all applicable components to the field located in the scrollable section on the right side of the ticket
  5. Labels
    1. Add the “Patch” label to to the field located in the scrollable section on the right side of the ticket
  6. Create filter for the patch fix version and add it to the release ticket
    1. If you cloned the previous patch ticket, just update the existing filter with the new fix version
    2. Example Filter
      1. You can update the fix version in this filter and then click on the Share button to get the new link related to this patch and then add it to the Release ticket description
  7. Create two (2) subtasks
    1. Patch Release Prep - [Type the specific XD Fix Version]
      1. Assign to the person coordinating the release
        
        Currently this is being performed by Christy Cocchia-Barbaree
    2. Patch Regression Test - [Type the specific XD Fix Version]
      1. Assign to the QA team member that is performing the patch regression test prior to customer release
Add the required fix versions to any applicable XD tickets (Branch version and next Trunk version)
1. All tickets that need to be included within the patch need to have BOTH the branch and trunk versions added
  1. EXAMPLE: If you are patching an issue within XD 25.2.2, you have to also add the XD 25.3.0 fix version since it is the next major release version
Create a SaasOps (DEVOPS) ticket and link it to the XD Release ticket
1. PLEASE NOTE: If the patch is for a scheduled release version, you do not need to create a SaaSOps (DEVOPS) ticket. They will need to be alerted of the incoming patch for 9906, but they will already have a ticket for the scheduled deployment of the new release to customers.
2. EXAMPLE TICKET
  1. Project = DEVOPS
  2. Issue Type = Task
  3. Component = Cloud Instance Upgrade
3. Indicate on following information within the ticket description
  1. What set of customers the patch is intended for: First Adopters or General Cloud
  2. What internal instance they should deploy the patch to for internal testing prior to customer release (Internal Cloud Resource Use and Policy)t
    1. 9909 - General Cloud Production
    2. 9908 - First Adopter Production
    3. 9906 - First Adopter Pre-Production
  3. What is the desired deployment date of the patch
4. Ping SaasOps within a ticket comment to alert them of the upcoming patch
Confirm all patch developments have been completed (Developed, Tested, Merged)
1. All tickets will need to be tested and merged into the branch and trunk versions by engineering prior to requesting a patch compile
  1. All tickets must be in the status of Regression Test in order to request a compile of the new version
Request Patch Compile
1. Change the status of the XD Release ticket to “Compile Release”
2. Assign the ticket to Derek Figg
  1. This is the current assignee as of 04/09/2025
3. After compile, Derek currently alerts Christy and DevOps that the files are up on Azure Storage and can be patched to our internal instance for testing
4. Testing begins once SaasOps alerts QA that the internal instance has been updated to the patch version
Release Jira Version
1. Navigate to “Releases” within the Jira left navigation of the XD project
2. Search for the patch release version
3. Click on the … Action menu and select “Release”
Internal Testing Environment Update by SaasOps
1. SaasOps notifies QA and Staff that internal instance has been patched via the OPS Google Chat
2. Once SaasOps notifies QA that the patch version has been updated on the specified internal instance, patch regression testing begins
Patch Testing
1. Update the XD Release ticket status to Testing
2. Assign the ticket to the QA team member that performs the regression
3. Notify QA through a ticket comment for historical record
4. Check in with QA team member via chat that they have seen the OPS chat message and confirm they have started the patch regression testing
Publish Package - QA Certifies or Fails the Patch Version
1. Version Certified (Passed Testing)
  1. QA team member will ping DevOps, Product, Engineering, Marketing, and Documentation teams on a release ticket comment indicating whether the patch version has passed or failed testing
  2. QA team member will log time for the testing onto the Patch Regression Testing [Version#] subtask and close it
  3. QA team member will update the release ticket status from Testing to Publish Package and assign the ticket to the team member managing the release. (This is currently Christy Cocchia-Barbaree)
  4. Release manager reviews the release ticket, confirms the patch was deployed to customers, logs any time, closes their Release Prep [Version#] subtask, and updates the status from Publish Package to Review Docs
2. Version Failures
  1. If the patch version fails testing and a new patch version needs to be created, the status on the failed patch version’s release ticket gets moved from Testing to Newer Branch Version Available
    1. This indicates that the patch was not deployed to customers
  2. QA team member updates SaasOps, Product, Engineering, Documentation, and Marketing to alert them that the patch failed testing and will indicate the new patch version number that we will be shifting to.
SaasOps Deploys the Patch to Affected Customers
1. SaasOps team member updates the OPS Google Chat to alert all staff that the patch is being deployed.
  1. Message will contain the patch version and what set of customers it will be deployed to
  2. If the patch is part of a scheduled customer upgrade, the patch will go out as planned on the specified upgrade date
2. PLEASE NOTE:
  1. Any patch versions previously deployed to First Adopters need to be added to Azure Storage so it can be automatically included by SaasOps when General Cloud gets upgraded to the version in the subsequent month. This ensures all customers get the appropriate fixes.
Review Documentation
1. Check in with Marketing and Documentation to see if they will be sending out a Release Blog for the patched version or if they will be updating the previous major release blog to include the additional patched items
Publish Package
1. Once all documentation and customer messaging is completed, update the status of the release ticket from Review Docs to Published