Releasing

This section describes how your project - a site built from Vortex - releases to production. (How the Vortex template itself is released is a different process, documented in Contributing > Maintenance > Release.)

A release process has a few moving parts, and Vortex provides defaults and integration points for each of them:

1. Release flow - the sequence of environments code goes through from development to production
2. Versioning workflow - the branching strategy, documented in GitFlow
3. Version scheme - the numbering system, chosen at install time and documented in Versioning
4. Release documentation - your project's own docs/releasing.md
5. Automated deployment - the CI pipeline and hosting integrations that do the technical work

Release flow

Projects typically follow a 3-tier environment strategy. Code moves "up" through the environments while the database moves "down":

  code:     Development ───► Stage ───► Production
  database: Development ◄─── Stage ◄─── Production

• Development - latest development code, not yet released. May be unstable, but CI tests should pass.
• Stage - pre-production environment. Mirrors production as closely as possible. Used for final release testing.
• Production - the live customer-facing application. Stable and reliable. Source of truth for data.

The production database is the primary source of truth - it is what code is applied to. When performing a release, you are applying a new version of code to a database within a specific environment. To make sure code changes work with real data, lower environments test against a copy of the production database:

1. The database is copied from a higher environment to a lower one (e.g., production → stage → development).
2. Code is deployed to that environment.
3. Testing confirms everything works against the copied database.

tip

CI pipelines use a copy of the production database (refreshed daily) to run all tests, so code changes are validated against real data structures too.

Environment agreement

The specific environment setup (dev/stage/production) should be agreed within your team and documented in your project. Some teams use additional environments (e.g., UAT, pre-prod) or different naming conventions.

Production deployment process

Once code is finalized and pushed, deployment to production is technically identical to deploying to any other environment and is fully automated.

For Acquia and Lagoon hosting, Vortex integrates directly with their deployment systems. For other hosting providers, you can integrate the provision steps into your hosting deployment configuration if it supports post-deployment hooks or custom scripts.

➡️ See Development > Provision to learn what provisioning steps run during deployments.

Documentation

docs/releasing.md

Your project includes a docs/releasing.md file that serves as the canonical release documentation for your team. As shipped, it records the expected release outcome and your project's version scheme, and leaves a marked section for project-specific configuration.

Extend it with:

• Detailed release procedures - an outline of what actions to take during releases: creating and finishing releases, deploying to production, rolling back, verifying.
• A release run template - a checklist of who does what and when during a release, cloned into a separate runsheet for each release.

Monitoring

New Relic integration

Vortex integrates with New Relic for release tracking: when configured, it creates deployment markers as releases reach your environments, so performance changes and errors can be correlated with specific releases.

➡️ See Deployment > Notifications

See also

Topic	Description
GitFlow	Branch structure and release operations
Versioning	CalVer, SemVer, and custom version schemes