01 / 12 Cover
Zentra
Release strategy deck AME by Zentra
AME by Zentra / tracked release model

Safer production changes.
Cleaner cutover.
Rollback-ready releases.

A professional release strategy for AME by Zentra built from the supplied plan, workflow, safety, and Bitbucket governance notes — styled in a dark Zentra presentation format.

Reviewed Versioned Validated Named release Rollback-ready
Primary branches
stg-250226 staging integration
fix/production-2026 production release

Atomic switch. New releases activate cleanly instead of live in-place updates. Fast rollback. Previous release activation stays available if the new release is bad.

1 exact commit atomic cutover fast rollback
Zentra
Release strategy deck
AME by Zentra / tracked release model

Safer production changes.
Cleaner cutover.
Rollback-ready releases.

A professional release strategy for AME by Zentra built from the supplied plan, workflow, safety, and Bitbucket governance notes.

reviewed versioned validated named release rollback-ready
Primary branches
stg-250226 staging integration
fix/production-2026 production release

Goal: move from branch-based deploys to a tracked release model with atomic cutover and fast rollback.

01Zentra / AME by Zentra release strategy
Executive summary

Why change the release model?

The supplied strategy recommends replacing direct branch-based deploys with tracked, named releases so every production change is clearer, safer, and easier to reverse.

01

Cleaner production

Production stops behaving like a mutable working tree. The live system becomes a deliberate activated release instead of a branch state.

02

Faster recovery

Rollback becomes an operational switch back to the previous release rather than manual shell work on the live server.

03

Better audit trail

Each release records the version, commit, branch, deploy time, hooks, migrations, and checkpoint references.

Every production change becomes:
reviewed versioned validated deployed as a named release rollback-ready
02Executive summary
The problem we are solving

Direct deploys create avoidable risk.

The current pattern mixes code, cache, workers, and migrations directly in the live path. That makes it harder to know what is actually live and slower to recover when something goes wrong.

What happens now
  • production can drift away from staging
  • it is hard to know exactly what is live
  • rollback is slower and more manual
  • urgent fixes can become permanent hidden differences
  • deploys mix code, cache, workers, and migrations in the live path
Why that matters
  • incident response depends too much on memory and shell access
  • hotfixes can fix the moment but damage long-term traceability
  • operators have to infer deploy behaviour from commit history or habit
  • business stakeholders cannot get a clean answer to what changed and when
The deployed unit should be a tracked release, not an untracked branch state.
03The problem
The proposed model

Promote intentionally. Build once. Activate cleanly.

The supplied branch model keeps feature work moving into staging first, then promotes only intentional, production-ready commits into the release branch.

stg-250226

Integration branch for staging validation.

fix/production-2026

Production release branch for releases and controlled hotfixes.

Zentra patch path Release sequence
1

Feature work

Developers shape the patch on feature branches before anything touches the release path.

build test
2

PR to staging

Reviewed work lands in stg-250226 so the integrated patch can be seen as one story.

review approvals
3

Staging validation

CI, QA, and staging checks confirm the exact candidate before promotion.

CI smoke
4

Promote exact commit

The approved commit is promoted into fix/production-2026 with no ambiguity about what ships.

promotion traceable
5

Build release

The pipeline assembles one immutable release package and prepares the exact deployable unit.

package manifest
6

Validate release path

Hooks, caches, and readiness checks run away from the live tree before activation.

hooks checks
7

Activate or rollback

Production switches to the new release cleanly, with the previous release still ready if needed.

cutover rollback

Plain English: the release path is shown as a compact sequence: feature work enters staging, the exact commit is promoted, then one release is built, checked, and activated.

Continue into the release package Jump forward to see what the built release actually contains.
open release
04The proposed model
What a release is

One immutable deployment package for one exact commit.

A release is not “whatever is currently on the branch”. It is a built package with metadata, hooks, and a known rollback point.

Release path example
/data/releases/propertyfeedtemplate/2026.03.7+abc1234/
version build commit branch
  • exact code for that commit
  • installed dependencies
  • built caches / artefacts
  • release metadata
  • deploy hook record
Release manifest
{
  "version": "2026.03.7",
  "build": "2026.03.7+abc1234",
  "commit": "abc1234",
  "branch": "fix/production-2026",
  "requires_migration": true,
  "hooks": [
    "php artisan migrate --force",
    "php artisan localization:property-types-prewarm"
  ]
}
Deploy hooks remove guesswork
composer install migrations cache rebuild queue restart localisation prewarms
05What a release is
Atomic cutover and rollback

Switch the pointer. Don’t patch the live tree.

Production should point to a symlink. When a release is ready, deployment changes the pointer from the old release to the new one. If the release is bad, switch back.

Previous release
2026.03.6+ab912d
/data/propertyfeedtemplate_current
New release
2026.03.7+abc1234
Normal rollback
  • switch symlink to previous release
  • rebuild or clear caches if required
  • restart workers
Database rollback
  • only if a migration requires it
  • driven by a checkpoint / restore plan
  • restore the database only if necessary
Rollback should be boring.
06Atomic cutover and rollback
Developer workflow

