Blog

Versioning your sGTM container: a workflow that holds

Named versions, an approval step, and a rollback procedure that everyone knows.

sGTM containers support named versions out of the box, but most teams treat them as save points rather than as a deployment workflow. A few habits transform "we publish whenever" into a controlled release process that scales.

Habit 1: name every version

When publishing, fill in the name and description fields. Format: [YYYY-MM-DD] [Author] [Change summary]. For example: "2026-04-26 hamid: added Snapchat CAPI tag." Three months later this is what you read to understand what shipped and when.

Habit 2: separate workspaces by author

Each contributor works in their own workspace, not the default. Workspaces are cheap and the isolation prevents two people from publishing conflicting changes. The merging is automatic on publish.

Habit 3: an approval step

For containers with more than two contributors, add an approval requirement: changes are submitted to the workspace, reviewed by a second person, then published by the original author. Most teams enforce this through process rather than tooling, but the GTM permission model lets you split Edit from Publish if you want hard enforcement.

Habit 4: publish during low-traffic windows

Schedule publishes for low-traffic times. A separate post covers the timing in detail. The short version: avoid Friday afternoons and Monday mornings.

Habit 5: a documented rollback procedure

When something breaks, the rollback should be one click and known to everyone. The procedure: open Versions, find the previous good version (named, ideally), click "Publish this version." The change propagates within seconds.

If your team has more than three people who might need to rollback, write the procedure down somewhere. The document does not need to be long. A two-line README in your team's wiki is enough.

Habit 6: review the version log monthly

Once a month, scan the version history. Look for: versions named "Update" or "Untitled" (improve the naming), authors who do not write descriptions (coach them), gaps in time when work obviously happened but no version captures it (someone is editing without publishing).

Combined with the quarterly tag audit, this keeps your container in shape without requiring a dedicated maintenance role.