Release manager
Engineering lead
QA manager
Product manager
Operations director
DevOps lead
This process is used when a product, software build, or service update is ready for deployment and requires formal authorization before it is released to production or made available to customers. It is triggered when development or testing milestones are completed, when a scheduled release window approaches, or when an emergency fix requires expedited deployment. Release approval is critical when the release affects production systems, customer-facing services, or regulated environments, and when multiple teams must confirm readiness before the release can proceed. It is common in technology, software, manufacturing, financial services, healthcare, and telecommunications.
The engineering or development team submits the release candidate with build documentation and change details. Quality assurance confirms that testing criteria have been met and outstanding defects are within acceptable limits. Operations or infrastructure teams verify that deployment prerequisites and rollback plans are in place. Product management confirms that the release aligns with product strategy and customer commitments. The release manager coordinates the process and facilitates the go/no-go decision. For high-risk releases, executive or change advisory board approval may be required.
Confident go/no-go decisions because every release is evaluated against defined readiness criteria by the teams responsible for quality, operations, and product alignment. Reduced production incidents through structured pre-release checks that catch deployment risks, unresolved defects, and infrastructure gaps before they reach customers. Faster release cadence by streamlining the approval process so that low-risk releases are authorized quickly while high-risk deployments receive appropriate scrutiny. Clear release accountability with documented sign-off from every required function, eliminating ambiguity about who authorized the release and under what conditions. Improved rollback readiness because operational contingency plans are reviewed and confirmed as part of the approval process, not as an afterthought.
Your version of this process may vary based on roles, systems, data, and approval paths. Moxo’s flow builder can be configured with AI agents, conditional branching, dynamic data references, and sophisticated logic to match how your organization runs this workflow. The steps below illustrate one example.
Release candidate submission and documentation
The process begins when the engineering team submits a release candidate for approval. The submission includes build version details, change logs, feature descriptions, known issues, test results, and deployment instructions. An AI agent can assist by pulling build metadata from connected CI/CD systems, compiling test result summaries, and flagging any open defects or incomplete test cases that may affect the release decision.
Quality assurance review
The QA team reviews the release candidate against testing criteria, including test coverage, pass rates, regression results, and severity of any outstanding defects. If all testing criteria are met and defects are within acceptable limits, QA signs off on the release. If critical defects remain or testing is incomplete, the release is held for remediation. The QA assessment may also include performance testing, security scanning, and compatibility verification depending on the release type.
Operational readiness and deployment review
Operations or infrastructure teams verify that the deployment environment is prepared, that deployment scripts and configurations are validated, and that rollback procedures are documented and tested. This includes confirming monitoring and alerting are in place for post-deployment observation. If operational prerequisites are not met—for example, infrastructure changes are pending or a maintenance window is not confirmed—the release is held until readiness is confirmed.
Product and stakeholder alignment
Product management confirms that the release content aligns with the product roadmap, customer commitments, and any communication or enablement requirements. If the release includes customer-facing changes, marketing, support, or customer success teams may be engaged to confirm documentation and communication readiness. If stakeholder concerns are raised, the process accommodates resolution before proceeding to the final decision.
Go/no-go decision and release execution
The release manager facilitates the final go/no-go decision based on the accumulated assessments from QA, operations, and product management. If all criteria are met, the release is authorized and deployment proceeds according to the approved plan. If the decision is no-go, the specific blockers are documented and assigned for resolution, and a revised release timeline is established. The complete release record—including all assessments, sign-offs, and the go/no-go decision—is retained for governance and post-release review.
This process commonly relies on inputs such as build artifacts, test results, change logs, deployment plans, rollback procedures, and stakeholder readiness confirmations. It may be triggered by a CI/CD pipeline event, a scheduled release window, or a manual submission from the engineering team. Connected systems such as Jira, GitHub, GitLab, Jenkins, or Azure DevOps provide build and testing data, while monitoring and infrastructure tools supply operational readiness information.
Key decision points include whether testing criteria have been fully met, whether any outstanding defects are severe enough to block the release, whether the deployment environment and rollback procedures are confirmed ready, whether stakeholder communication and enablement are prepared, and whether the overall risk profile supports a go decision. If any function withholds sign-off, the release is held until the specific concern is addressed.
Releases approved with incomplete test coverage, leading to production defects that could have been caught pre-deployment. Rollback procedures not validated before release, leaving the team without a reliable recovery path if the deployment fails. Operational readiness assumed rather than confirmed, resulting in deployment failures due to infrastructure or configuration gaps. Stakeholder communication not coordinated with the release, causing customer confusion or support team unpreparedness. Go/no-go decisions made without all required sign-offs, creating accountability gaps when production issues arise post-release.
Orchestrates release reviews across engineering, QA, operations, product, and stakeholder teams so that every function provides its assessment before a go/no-go decision is made.
AI agents assist with release readiness checks by compiling test results, flagging open defects, and pulling build metadata from connected CI/CD systems to ensure the release candidate is fully documented.
Routes releases to the appropriate approval authority based on risk level, release type, and organizational change management policies, ensuring routine releases move quickly while high-risk deployments receive change advisory board review.
Connects to development, testing, and deployment systems such as Jira, GitHub, Jenkins, or Azure DevOps to pull release data directly into the approval process, extending existing DevOps infrastructure.
Maintains a complete record of every assessment, sign-off, and go/no-go decision for each release, supporting post-release review, incident investigation, and continuous improvement of the release process.
