HaloITSM

HaloITSM Guides

Documentation to assist with the setup and configuration of the HaloITSM platform

Guides > Software Releases

Software Releases

In this guide we will cover:

- What is the Software Releases functionality? 

- Configuring Software Releases

- Using Software Releases

- Logging work for a release (tagging tickets to a release) 

- Viewing the changes made within a version

- Sending Release emails

- Tracking Release Issues and Statistics



Associated administrator guide: 



What is the Software Releases functionality? 

Halo provides the ability to track and manage software releases for products your company supplies. Multiple products, release types and release note sets can be configured, providing a comprehensive way to organise and track each change made to your products. 


Each time a change needs to be made progress can be tracked using a change request ticket in Halo. These changes can then be tagged to releases for specified products, to help you monitor when each change was made/released. Release emails can be configured to easily send a bulk email to users who requested a change upon the release of a new version. The functionality also supports incident management for software releases. Raised incidents can be linked to a product's release, all incidents linked to this release will be visible against the release itself, allowing you to easily monitor the number of open and total incidents for a particular release.


We also have a number of integrations that can be used in conjunction with the releases functionality including: Azure DevOps Integration and Jira Integration. 


Configuring Software Releases

Enable Software Releases

To enable this feature, head to configuration and enable the module 'Software Releases' using the '+' icon. 

Fig 1. Enable software releases module 


Once enabled, click into the module to begin configuration. 


Setup Products

You will first need to setup products that you would like to track releases for. This is done by clicking the 'Setup Products' button in the Software Releases module. When creating a new product, you will be prompted to give the product a name and an option to list any components, should you wish. 

Fig 2. New software product


After saving the product with the given name, you will be able to configure release emails.

Fig 3. Configure release emails


Here, you can configure a release emails for this product, per release type. Each release for this product will be assigned a release type (covered shortly), this will determine the email template used for the release email, we will cover this in more detail in the section 'Sending release emails'. 


Under the 'Releases' tab you will be able to see all the releases that have taken place for this product, you will not have any data in here yet as no releases have been made. 


Configure Release Types 

Release types allow you to classify each software release, each release will be assign a release type, which provides a way to organise releases within a product and determine which email template will be used for the release email. 


To create new release types, head to Configuration>Software Releases and click into 'Release Types'.

Fig 4. Configure release types


Halo comes with out-of-the-box release types:

  • Not Released
  • Beta
  • Live
  • N/A

But creating your own bespoke release types is as simple as clicking 'New' and giving your release type a name. 


Once named you will need to associate the release type with a 'Release Note Set', this will associate this release type with the correct release note set. This field must be set in order for release emails to be able to be sent for releases of this type. 


Configure Release note groups

Each change made as part of a release can be assigned to a release note group. Release note groups are used to organise the individual changes within a version, for example into 'New features' and 'bug fixes'. This is used for further categorisation of release notes (changes). 


Configure release note groups under configuration > software releases > release note groups > new. When creating a new release note group you will just need to give it a name and set an overarching release note for this group. 

Fig 5. New release note group


Configure Release note sets for tagging

Now you will need to configure your release note sets this allows you to tag tickets (change requests) with a specific release version. Tickets tagged to a release version will be included in the release notes for that version, that is they provide a record of the change(s) that have been made to the product as part of this release. 


Under configuration > software releases, beneath the 'Product and Release Setup' options, you will find the 'Release Note Tagging' configuration:


Here you can enable and re-name up to three release tags. If all three are enabled, you will be able to tag a single ticket to three release versions. 


Enable release tags by checking, 'Use Beta Release', 'Use Candidate Release' and 'Use Stable Release'. Once each of these are enabled you will be given the option to re-name the release tag field, the name entered will be used as the name of the field against the ticket in which the release version is specified. 

Fig 6. Options to enable release note sets and re-name the set field name


Once you have enabled your sets you will notice some additional settings to control how/when tickets are tagged to releases. 


Automatic Tagging

Automatically tag notes from Beta releases which are not tagged against a Candidate release when releasing a new Candidate with a higher sequence- When enabled any tickets that are tagged to a Beta release will automatically be tagged to a candidate release when a candidate release of a higher sequence is created. The candidate release they are tagged to will depend on the 'Automatic Tagging Method (Candidate)' chosen.

