02 Oct 2017

Removing Risk from Product Launches: A webinar with LaunchDarkly, CircleCI, and GoPro

We recently sat down with one of GoPro’s Senior Engineering Managers, Andrew Maxwell, and the CTO of CircleCI to discuss reducing risk in product launches. Andrew talked about how his team delivered their code two weeks early, tested in production, and had an overall successful product launch. He goes into detail, sharing how his team uses continuous integration and feature flags to make product launches like that possible.

The Big Launch

Andrew’s team is responsible for web applications. Last September his team was focused on a big initiative around a product launch called GoPro Plus, which allows users to access and share content wherever they are. This launch included both mobile and desktop apps, and promoted two new cameras in the GoPro line.  

Two Weeks

The team delivered their code and pushed it into production two weeks early:

“…we used LaunchDarkly to push our code to production, turn the apps off — off by default—and then make sure that we had everything pushed out, deployed, and the infrastructure running live without customers actually seeing it.”

Two weeks gave them time to do a full integration test their features. They tested both in-house and in production—slowly opening up who had access—so they could get valuable feedback, find bugs, and make continuous improvements in the weeks leading up to the big launch. On the day-of, they were confident in their work and simply turned on 12 feature flags.

Check out the full webinar below to learn more about how the team used CircleCI and LaunchDarkly, their planning strategies, and best practices for their continuous integration pipeline.

08 Sep 2017

Saving Private Instances

You are a new Director of Engineering at an enterprise company. The company has just moved your product to the cloud and is hosting in Microsoft Azure. You come from a tech startup where you ran all of your software in the cloud and focused on building product. So naturally you have just implemented instrumented monitoring with HoneyComb, Kubernetes to manage your containers, and you’re thinking about leveraging serverless architecture.

You moved to this established enterprise company because they are providing technology to the healthcare industry and you are passionate about this space. They want you because you are good.

Now you face a challenge—how can I bring the good things from my past role and pair them with the security standards and compliance in my new role? Well, let’s first think about what the good things from your past role entails. Your previous team:

  • Deployed 5 times a day
  • Used feature branching
  • Feature flag first development
  • Implemented continuous integration

You realize you used 3rd party software for most of these good things, and had homegrown for others. You decide your first project is to research what software the new team is using, has built, and what software you will need to build and buy.

Security and the cloud.

Now, before we dive in, let’s consider the security standards and compliance you need to think about in your new role:

 

  • Where is my data stored?
  • What data is being sent over to the third party—is it PII?
  • Where connections are made to third parties?
  • How can I set different access control?
  • How it will work when connection fails-redundancy?
  • Is it HIPAA compliant?
  • How is all this audited?

 

Like your new company, many companies are just starting to move key operations to the cloud. This is SCARY. Moving into Azure will allow your company to free up floor space, add more server redundancy, easily scale up and down, only pay for what you use, and focus resources on revenue generating activities— security is still your responsibility.  And though these are all great things, you are not a security company.

Now you are tasked with bringing in these good processes, and they include 3rd party software providers. Products in this space are inherent in your development lifecycle and very close to your core application, but you need to ensure they are secure.

As we all know, most software providers in this space are cool tech companies in The Valley, far and isolated from the realities of your secure enterprise world. You look at on-premise options. And you remember that you’re driving change in the Healthcare space, not looking to manage infrastructure. The cloud options require a significant audit that is time consuming. A SaaS provider carries an ongoing risk that requires you store some data on 3rd party servers, which is a non-starter in Healthcare.

Is there a middle ground?

There is one more option many software providers offer: Private SaaS, also known as a managed instance, Dedicated VPC, or private instance. You surmise if they do not have on-prem, private SaaS, or a really really good security team, then it’s not likely their team is accustomed to working on enterprise challenges.

What exactly is a private SaaS offering? This refers to a dedicated single tenant, cloud software where the vendor manages the infrastructure.

Why choose a private instance?

  • Single Tenant—You will have a dedicated set of infrastructure contained within a VPC. This eliminates the risk of noisy neighbors.
  • Data Storage—Data can be stored in your AWS account or in an isolated section of the vendor’s AWS account. This allows flexibility, if you are in the EU, vendor could spin up the instance in AWS in the EU.
  • Residency—If you have a preference on where the instance is located or need to ensure proximity.
  • Compliance—If you have additional security or compliance regulations, a private instance can be customized to fit your needs.
  • Change Cadence—If you need to know when the software will be updated, you will have better insight and greater flexibility with a private instance.
  • Integrations—If you have custom tools, integrations can be built.

