Often when we hear the term Software Development Life Cycle, we think of agile frameworks. In order to remain agile, we can apply similar procedures to the Software Release Life Cycle, or the process by which we move a product from coding into development.

By applying the same principles to this narrower part of the software production process, we can apply agile principles to this stage as well, and it integrates well with the DevOps philosophy too. The software release cycle is essentially a term for all the stages of the maturity of software, as it is being prepared for release.

The stages of the software release cycle typically include pre-alpha, alpha, beta, release candidate, and general availability. The release cycle itself refers to each of these stages as a whole.

Release Stages

In the earliest stages, limited numbers of people should be given access to the software, as it is likely to be at its buggiest. In the pre-alpha stage, the only ones with access will typically be the development team, and this encompasses the earliest stages from planning to early execution. At the alpha stage, testing is being given to the product as a whole. It is typically only being tested in-house.

By the time a release has reached the beta stage, it has been deployed on the customer site, and testing by targeted users occurs to identify if any bugs or changes need to occur in the software. This is where you can target your internal team in your feature flag to be able to test in production. Once it has passed beta-testing, it is defined as a release candidate, with the final stable version released to general availability, and the public. Testing may continue, but the product itself is considered to be stable.

How Feature Flags Work

Feature flags, sometimes known as “feature toggles,” are functions that make it possible to turn certain features of an application on or off at a given time. They are immensely useful for the Continuous Delivery model, where items are being released at various stages prior to the entire application having been completed. With feature flags, certain items can be toggled on or off depending on their stage of development, without slowing down the release of other parts of an application.

One of the advantages of feature toggling (or feature flags) is that you can theoretically test parts of an application directly in production, but with parts that are only accessible to a specific group (such as through using “dev cookies”). This provides the ability to do true end-to-end testing and to see how well a project will work in its actual eventual environment.

Feature flag management systems make it easy to control which group of users see which new code. That makes it easy to map to your Software Development Lifecycle. You can release just to the development team working on the code to begin with, then expand to additional engineering, QA, and product teams. Finally, you can begin to roll out to customers, often in some proportional roll out or by segmenting users by attributes such as geography.

By using feature flags, you can also improve deployment by reducing feature branching and supporting trunk-based development. With this highly release-focused approach, you are able to give your users a great user experience.

Feature Flag Example Use Case

Let’s say you have a member of your development team that is working on some new features that will take several months to complete. However, your release schedule is set to bi-weekly. You can work on code that integrates well with existing code by using a minimal number of feature flags within your application. These toggles can simply be turned on and off when needed.

An example of feature flag usage is as below:

<toggle name="flagged_code">Code which is not ready yet</toggle>

We can then set toggles to be on or off so that there’s a feature in the code which will exist but not yet be turned on.

The code may exist in the application, however, the end-user will have no ability to see what is occurring; this flag can be turned on when it is ready. The toggle will be placed in an if-else statement that will do the decision making to determine whether or not you will see the new feature, depending on the targeting rules you created.

Feature Flags and Scalability

One of the useful aspects of feature flags is that they promote scalability. It can make it easy to dial up or down server load to deal with changes in performance. In case you need to scale up and there is a sudden slowdown of performance, various flags can be temporarily toggled off to keep the application running without requiring the entire thing being taken offline.

By adopting feature flags, you enable your applications to move far more quickly through the Software Development Release Cycle. You can release elements of your beta tests prior to the entire application being complete, and are well prepared to scale up or down, enabling you to continually provide content without sacrificing the overall functionality of your applications.

Learn More About Feature Flags

Interested in digging deeper on feature flags? We’ve got you covered:

• Watch this video on Feature Flag Best Practices
• Read more about feature flags in our free Feature Flag Best Practices eBook
• Learn about the Top Three Feature Flag Use Cases
• Find out more about the Pros and Cons of Canary Release and Feature Flags in Releases

Be sure to follow us on Twitter @splitsoftware, and subscribe to our YouTube channel.