Automatic Tagging Method (Candidate) - This determines how tickets are automatically tagged to candidate releases.

  • Tag to the version being released- When selected the ticket will be tagged to the newest release in the 'Candidate release note set'
  • Tag to the same version as the Beta tag- When selected the ticket will be tagged to the same version as the Beta release in the 'Candidate release note set'.

Automatically tag notes from Beta and Candidate releases which are not tagged against a Stable release when releasing a new Stable with a higher sequence- When enabled any tickets that are tagged to a Beta or Candidate release will automatically be tagged to a Stable release when a Stable release of a higher sequence is created. The Stable release they are tagged to will depend on the 'Automatic Tagging Method (Stable)' chosen.

Automatic Tagging Method (Stable) - This determines how tickets are automatically tagged to Stable releases.

  • Tag to the version being released- When selected the ticket will be tagged to the newest release in the 'Stable release note set'
  • Tag to the same version as the Beta/Candidate tag- When selected the ticket will be tagged to the same version as the Beta/Candidate release in the 'Stable release note set'.


Category for Release Notes - The category selected here will appear in the column profile when viewing the release notes against a version. This allows you to categorise software release notes/change requests further, adding this category value to the overarching view. 

Include unsent release notes from previous versions in Release emails - When disabled release emails will only be sent to the end users against release notes assigned to the release the email is being sent from. If enabled all these users, plus users against release notes in previous releases that have not been released yet, will be sent the release email (only where the product against the ticket matches). In short, this can be enabled to ensure any older releases that have not been released officially have release email sent out. 

Use Semantic Versioning - When enabled you will be able to name releases using a strict semantic format. As shown in figure 7. 

Fig 7. Name Releases using semantic versioning


Restrict the list of versions that appear in the version field if the version is not released - When enabled only versions that have been release will be available to select in the 'Version' field (this field is used to link incidents to releases). A version is classed as released when the release date has passed.

 

Advanced options 

When selecting a release, choose from any that are linked to products that are linked to the same DevOps project - When enabled, you will be able to select any releases for  the product associated with the ticket as well as any releases associated with the product linked to the ticket via a third party. When the ticket is linked to a third party entity (such as an issue in Jira), you will be able to choose from releases associated with the third party product as well as the ones for the product linked to the Halo ticket. 

Exclude the unknown version from the version list - When enabled, the 'unknown' version will not be able to be selected in the 'version' field. The version field is used to link incident tickets to releases. 


Using Software Releases

Once you have configured the above settings you are ready to create some releases. To make a new release head to the 'Software Releases' module

Fig 8. Software releases module in navigation pane


Here, you will be able to add/edit releases for your products. When adding a release to a product, you will be prompted to fill out details of the release. 

Fig 9. Release details


Release Name - Give a name (usually a version number) to the release.

Release Type - Specify the release type for this release (Not Released, Beta, Live etc..).

Product - Set the product that this release is in relation to.

Build Date - Set the date building for this release is expected to be complete. 

Release Date - Set the scheduled date for this release.

Released By - Specify the agent in charge of the release, if applicable.

Notes (Public)/(Internal) - Here you can specify any public/internal notes relevant to this release.


Now you have created and set the details of a release you can begin tagging change tickets to this release. 


Logging work for a release (tagging tickets to a release) 

Now your release has been configured, agents can use tickets in Halo to log progress and track the time spent making these changes, once complete, these change tickets can be linked to the relevant release version. Any tickets linked to a release version will be visible against this release, allowing you to easily track and monitor the changes made in a given release. 


Configuring the ticket type(s)

First, you will need to ensure the change management tab is enabled for your change request tickets, this tab contains the fields relevant to software release functionality, therefore needs to be enabled to see these fields. This is enabled under configuration > tickets > change management > 'Show the Change Management tab on the Ticket Details screen for Change Requests'

Fig 10. Enable change management tab


Now you will need to add the required software release fields to your change request ticket, or the ticket that agents (developers) will use to track progress/changes when making changes to the software. 


Figure 11 shows the fields relating to this functionality.

Fig 11. Ticket fields used for software release management 


Product - This field allows you to select the software product the change is for, the releases (versions) that the ticket can be tagged to will be restricted to releases for this product. If this field is not used or not set you will only be able to assign tickets to releases for the product with the lowest system ID.

