A recent article summarizes the history of the DevOps movement and identifies two phases in it. The first phase focused on increasing collaboration between traditionally siloed engineering teams (Dev, QA, Ops) whereas the second phase, which is currently emerging, takes this as established and aims to improve collaboration between engineering and non-engineering teams, such as sales and marketing, as well.
With its formal origins traceable back to 2008, followed by a report in 2011 which summarized and recognized DevOps as more than just a fad, what has been termed the 1.0 movement has attempted to streamline the model of continuous software delivery, focusing on increasing collaboration and trust, and adopting practices that facilitate this. The current set of practices and tools reflect the maturity of the movement.
Last year’s State of DevOps report captures some of the key points of the status quo - faster and more frequent deployments to production, higher visibility of failures, and faster time to recovery.
The next phase of DevOps is driven by closer interaction between engineering and non-engineering functions like sales. Customers and markets are always changing and engineering teams have to respond to this continuous change by being ready to deploy features in tandem with sales and marketing campaigns.
Just as in the first phase, a combination of practices and tooling has emerged to facilitate this. These include ChatOps, feature/task management tools, and dashboards. The focus is on speed without compromising on system stability.
The use of feature flags is being touted as one of the key mechanisms to keep up with such demands. Traditional software releases have a one-to-one relationship between a code push to production and the availability of specific features for the end users. Feature flags decouple this relationship by adding the ability to disable a specific feature unless a flag is set, which can be done at runtime.
There are several advantages to decoupling feature rollout from code deployments:
- Code can be released in chunks even if a feature is not complete. The feature can be simply turned off.
- A/B and beta testing.
- End users can be categorized into groups, e.g. power versus normal users, paid versus free users.
Feature flags require discipline on the part of the engineering team and a well-thought-out design of the software. Many organizations with large deployments, like Facebook and Etsy, leverage feature flags.
