In this episode, Edith and Paul are joined by Scott Raney, Partner at Redpoint Ventures. Edith, and Paul hear from Scott why continuous delivery matters in modern software development. This is episode #21 in the To Be Continuous podcast series all about continuous delivery and software development.
Earlier this year, I wrote about why staging servers should die – that they actually increase risk and time and decrease quality. I’ve been very pleased at the thoughtful comments and feedback I’ve gotten about why effective continuous delivery and DevOps means no staging server. The one that made me the happiest was “Dreams exist to become reality. Here is one I’d like to achieve at work.”
Here I’ll address the feedback I received, and what’s standing in the way of achieving this dream.
First, there was a large agreement that “waterfall deployment” with a staging server added time and risk to the launch process. Rapportive founder Sam Stokes agreed, saying “Staging environments are an evolutionary dead end. They get out of sync, slow you down, just get neglected.” https://twitter.com/samstokes/status/690689667306369024 Christan Deger, Autoscout Software Architect said “staging environment, even in a completely automated cloud setup, requires constant effort and produces costs.” Dave Nolan gave a talk at Pipeline London https://vimeo.com/162633462 on #nostaging.
Here are the questions and concerns about the practicality and validity of the “#noStaging” Dream.
“Don’t we need to test major infrastructure changes in Staging?”
I’m not advocating pushing untested code willy nilly into production. I am advocating for through and complete automation, continuous integration and feature flagging, with the goal to get as quickly as possible to production. The reason to kill staging servers was said very well by Joseph Rustcio, Librato CTO & co-founder “You think of everything in advance of how a user will use a feature, and you still miss half of them.” The purpose of DevOps is to move as fast as possible from code on a developers box to customer.
One great case study is Librato. Librato uses feature flags to wrap features, deploying their code and then ramping volume up and down, controlling risk. The allure of a staging server is that all systems can be thoroughly tested there, “guaranteeing” a painless final deployment. However, the moment where you push code to the real world is the scariest, because the real world NEVER matches staging. By using feature flagging, Librato could de-risk a new infrastructure project. They used “Branch-by-abstraction” to ramp on and off a new infrastructure. The old way would have been to push the entire new infrastructure at a slow time like 3 am, then when something went wrong, scramble to fix, precisely when memories and tempers are short due to sleep deprivation and key people might be asleep. With feature flags, Librato could ramp up volume in the real world, with real data. Ruscio says of their rollout with feature flags, “We never got paged at night for an issue with the new system, as we were only introducing it during the day when we were available. So all issues could be addressed while we were available. With feature flags, we could even dial back risk during lunch hour.”
“But we need a staging server for contractual reasons”
Having a staging server for contractual reasons is arguing for an artificial artifact. As Dave Farley, co-author of Continuous Delivery” says “it’s not done until it’s delivered to users”. Lamont Lucas, FastRobot co-founder, says “media and advertising companies want final approval before a feature goes live, generally from non-technical approvers. Flagging all users coming from a gateway lets you fulfill the contractual obligation (of showing a feature to them for approval) while preventing you from having an entire legacy/pointless staging setup.”
“What about performance testing?”
Sean Byrnes, CEO/Founder of Outlier and the Founder of Flurry, often had to “test that new features work in a production-like environment and don’t compromise the integrity of our systems”, as Flurry had millions of users worldwide. However, Byrnes continued, “You don’t have to load test EVERY feature to failure”.
The failure of most features it’s lack of load as there’s no customer interest. However for feature where you do really need to know the failure rate, an alternate server other than production can be spun up ephemerally for that reason. Just don’t call it “the staging server” – it’s a production-like load system spun up for a specific reason – to test load – and then shut down after it’s purpose is complete.
“Feature flags are only good for shallow UE changes, not for Microservices”.
Actually, micro services make using staging servers even more painful as many versions of different microservices might be running across staging and production. Deger says, “ In a microservices architecture with lot of independent deployments going on, using a single staging environment would inadvertently test integrations with services in different versions, than what is currently in production. This gives a false sense of security. So we decided to not have a staging environment at all and find different ways to release features with confidence while only integrating in production.
We are constantly learning new techniques to deploy into production without a staging environment. There are many different ways of integrations that we need to care of, but overall it makes us faster and the testing and release experience is better.””
“Harbaugh is biased”
I advise that instead of a confusing, time consuming, expensive, redundant and ultimately unsuccessful staging server; development teams should use feature flags to move features to production and do their feature validation as quickly as possible on production. I’m not unbiased – I’m CEO of a feature flagging management platform, LaunchDarkly. However, I founded LaunchDarkly the same reason I publish articles, podcast , and give talks on DevOps: because I care deeply about the power of feature flagging to create better quality software and reduce risk. You don’t need LaunchDarkly to feature flag – it’s easy to get started with a simple config file or open source library. Deger, is the contributor to an open source framework for feature flagging and huge proponent of no staging servers.
“Let’s talk when you want to do serious software development”.
Just as waterfall development once seemed the only way to guarantee success, so did waterfall deployment until recently. The most innovative and fast moving companies like Netflix, Google, and Amazon have found that they can move faster if they’re more agile. And serious? I think of software development as fun, as exciting, as liberating, transforming – with software people are connected worldwide, interacting in incredible ways, and their lives are better. I hope software never becomes too serious for me.
Separating feature rollout from code deployment to mitigate risk in continuous delivery
We are in the era of continuous delivery, where we are expected to quickly deliver software that is stable and performant. We see development teams embracing a suite of continuous integration/delivery tools to automate their testing and QA, all while deploying at an accelerated cadence.
However, no matter how hard we try to mitigate the risk of software delivery, almost all end-user software releases are strictly coupled with some form of code deployment. This means that companies must rely on testing and QA to identify all issues before a release hits production. It also means that companies primarily rely on version control systems or scraped together config files to control feature releases and mitigate risk. For instance, many homegrown feature release systems rely on hard coded values read from config files. These systems can work with a handful of configuration values, but accrue massive technical debt at scale and may require a full redeploy for any updates.
Once a release is in production, it is basically out in the wild. Without proper controls, rolling back to previous versions becomes a code deployment exercise, requiring engineering expertise and increasing the potential for downtime. Continue reading “Powering Continuous Delivery With Feature Flags” »
GlueCon is a low-key, practitioner focused developer conference near Boulder, Colorado. Docker had been announced at a prior GlueCon, and so the conference has a well-deserved reputation as to where the next breakthrough will be announced. In a two-day conference with six tracks per day, you could “choose your own adventure” to learn about relevant tools for your domain of “Cloud, DevOps, Mobile, APIs, Big Data”, or get exposed to techniques outside your usual realm. I was amazed by how many people I thought I knew, then realized they looked familiar from their Twitter handle. However, if you’re looking for Dreamforce or the CES of Software, this is definitely NOT it – which I liked.
My favorite talk was Travis Vachon, Engineering Director of CircleCI on “DNA of Successful Development Teams”. The room was packed to the rafters, with people sitting on the side railings. My main takeaway was
— Edith Harbaugh (@edith_h) May 25, 2016
Emmanuel Paraskakis, VP Product at Apiary.io talked about trying to get developers to write consistent APIs by providing them with a style guide full of “musts” and “should” for format. “No one read my 20-page style guide”. I think we’ve all been there. Continue reading “GlueCon 2016: Developer + Operations, Tools + Teams” »
It’s been a busy spring for LaunchDarkly, the leading feature flag management company. We’ve hit a huge milestone – we’re serving Billions (with a B) feature flag events daily, for companies all over the world.
LaunchDarkly helps companies with better DevOps by managing code deployment separately from business logic. We allow an entire product development organization to control who gets the right feature, when. Developer tool companies like CircleCI, Apiary and AppDirect use us to power their own DevOps. But, LaunchDarkly isn’t just for developer tool companies to reduce risk and iterate quickly on feature release. Across industries, companies like Ten-X, Behalf, Handshake, and TrustPilot integrated LaunchDarkly into their development and release cycles to move faster with higher quality.
Why are companies moving so quickly to LaunchDarkly? We offer true polyglot support for web and mobile applications. Have a Node.js web application with Go micro-services and a mobile app written in Swift? We got you covered. And, more importantly, we allow companies like CircleCI and Behalf to go beyond DevOps to transform the way they deliver software from idea to delivery by uniting product management, engineering, QA and operations. We offer end to end feature flag management to allow an entire product development organization to control who gets the right feature, when.
To help spread the word about the power of feature flagging, we also have awesome partners. We were thrilled to participate in the Microsoft Build in March. I was part of the Microsoft DevOps Keynote, showing our end to end integration with Visual Studio Team Services. And we’re proud to power feature rollouts for effective DevOps at companies like: Continue reading “LaunchDarkly – Now Serving Billions of Feature Flags at Warp Speed” »
Decoupling feature rollout from code deployment and the rise of user-centered deployments
The Origin of DevOps
In 2008, Patrick Debois laid the foundations for DevOps at an Agile conference in Toronto. He was trying to come up with a solution for the inherent conflicts between developers and system admins. Both disciplines seemed to be at odds: developers wanted to release software more frequently, but system admins wanted to ensure stability, performance, and scalability. While this conflict isn’t necessarily black and white, it highlighted the need for developers and system admins to no longer consider themselves as mutually exclusive roles, but rather as cross-functional partners.
A year later, Paul Hammond and John Allspaw gave a talk at the Velocity ‘09 conference that highlighted the necessity for cooperation between Dev and Ops. This inspired Debois to coin the term “DevOps” (#DevOps), which quickly picked up momentum (and a fair share of controversy).
Now, with the proliferation of DevOpsDays meetups and DevOps communities around the world, the movement has accelerated.