Release Timing and Sequence
There are two flavors of releases that BoldGroup will be managing using an official Release Process to track. These are:
- Maintenance releases
- Feature releases
The two releases follow very different release cadence as well as version numbering. Our version format is as follows:
[Major].[Minor].[Patch].[Build]
Additionally, there are three primary release targets when looking at the end deployment target:
- On-Premises at the customer location
- SaaS model hosted by BoldGroup
- Mobile App (app stores)
Maintenance Release
This release will consist primarily of bug fixes and small enhancements due to the maintenance of our code base. This will occur on a typical cadence of 4-6 weeks for client/server products and bi-weekly for SaaS (AB). This can also include Hot Fixes which are typically released in 1 or 2 days to fix mission critical issues should they arise.
These releases will follow our release process but will have a greatly reduced checklist. They will also only have the ALPHA and GA phases with a typically 1week review period. For HotFixes these may be skipped completely on a per-case basis. The end goal is to allow us to quickly respond to customer issues in a timely manner.
These releases will increment the Patch section of our version scheme.
On-Prem Targets
These releases will be made available and deployed by IT/Support as requested by customers
SaaS Targets
These will be deployed by IT/Development on a weekend after US business hours conclude in PT. This is to minimize disruption as well as load on the systems. HotFixes may require release during business days/hours on a per-case basis.
Mobile App Targets
These will be deployed to production by Development in the respective app stores when the release process signoff concludes
Feature Release
This release will consist primarily of new development of features or products. These are larger scale activities with a lot more knowledge transfer required. This will occur on a typical cadence of one release per quarter. These will be trailing the quarter roughly 30-45 days where the work was completed to allow time for the knowledge to be transferred in the organization. This release will follow the full release process checklist and include all of the ALPHA, BETA, RC, and GA phases.
These releases will increment the Major or Minor section of our version scheme depending on the overall scope. There are possibly some exceptions if the product does not support changing these cleanly. In those cases, the Patch version will be bumped to the next higher tens position to signify a larger release.
On-Prem Targets
These releases will be made available once the full GA is signed off and deployed by IT/Support as requested by customers
SaaS Targets
These will be deployed by IT/Development once the full GA is signed off on a weekend after US business hours conclude in PT.
Mobile App Targets
These will be deployed to production by Development in the respective app stores when the release process signoff concludes.
Alpha
The alpha phase of the release life cycle is the first phase of software testing. Opening testing inside the organization is known as an alpha release. The purpose of an Alpha release is to increase visibility of features under development throughout the organization. Early involvement provides greater understanding and higher likelihood to catch/adjust features that may not completely fit the intended market.
Alpha software is not thoroughly tested by development/QA before it is released to internal stakeholders. Alpha software may contain serious errors and may not contain all features that are planned for the final version. In general, external availability of alpha software is not allowed. The alpha phase usually ends with a feature freeze, indicating that no more features will be added to the software. At this time, the software is said to be feature complete.
Bold Group Dev Process: This is built from an Epic or Feature branch
Summary of Alpha testing
- Must not be expected to be perfect.
- Should be available early in the process and updated along the way.
- Should not be used to evaluate the “quality” of the product
- May be used for internal testing, review, training, and discussion only. (no external access)
- Ends when development is “feature complete”
Feedback during the Alpha testing phase
- Should be provided through a single contact point
- Should be focused on major structure and missing functionality of features that are included
Beta
A beta phase generally begins when the software is feature complete but likely to contain several known or unknown bugs. Software in the beta phase will generally have many more bugs in it than completed software and speed or performance issues and may still cause crashes or data loss. The focus of beta testing is reducing impacts to users, often incorporating usability testing.
The process of delivering a beta version to the users is called beta release and is typically the first time that the software is available outside of the organization that developed it. Beta version software is often useful for demonstrations and previews within an organization and to prospective customers. These users should be performing this testing on test systems not live production environments.
Bold Group Dev Process: This is after all code is in the Epic. Code should not be in Master/Main yet.
Summary of Beta testing
- Must include all intended features and functionality
- Must be time-bounded with a firm end date
- Should not have major bugs but expect to find some minor ones
- Should include some documentation indicating what feature/functionality is to be tested
- May be used for sales demonstrations and to prepare training material
- Ends when beta period expires
Feedback during the Beta testing phase
- Should be provided through a single contact point
- Should focus on helping refine how the functionality will be used in production
- May be very specific to customer data
Release candidate
A release candidate (RC) is the final beta release that is intended to be the production product. It is ready to release unless significant bugs emerge. In this stage of product stabilization, all product features have been designed, coded and tested through one or more beta cycles with no known showstopper-class bugs. Preparation turns to final release packaging, documentation, and other release housekeeping tasks. Bugs discovered from this point on must be evaluated to determine whether they are “critical” and must be fixed before release or held until after release and dealt with as normal maintenance.
Bold Group Dev Process: This is after all code is in Master/Main AND a release branch has been cut.
Summary of RC testing
- Must include all intended features and functionality
- Should focus on documentation and install/upgrade processes
- Should include official QA regression testing
Feedback during the RC testing phase
- Should be provided through a single contact point
- Should focus on helping polish the final product
GA Release
Also called production release, the GA / stable release is the last release candidate (RC) which has passed all verifications / tests. The remaining bugs are considered as acceptable and will be resolved through the standard KanBan process. This release goes to production and is announced/installed/upgraded under each products normal update process. Once released, all future work will be delivered in the next release.
