Skip to main content

Releases

Releases allow you to group feature flag changes into a single deployable unit, track them through your CI/CD pipeline, and roll them back instantly if issues arise.

What is a Release?​

A Release in Toggly is a container for:

  • Feature Changes: A set of feature flag states (enabled/disabled, rules) that you want to apply.
  • CI/CD Builds: Links to your GitHub Actions, Azure DevOps, or other CI builds.
  • Release Notes: Information about what's changing.
  • Deployment Status: Tracking where this release is deployed (e.g., Development, Staging, Production).
  • Gates: Automated checks (like error rates or performance metrics) that must pass before the release is considered successful.

Why use Releases?​

While you can toggle individual feature flags manually, Releases offer several advantages for your deployment workflow:

  1. Atomic Deployments: Update multiple feature flags at once. This ensures that dependent features are enabled simultaneously.
  2. Audit Trail: Track exactly which build version maps to which set of feature flags.
  3. Safety: Automatically rollback all feature changes in a release if something goes wrong.
  4. Collaboration: Share release notes and status with the team.

Creating a Release​

You can create a release in two ways:

1. Manual Creation​

  1. Navigate to Releases in the Toggly dashboard.
  2. Click Create Release.
  3. Enter a Name and optional Release Notes.
  4. Select the Environment you are targeting initially.
  5. Add Feature Changes: Select which flags you want to modify and set their desired state.
  6. Click Create.

2. Automated Creation via CI/CD​

Most teams automate release creation as part of their build pipeline. When your CI system builds your application:

  1. It calls the Toggly API to "associate a build".
  2. Toggly creates a new Draft release (or updates an existing one) with the build details (commit SHA, branch, etc.).
  3. You can then manage the feature flags for that release in the dashboard before deploying.

Learn more about CI/CD Integration

Deployment Workflow​

A typical release workflow looks like this:

1. Draft​

The release is created but not yet active. You define which feature flags should change. For example, you might decide that new-checkout-flow should be Enabled and legacy-checkout should be Disabled.

2. Deploy (Activate)​

When you are ready, you Activate the release to a specific environment (e.g., Staging).

  • Toggly applies all the defined feature flag changes instantly.
  • The release status changes to Live.
  • Toggly captures a snapshot of the previous state of those flags (FromState) to enable rollback.

3. Monitor & Gates​

If you have configured Gates, Toggly monitors them.

  • If gates pass, the release is considered healthy.
  • If gates fail, you can configure auto-rollback or manual intervention.

4. Rollback​

If a critical issue is discovered, you can Rollback the release.

  • Toggly immediately reverts all feature flags in the release to their state before the release was activated.
  • The release status changes to RolledBack.

Feature Flag Conflicts​

If multiple releases modify the same feature flag, Toggly handles this by tracking the sequence of changes.

  • If you rollback an older release, Toggly attempts to restore the state at that time, but warns you if the flag has been modified by a newer release in the meantime.

Next Steps​