Daily development, hotfixes, and releases each have a clean path.

The goal is simple: every change should be reviewable, every deploy reproducible, and every release rollback-ready.

Day-to-day development
  1. Create a feature branch
  2. Build and test the change
  3. Open a PR into stg-250226
  4. Get review and approvals
  5. Let CI and staging validate
  6. Promote when ready as part of a release
Hotfix workflow
  1. Start from fix/production-2026
  2. Keep the change as small as possible
  3. Validate with CI
  4. Deploy through the release pipeline
  5. Back-merge the same fix into staging
Release workflow
  1. Choose the exact commit to release
  2. Assign a release version
  3. Build the release
  4. Run validation in the release path
  5. Run declared hooks
  6. Atomically activate the release
Safe working rules
no dirty worktree deploys no skipped review for production changes no prod-only changes left unmerged server is not the source of truth
07Developer workflow
Pipeline safety and security

Production should not be a place where code is edited directly.

The pipeline model is safer because it separates preparing a release, validating a release, and activating a release.

1

Branch restrictions

Block direct pushes, force pushes, deletes, and unreviewed merges.

2

Merge checks

Require approvals, green pipeline, and no unresolved tasks.

3

Deployment restrictions

Only approved branches deploy to each environment.

4

Immutable releases

Each release is built in its own directory and never edited after activation.

5

Database checkpoints

Create a checkpoint or dump before production cutover.

6

Validation

Run lint, dependencies, migration readiness, cache rebuild, and smoke checks.

7

Health checks

Confirm key routes, workers, and logs are healthy after activation.

8

Rollback

Switch back quickly and restore DB only if necessary.

Why this is safer than pulling directly on prod: direct server pulls mix code changes, cache changes, migrations, worker restarts, and environment assumptions inside the live application path.

08Pipeline safety and security
Bitbucket enforcement plan

Lock the release flow into the platform.

The intention is to enforce the release model with Bitbucket rules, deployment restrictions, and merge checks — not by relying on people to remember the right steps.

stg-250226

Use for integration and staging validation.

  • PR-only merge
  • minimum approvals
  • no direct push for normal developers
  • no force push
  • no delete
  • green pipeline required
fix/production-2026

Use for production releases and controlled hotfixes.

  • PR-only merge
  • stricter approvals than staging
  • direct push only for a very small release-admin group
  • no force push
  • no delete
  • green pipeline required
  • no unresolved review tasks
Deployment environment rules
  • staging deploys only from stg-250226
  • production deploys only from fix/production-2026
  • production triggers restricted to release managers / CI
Merge checks
  • minimum approvals
  • successful pipeline required
  • no unresolved tasks
  • optional block self-approval
Practical summary
  • staging receives reviewed integration changes
  • production receives reviewed release changes
  • pipeline is the deploy authority, not a manual server pull
09Bitbucket enforcement
Governance and auditability

Make releases repeatable, explainable, and easy to rebuild.

Release governance is strongest when settings are managed and every production change leaves a record that can be reviewed later.

Production release should only happen when
  • PR merged successfully
  • release manifest exists
  • required deploy hooks are declared
  • pipeline validation passes
Every release should record
  • release version
  • commit hash
  • branch
  • deploy time
  • commands run
  • migrations run
  • checkpoint reference
API-driven management
  • branch restrictions
  • default reviewers
  • merge checks where API allows
  • deployment branch rules where supported
BITBUCKET_USERNAME
BITBUCKET_APP_PASSWORD
PRODUCTION_BRANCH=fix/production-2026
STG_BACKMERGE_TARGET_BRANCH=stg-250226
production deploy SSH secrets
staging deploy SSH secrets

Why manage settings through API-backed scripts? Repeatability, auditability, and easier rebuild if repo settings are lost.

10Governance and auditability
Benefits and end state

Why this model is better over the long term.

The release model improves day-to-day operations, makes incidents easier to understand, and reduces dependence on one person remembering special deploy steps.

Operational benefits
  • safer production deploys
  • faster rollback
  • less branch drift
  • less production shell surgery
  • more confidence in production changes
Management benefits
  • better accountability
  • easier incident review
  • better auditability
  • less dependence on memory and tribal knowledge
Engineering benefits
  • reproducible deploys
  • explicit post-deploy commands
  • cleaner staging-to-production promotion
  • fewer 'works on staging but not on prod' surprises
Corporate-style end state
protected branches immutable tracked releases deployment environments restricted by branch PR approvals + CI required rollback by previous release activation
11Benefits and end state
Plain-English explanation

Think of staging as the test track and production as the showroom.

Instead of changing the live car while customers are looking at it, we prepare a complete new version in the garage, test it, then swap it in cleanly. If the new car has a problem, the previous one goes straight back on display.

Recommended policy
  • no direct production edits as the normal path
  • no production deploys from dirty working trees
  • no production merge without approvals and green checks
  • every release tracked, named, and reversible
  • every production hotfix back-merged into staging
Outcome

This strategy gives AME by Zentra a corporate-grade release process that is safer, cleaner, and easier to operate long term.

safer deploys clean rollback clear history
Zentra AME by Zentra / release strategy deck
12Outcome