Who is this article for?

Advanced Administrators and Module Developers seeking access to Module Builder

Reporting authorities, roles, and record access controls restrict data visibility.

The Software Quality Assurance (SQA) process ensures that scheduled testing and validation before conducted prior to a move to production. Using scheduled releases provides many benefits, including:

• Increased quality
• Clearer customer involvement and input into ticket prioritization
• Visibility, for all parties, of when tickets are scheduled for work
• Reduced likelihood of unfinished tickets being promoted to production
• Simplified change management
• Improved work planning

While break-fix or emergency changes can still be made as needed, as a rule tickets are managed as a release. 

What is a release?

A release is a group of tickets involving one or more modules. Ideagen works with customers to determine which tickets are in a release.

Preparing for established releases requires a commitment from both Ideagen and the customer to plan for, schedule, test, and promote them. Releases typically follow a bimonthly cadence, with the specific dates mutually agreed to by Ideagen and the customer.

A release object is managed in TrakWay and consists of the following main fields. Other optional fields can also be populated.

Only Ideagen employees can create releases, but customer admins can assign and modify which release is associated with a ticket.

Once a release has been created, TrakWay tickets can be associated with it by selecting it from the Release field.

Do not re-use releases
Release objects cannot be modified and re-used for subsequent releases. It is important that the release details be retained so that tickets accurately depict their associated release, even after closing.

Emergency changes

There are occasions when it is necessary to modify a module before a planned release date. These mid-cycle exceptions are handled in one of four ways, listed in order of preference:

1. Evaluating whether there is an acceptable workaround until after the planned release date.

2. Manually applying the necessary module changes directly in each area – Build, Test, UAT, and Production – without promoting the entire module.

   Manual updates 
   This option may not be possible, depending on the complexity of the change.

3. Removing from the release all tickets that have not been started and completing those tickets that have been started before working on the change prompting the mid-cycle exception.
4. Removing from the release all tickets that have not been started and backing out the changes for tickets that have been started to ensure the functionality of the module isn’t affected before working on the change prompting the mid-cycle exception.
   This option will triple the required hours and support requests for the backed-out changes as they must be removed and then re-added later.

Non-release tickets

Not all tickets must be in a release. Tickets related to platform changes, interfaces, custom (SSRS) reports, and data need not be associated with a release, unless there are accompanying module changes.

Release process

Define releases and cadence

Customer admins and the Technical Account Manager (TAM) work together to establish the:

• Required module/application releases
• Cadence for releases*

• Specific dates for release

  • Review the Platform release schedule to ensure your planned release doesn't conflict with a planned platform release

  *The default release cadence is bi-monthly (every other month)

Create releases

Release objects should be created for all modules/applications for which there are open TrakWay tickets. Three upcoming releases should be planned, per module/application. The following are examples:

Additional future releases may be created, based on TAM and customer admin planning.

Adding tickets to a release

During account meetings, or as needed, the TAM and customer admins evaluate all tickets in Pending Work and determine which tickets should be included in which release. The number of tickets that can be included in the current or next release is determined by the total estimated number of hours required. Note that some tickets, such as platform or operations tickets, are not associated with customer releases.

Managing a release

Technical Account Managers (TAM) are responsible for managing a release in coordination with customer administrators:

• Reviewing incoming tickets and setting the disposition.
• Determining if any tickets need to be managed as emergency tickets.
• Producing the Release Plan and entering it in the release object.
  • Date and time of release and all related milestones, accounting for resource (Ideagen and customer) availability, design, configuration, testing, and promotion
  • Area(s) from which the modules will be exported
  • List of modules to be promoted
  • Additional activities that may be required, e.g., items to run through dirty objects, or be fed through the search engine, data that needs to be imported, etc.
  • Testing plan
  • Communications plan
• Adjusting tickets, if needed, after consulting with customer admins.
• Monitoring which tickets are included in each release.
• Creating ticket Tags when appropriate
• Driving the progress, resolution, and internal Ideagen testing of all release tickets, ensuring they are completed on time and are advanced to Customer Verification by the milestone date.
• Ensuring that no work for non-release tickets commences for this module/application.
• Promoting the modules to production.
• Advancing all release tickets from Pending Release to Production Validation.

Customer admins are responsible for:

• Ensuring the requirements of each ticket are clear and thorough and that all release tickets are advanced to Pending Work by the milestone date.
• Using ticket Tags when appropriate
• Writing test scripts that describe a user's behavior and the expected results. Writing test scripts will help to validate that requirements are thorough.
• Ensuring thorough UAT testing is completed, following the test scripts, in a timely manner and that tickets are advanced from Customer Verification to Pending Release at least five days before the release. Once a ticket has advanced to Customer Verification it must be included in the release.
• Planning and communicating the pending changes within their organization, if needed.
• Validating that the changes are working properly in production, following a release.
• Advancing all release tickets from Production Validation to Close.

Release activities and schedule

Adhering to the following schedule and milestones increases the likelihood of a successful release.

• Ensuring that all tickets are in the appropriate workflow task by the required milestone date. If a milestone is not met, then subsequent milestones will need to be delayed.
• Release planning must account for holidays and planned vacations for both Ideagen employees and customer administrators.
• Allow for a period of two weeks to a month between when a release finishes and the next one begins. This period can be used for incident resolution or other high-priority tickets.

Here is an example schedule for a two-month release cycle. Other release frequencies will follow a similar schedule.

Release and backlog communication

Reports can be created to clearly identify tickets that are included in the release, allowing all parties to see when specific tickets will move to Production. In addition to the Release field shown in the report below, admins can also add fields for Application and/or Identifier. Dates can be added to Release names, if desired.

Display workflow tasks in sequential order
By default, values in crosstab reports are ordered alphabetically. However, using a calculated field you can display them in any order you choose.

The calculated field, Task Order, used in the report above contains this formula:

Case("Workflow Task", 'Initiate', '01-Initiate', 'Screen', '02-Screen', 'DevonWay Review', '03-DevonWay Review', 'Customer Review', '04-Customer Review', 'Pending Work', '05-Pending Work', 'Working', '06-Working', 'Customer Verification', '07-Customer Verification', 'Pending Release', '08-Pending Release', 'Production Validation', '09-Production Validation', 'Pending Close', '10-Pending Close', 'Close', '11-Close')

Customer admins can share these reports with interested parties within their organization, prompting any needed discussions about priorities and schedules.

A calendar view report can also be created and shared.