Architecting a Better Rollout with Continuous Delivery

DZone 's Guide to

Architecting a Better Rollout with Continuous Delivery

A recorded joint webinar from LaunchDarkly and Codeship on ways to use their tooling for Continuous Delivery.

· DevOps Zone ·
Free Resource

Quality assurance doesn’t end after you deploy. In a recent webinar hosted jointly by Codeship and LaunchDarkly, Codeship co-founder Florian Motlik said, “While QA is undoubtedly important, you need to extend the QA to after the deployment to production. Feature flagging becomes that extension to continuous delivery that allows you to bring that quality into already released code, to make sure your customers really get the best experience.”

Perhaps you’ve already implemented continuous integration and then deploy — something Codeship enables for a lot of great companies. The missing next level of sophistication in continuous delivery is rollout.

“The missing next level of sophistication in continuous delivery is rollout.” – @LaunchDarkly

You’ve put effort into your deployment, but now that you have the ability to continuously deploy, you still can’t separate rollout. Companies extend QA out into the real world using feature flags — a prudent alternative to begging someone to look at a QA or beta server. You get the ability to find out how well the feature is doing, then turn it off if necessary. Additionally, you can do this without a deployment.

There’s a way to validate product features using these systems that you don’t have to manage yourself. At this intersection of continuous delivery and feature flagging, you’ll find continuous integration platform Codeship and feature flag as a service provider LaunchDarkly.

Here are some key takeaway points from the joint webinar hosted recently by Codeship and LaunchDarkly co-founders. I recommend watching the recorded webinar if you want to go deeper into any of these topics:

  • New Docker as Codeship infrastructure. Send Codeship a message to get on the waitlist for this. Also, sign up for the Codeship Docker Platform webinar.
  • Best practices for total parity on your local system in CI and with production. Your CI system should support any version, run against any version, and be able to run on your local system, no matter the version.
  • Best practices around Github flow. How Codeship recommends you handle continuous delivery through your repository.
  • Seven ways to use feature flags. Including what’s best for B2B versus B2C, when you should block TechCrunch, and how to use features flags to get an advantage.
  • WorkHands case study. How and why they chose to use Codeship and LaunchDarkly.

A few quotes you’ll hear in this recorded webinar:

“It’s like if you don’t wash your dishes for a couple days, then all of a sudden you have a huge pile of dishes. Without using continuous integration, we just accrued a lot of technical debt… and it got to the point where to the point where the smallest change was incredibly risky.” -Patrick Cushing, CEO of WorkHands, on not using continuous delivery (as related by Edith Harbaugh)
“Together, Codeship and LaunchDarkly give you that whole cycle of building, testing, releasing, and then validating, not just from a technical perspective but from a product perspective.” -Florian Motlik, Codeship co-founder & CTO
“Push when you want, as often as you want — but you don’t have to worry about everything being visible to everybody.” -Edith Harbaugh, LaunchDarkly CEO & co-founder, on using feature flags
“A common complaint of feature flags is that they add a lot of technical debt. I agree with this — they add technical debt if you’re not careful. If you’re aware of the features you’ve wrapped, it’s actually very, very easy to sunset an old feature because you’ve taken the care at the beginning to wrap it.” -Edith Harbaugh

Find the recorded webinar and slides here.

best practices, continuous delivery, devops, docker, github

Published at DZone with permission of Andrea Echstenkamper , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}