Release, Release 2 and Release 3 - These fields allow you to tag the ticket to each release it will be on. Useful when a change will be available on different versions based on the track customers are on. For example changes are often available on different Beta to Stable versions as Beta versions of the software have higher versions released than Stable, if the change needs to be rolled out quickly to both Stable and Beta, it will need to be released on the next version for the respective track. The names these fields will have when logging the ticket will be in line with release tags you configured earlier. 

  • Release - Used for the Beta release note set
  • Release 2 - Used for the Candidate release note set
  • Release 3 - Used for the Stable release note set

Release Note - This field allows you to log notes about the change made.

Release Note group - This field allows you to assign the change to a group of release notes. This is only used for further categorisation when viewing release notes for a release. 


Note: The ticket type(s) used to track software changes must have the ITIL Type 'Change Request'. 


Once you have added these fields to the relevant ticket type(s) you can begin logging tickets to track software changes. 


Logging the ticket

Log and work on the change ticket as usual. Then navigate to the 'Change Management' tab against the ticket to associate this ticket to a software product and release. 

Fig 12. Completed software information for ticket


In the figure 12 example the ticket has been associated with the product 'HaloPSA', this means it can only be tagged to releases for this product. 


In the figure 12 example the ticket has been tagged to the release v2.192 for the Beta release and v2.190 for the stable release. This is because at the time this change has been completed v2.190 has already been released for the Beta version of the product, but it has not for the Stable version. To ensure this fix is rolled out as quickly as possible it will be released on the next release for both Stable and Beta. 


Now this change ticket is tagged to the relevant releases, it will be visible against the release itself. 


Viewing the changes made within a version

Each change ticket that has been tagged to a release will be visible under the release(s) it has been tagged to. To see all the changes made within a release head to the Software releases module, select the product and release you would like to see the changes for > Release Notes tab. 


Under the release notes tab you will see all the change tickets that have been tagged to this release. 

Fig 13. Release notes for release


From here you can easily review and monitor the changes associated with this release. You will see the status of changes, notes on the change, the release note set and release note group for the change. This allows you to:

  • Track the progress of changes. Once all tickets are closed off you know the release is ready to be published.
  • Review contents of the release, see what changes are due to come out when this release is published. 
  • Compare contents of the release, the release note group field can be used to compare how many changes are in one group vs another. For example the number of new features vs patches in a single release. 


Sending Release emails 

When a new release of your software is ready to be published you can notify all users using release emails. A release email will send an email to each end user of the change tickets tagged to this release, allowing the user that requested the change to be notified that the change is now complete and on this release version. 


The email template used for the release email is determined by the 'Release Type' and product for the release. 

Fig 14. Release type and product for release


To see/set what template will be used for this product/release type combination head to configuration > software releases > products > release emails tab. 


Figure 15 shows what template will be used for the release in figure 14. 

Fig 15. Email Template used for releases of type 'Released-Beta' for the HaloPSA product


To send the release email for a release navigate to this release in the Software Releases module and use the button 'Send Release Email'.

Fig 16. Send release email


When used you will see a preview of the email before it is sent, allowing you to make any changes to the template/email prior to sending. 


Once happy with the email template you can send it off, this will que the emails to be sent. Keep in mind an email will be sent to each end user of the change tickets linked to this release, if this is a considerable number of users it is advised to send release emails out of hours to avoid impact to day-to-day email processing. 


Note: Release emails can be re-sent any number of times, using the same button. After sending the button name will update to 'Re-send Release Email'. 


Tracking Release Issues and Statistics

Once a release is published you can use Halo to track any issues raised related to this release and monitor issue statistics. 


When a user raises an incident ticket, the ticket can be tagged to this release, in the same way change requests are tagged to releases. When tagged the incident ticket will be visible under the 'Issues logged' tab against the release. 

Fig 17. Issues logged for a release


To link an incident ticket to a release you will need to add the fields 'Product' and 'Version' to your incident ticket type(s).

Fig 18. Product and version fields


Now, once the ticket is logged you can choose which product and version (release) the incident ticket relates to, usually the release that contains changes that caused this incident. 

Fig 19. Product and version the incident is linked to


Note: The versions available to select will be restricted based on the product selected. 


To see the total number of issues logged, and issues currently open for this release head to the 'Details' tab of the release > 'Statistics' section. 

Fig 20. Total issues logged and issues currently open for release


This allows you to easily monitor the number of issues with a given release, helping you to plan timeframes for future sprints. For example, if previous releases have lots of issues currently open, you know to more time needs to be dedicated to resolving these issues before making new features. 

Popular Guides

Pin It on Pinterest