Skip to main content

Release Management

How do we handle new releases?

Y
Written by Yannick De Coster
Updated over 6 months ago

Versions

Our version naming is structured MAJOR.MINOR.PATCH

Examples:

202406.1.0

202407.12.33

Definitions:

MAJOR contains new or changed functionality.

MINOR contains a bug fix which requires downtime to deploy.

PATCH contains a bug fix that can be deployed without downtime.

Deployments

MINOR and PATCH releases

We ensure issues can be resolved in the fastest possible way with a minimal impact to the users by releasing regularly to all environments (both staging and production) without prior announcement or confirmation after.

PATCH can be deployed at any time during the day. Currently (time of writing Q4 2024) this happens once per day at 18:00 UTC, if fixes are available.

MINOR deployed daily - if fixes are available - at a time of low activity: between midnight UTC and 03:30 UTC.

MAJOR releases

The release process is the following:

  1. Transporeon Transport Operations team builds to schedule, not to scope. We plan for a 2 month development cycle for feature releases (ie. MAJOR), this may slightly differ based on test results.

  2. The release is made available on the customer's staging environment, this is an automated process which follows the 2 month development cycle.

  3. All customers are informed via email. The email will contain:

    1. Notification of the update including the version number.

    2. A link to the release notes.

    3. The planned date for release to production. Background on the production release planning:

      1. The date is non-negotiable. Deploys are batched and cannot be customer specific.

      2. The date will typically provide the customer with 2-4 weeks of time for optional testing.

      3. The date may be moved back at Transporeon's discretion, but will not be pulled forward.

  4. Optional customer validation is done.

  5. If there are no open blocker tickets or planning changes (which are informed through an email update), then the release to production will happen on the scheduled date.

Post deployment

  1. Transporeon QA performs a sanity check immediately following the deploy.

  2. Logs are (as always) actively monitored, detected issues are proactively investigated and resolved.

  3. The development team is on extended availability the day immediately following a new release, this allows for a faster time to resolution.

Notes

  1. Rollbacks are not possible.

  2. Bugs resolution targets as per our SLA.

  3. The product design may be updated slightly on each release. This happens entirely at Transporeon's discretion.

  4. New functionality is generally added through an opt-in process. This keeps customer's setups as similar as possible across multiple versions.

  5. Bugs in newly added functionality can never be considered a blocker for release to production.

  6. If a new release would be non compatible from a API perspective, deviations may occur from above described process. This should be extremely rare.

Questions or issues (both on staging and production) should always be logged through the support desk.

Did this answer your question?