TDX Release Management: Working with Release

This article provides guidance to TeamDynamix (TDX) Agents on  various Release management activities, including when to use a Release, what is should contain, relating to changes, and  Release best practices.
 

In This Article:

 

Quick Decision Guide

Should I use a Release?

  • One isolated Change? → Use a Change.
  • Multiple related High Impact Changes implemented together? → Use a Release.
  • Supporting activity that does not require its own Change? → Use a Task.
  • Large, complex effort requiring extensive project planning? → Consider a PPM Project in addition to Release/Change management.

Best Practices

  • Use Releases to coordinate related Changes - not simply because a Change is important.
  • Keep the Release focused on the overall implementation.
  • Keep technical implementation details in the appropriate Change.
  • Link related tickets instead of duplicating information.
  • Use tasks and task templates for repeatable supporting activities.
  • Plan communication before implementation begins.
  • Always document a contingency or rollback approach for significant Releases.
  • Close the Release only after the implementation has been validated.
     

Overview

Release Management in TeamDynamix helps teams coordinate multiple related changes that are being implemented together.

A Release provides an overall view of an implementation, while individual Change tickets document the specific changes required to complete it.

A simple way to think about it is:

Release = the coordinated implementation
Change = an individual modification
Task = supporting work needed to complete the implementation

 

When Should I Use a Release?

Create or use a Release when multiple related changes need to be coordinated as one implementation.

Examples include:

  • Major application upgrades
  • Enterprise system deployments
  • Infrastructure upgrades involving multiple teams
  • Coordinated integration changes
  • Semester-start technology deployments
  • Large security or identity implementations
  • Other deployments involving multiple related Changes

You generally do not need a Release for a routine or isolated Change that can be planned, approved, implemented, and validated independently.

 

What Should a Release Contain?

A Release should provide enough information for someone to understand the overall implementation without reviewing every individual Change.

Include:

  • A clear Release title
  • Purpose and business justification
  • Systems or services affected
  • Implementation date and maintenance window
  • Release owner
  • Teams and stakeholders involved
  • Related Change tickets
  • Dependencies
  • Testing and validation plan
  • Communication plan
  • Rollback or contingency plan

Use a meaningful title

Use a title that identifies the system and implementation.


Good: ConnectCarolina CS - Fall 2026 Upgrade

Avoid: System Update, October Changes, University Wide Upgrade

Clear titles make Releases easier to find and report on later.

Relating Changes to a Release

Individual Changes should be associated with the appropriate Release using TeamDynamix's parent/child ticket functionality.

For example:

Release:
ConnectCarolina CS - Fall 2026 Upgrade

Related Changes:

  • Database upgrade
  • Application deployment
  • SSO Authentication update
  • Integration deployment
  • Reporting update

The Release should describe the overall implementation. The individual Changes should contain the technical implementation details for each modification.

Avoid copying the same information into every ticket.

Use Tasks for Supporting Work

Use ticket tasks for activities that support the Release but do not require their own Change record.

Examples:

  • Confirm backups
  • Notify stakeholders
  • Confirm vendor availability
  • Perform testing
  • Validate integrations
  • Notify the Service Desk
  • Complete post-implementation checks

For recurring Releases, task templates may be available to provide a standard checklist.

Plan the Implementation

Before implementation begins, confirm:

  • All required Changes have been identified.
  • Required approvals are complete.
  • The implementation window is appropriate.
  • Dependencies have been identified.
  • Required staff and vendors are available.
  • Testing and validation criteria are defined.
  • Communications are prepared.
  • Rollback or contingency procedures are understood.

When scheduling Enterprise Releases, consider academic and operational calendars such as registration, examinations, financial aid deadlines, payroll, move-in, and other periods of high institutional activity.

 

Communicate

Communication should be part of the Release plan.

Before implementation, communicate:

  • What is changing
  • Why it is changing
  • When it will occur
  • Who is affected
  • Expected service impact
  • Where users can get assistance

During implementation, provide updates when there are significant delays, unexpected issues, or changes to the approved plan.

After implementation, communicate completion and any known issues or required user actions.

Validate and Close

A Release is not complete simply because the technical deployment finished.

Before closing the Release:

  • Confirm implementation is complete.
  • Complete technical validation.
  • Complete business validation when appropriate.
  • Confirm related Changes and required tasks are complete.
  • Document outstanding issues.
  • Send required completion communications.
  • Update relevant documentation.
  • Record lessons learned for significant or unsuccessful Releases.

 

Print Article