Regardless of the software methodology used, an application’s release cycle often contains several phases before a piece of code reaches production. While the name for each phase will vary from company to company and even team to team they normally have a consistent theme.
The first phase for a software team is usually called “requirements.” In this phase project managers, business owners, and developers work together to iron out implementation details for a software application. Depending on the methodology used, this phase can consist of completely planning an application from first feature to last (waterfall), or it can consist of a set of features to be implemented in the next week to a month (agile). While the process varies, the results are the same. Once a group of requirements for a product are decided on and green lighted the implementation process begins.
The second phase for a release cycle is normally the “design” phase. A design team with guidelines agreed upon in the requirements phase works to create wireframes and mock ups of the product with input from engineers and managers to create a consistent look and feel for a software product.
Once the design phase is completed, the “development” phase begins. Now armed with business & design guidelines, engineers develop the product. As the product is developed, the engineers will consult with the design team and product managers to ensure the software meets expectations as the application’s requirements change due to technical, user experience, or user interface challenges. The workforce of the “development” phase usually consists of front-end engineers who focus more on the user facing portion of the software and back-end engineers who work to translate business rules for a product into code.
On a strong software team as developers begin to complete features that are slated for a software release, features are pushed to a remote server that automatically runs unit tests written by the developers. These tests usually test pieces of code in isolation and prevent logic and syntax errors. This phase is often called “Continuous Integration” because the software code changes are run automatically as developers complete features.
Once the tests pass the “Continuous Integration” phase, the quality assurance team (QA) starts the important task of validating that the developed features meet the requirements specified in the “requirements” phase and that they are bug free. Since it’s incredibly unproductive to have QA test code on the developer’s machine, a centralized server or version control system is used to allow QA to test software independently from the developer who coded the feature. During this phase, QA is normally tasked with testing that all the pieces of code written by developers work together as a whole correctly. This phase is often called “integration testing”, “regression testing”, or “acceptance testing” depending on the type of tests written.
Once the QA team gives the okay for a set of features, the group of features is grouped into a release and pushed onto additional remote sever(s) often called “staging” or “demo”. These environments/phases are considered by a software team to be stable and are often used by business owners and managers to demo unreleased functionality to clients, partners, and other parties prior to release to production. This environment is often seeded with fake data to make the software seem as close to production as possible.
Once a set group of features are pushed to “staging” or “demo” they are often given a release name or version number to mark the release as a possible candidate for release to production. Before shipping a release to production, the release is pushed to the final phase before production, “load testing”. In this phase, the operations (ops) and release engineering teams deploy a release to an environment as close to product as possible and stress test the release to ensure the software can handle scaling from 1 to possibly hundreds of millions of users without failing.
There can often be additional phases before “production” such as “beta” where a release is deployed to only a small percentage of a company’s customer base to be absolutely certain that the software will not fail customers. Once the release engineering team gives the okay from “load testing” or “beta” a release is ready to be deployed to the final phase “production”.
“Production” is the final step in a release’s life cycle, and can often be the most stressful and also satisfying step in the release cycle for a software team. After passing all prior phases, a software team determines a date and time (release date) for customers to receive the new software. The release date can be set as far in advance as months or even years or in as little foresight as an hour or two.
The time the entire software release cycle takes will vary between teams, releases, and types of software. A team that follows a waterfall release cycle is more likely to have a set date well in advance whereas an agile software team is more likely to have a shorter release window as the software changes are fewer than a waterfall release cycle. The content of the release also plays an important factor. A release that patches a critical bug for customers may complete the entire release cycle in a few hours as teams rush to fix issues customers are having, whereas a more feature rich release will tend to have a longer software release cycle as features may be grouped together for marketing or rebranding purposes. Additionally, a team that is releasing software to the web has more flexibility around release times then a team developing a native software application that has to go through a third party app store and be approved.
Regardless of software release cycle length, once a release date approaches the release engineering and development operations teams go into action. It is also normally required for at least one member of the development team to be present in case a bug fix is required due to a software flaw in the released code.
The release engineers create a release checklist and plan that outlines the steps that are required to release the software to production, notes for any contingency plans in case something goes wrong, and estimations for how long the entire production release process will take. This information often needs to communicated across multiple time zones and teams as production environments are often spread out across the globe to minimize customer load times. Some teams coordinate production releases using wikis or phone conference calls.
It is however becoming more and more popular to use web applications like Release[Board] that provide a “living” dashboard that stays up to the second and tracks all the release tasks for a production release. The popularity of real time software dashboards is due to the complexity involved in deploying software to production. A single deployment task done in the wrong order or simply forgotten can cost a software company millions of dollars (for some companies per second). With all the steps and phases that brings a piece of software from idea to implementation it critical for a software team to cap their software release cycle with a successful release and happy customers.