Getting your product into the beta and production environment.
The goal of any project is to deploy each build into a live environment and ensure that all stakeholders are happy with the outcome.
There are often three environments to consider: Development, Beta and Production. These separate environments are required to ensure quality control gates are in place. The specific purpose for each environment is as follows:
- The development environment is used to locally develop the application, it is a closed environment for internal use only and is where development of the application occurs.
- The beta environment is the first live, cloud-based environment in most workflows. It is traditionally the sum of all issues completed, that have passed the Definition of Done and is openly available for the Product Owner and other relevant stakeholders to use.
- The production environment is the final stage of deployment where only tickets that have passed UAT are deployed to. Nothing should make it to this environment without first being reviewed in the previous environments and stepping through quality control processes.
As part of the development lifecycle, an application moves from the development environment, into beta, then eventually into production. In order to progress into the next environment, the application needs to meet certain criteria before it can be approved for release. Checklists for these gates are recommended to ensure that each release lives up to the standard of that environment.
The beta release checklist is completed before moving tickets to the beta environment. While most of the criteria involves routine security and quality checks, one important artefact that should be required is a Testing Report. A Testing Report traditionally shows the current state of the tests run against the application, which are expected to all be passing before the release can continue.
The production release checklist is prepared when the product on beta is ready to be released to production. Before the application can be released into the production environment, teams must have received express approval from the Product Owner.
Completing a development build traditionally marks the transition into a support phase for any project. This is a long-term shift that looks to focus on supporting and improving an application operationally. Managing this transition generally entails a shift in team and a handover to manage that change.
Beyond moving a project into support, there is also the opportunity to look at the next problem statement, scope and development build. It’s ideal for newly finished projects on their MVP to leave time to allow initial users to provide feedback, which will shape the next phase of the project. However, for long standing applications with large wish lists, starting the next scoping effort should continue to improve your product while it is being supported and maintained on production.