What’s next?

You have narrowed down a few software providers for each job you are trying to solve (continuous integration, branching, feature flagging). You understand the value, the costs, and the security implications. You have chosen to stay in the cloud, which makes your infrastructure team happy. You have chosen to use private instances and SaaS where it makes sense, which makes your security team happy. And you have the tools you need to bring the good things into your new role, so you are happy.

Now you can focus on helping your company deliver product faster, eliminate risk in your release process, speed up your product feedback loop, and do it all securely.

23 May 2017

Risk Elimination and The LaunchDarkly Value-Add

My first week at LaunchDarkly brought me out of the shadows in a hurry.  It began at an offsite strategy session at DFJ, our lead investor, where I learned valuable details about Waterfall vs. Agile software development methodologies. I also gained important insights into a key industry trend affecting the development community: the transition from Waterfall to Continuous Integration/Continuous Delivery (CI/CD).

What I’ve learned as a marketer has deepened my appreciation for what makes the LaunchDarkly solution so unique.

For starters, there are three main categories of customers who will benefit from partnering with LaunchDarkly:

  1. Companies interested in switching from Waterfall to CI/CD
  2. Companies currently switching/recently switched from Waterfall to CI/CD but not yet feature flagging
  3. Companies that are currently engaged in CI/CD, and using a homegrown feature management system

What’s clear is that all three of these customer segments experience different challenges. But all fall into to what our VP of Product and Platform, Adam Zimman, calls “The Risk Gap.”

What is The Risk Gap?

In software development, there is inherent risk in launching new releases. Risk in this case can be broken down into two categories:

  • Risk of losing product value
  • Risk of losing time

The longer it takes an engineering team to launch a new software release, the greater the risk of feature obsolescence. Another risk factor is competitor time to market; those companies that don’t enjoy “first mover advantage” can suffer from demoralized developers who lose interest because they can’t ship quickly enough.

The Risk Gap also means that there is greater operational risk associated with feature releases that carry greater value. The more value associated with a feature update, the greater the risk to your Ops team, because of changes made to your code base.

The Risk Gap is closely linked to the Iron Triangle concept that suggests the following:  while teams should strive to release high value features at a quick pace, the reality is that they’re often forced to pick one or the other (speed vs. quality).

The Iron Triangle mantra is “Fast, good, or cheap. Pick two.”

Let’s see how this affects the three customer categories who will benefit from using LaunchDarkly by examining the Risk Gap/Iron Triangle framework.

CategoryPainDoes Have Does Not Have
Companies interested in switching from Waterfall to CI/CDTakes Dev team a long time to launch releases.-High Quality
-Low Cost - traditional Waterfall methodology
Fast Delivery
Companies switching/recently switched from Waterfall to CI/CD but not yet feature flaggingQuality of releases is at risk.-Fast Delivery via CI/CD
-Lower Costs - not using a feature management platform
High Quality
Companies doing CI/CD + using a homegrown feature management systemA homegrown feature management system is costly to develop and maintain.-Fast Delivery - quick release cycle
-High Quality - continuous feedback loop
Lowest Cost

Each customer category is missing one of the three components of the Iron Triangle: either quality, speed, or lowest cost.

LaunchDarkly’s value-add

LaunchDarkly exists to close the Risk Gap – enabling the largest software engineering teams in the world to responsibly employ the CI/CD methodology, accelerate development cycles, eliminate the risk associated with large releases, and cut costs of developing/maintaining homegrown feature management systems.

For the first time, you don’t have to make tradeoffs with LaunchDarkly.

When you combine the great team here, a revolutionary product, and the opportunity to learn from brilliant minds every day, I am very much so looking forward to bringing our product to market.

30 Aug 2016

To Be Continuous: Category Creation

In this episode, Paul and Edith are joined by Martin Casado, General Partner at Andreessen Horowitz. The group discusses the deeply complicated and difficult process of category creation, with a special focus on technology infrastructure products.  This is episode #24 in the To Be Continuous podcast series all about continuous delivery and software development.

Continue reading “To Be Continuous: Category Creation” »

02 Jun 2016

Powering Continuous Delivery With Feature Flags

Continuous Delivery LaunchDarkly

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” »