Talking Relaxed, Simplified Release Processes with FullStory and SPS Commerce featured image

Engineering teams are constantly facing the challenge of deciding which tools they can develop in-house, and which to outsource.

A lot of the decision-making process comes down to the value the team will receive from a third-party tool relative to its cost.

When it came to feature management, the team at FullStory surveyed its internal capabilities and realized it was probably smarter to look outside the company's walls for an answer.

"Our main thing was try to get to a place where we could feel pretty good about rolling out services that had a lot of interdependencies in a really safe way," said Braden Schaeffer, senior software engineer at FullStory. "I don't think we could have done that ourselves."

In a recent Launch & Learn virtual event, we spoke with Braden and Jake Freeberg, lead software engineer at SPS Commerce, about why their teams chose to initially move forward with a solution for feature management, the implementation process, the worst thing they've ever released into production, and more. The discussion was mostly Q&A-based and included questions from our audience and LaunchDarkly’s CMO, Keith Messick. 

“I've done many of these Zoom panels, and they go either one way or the other—an A or an F," Keith said during the event. "This was an A." Below are a few excerpts of the A-grade, hour-long discussion.

Spoiler: Following the implementation of LaunchDarkly, Braden uses words like "chill" and "easy" to describe the improved release process at FullStory. "Releasing is just no big deal," he said.

As for Jake's take on releasing with LaunchDarkly? "It just makes my life simpler," he says. "And my deployments more relaxing."

How do your teams use LaunchDarkly?

First up for questions was Braden, who explained how independent deployments of services was one of the first big projects his team took on at FullStory.

“We had a big, monolithic deployment, and it was key for us to have something that allowed services to be deployed with different logic branches and different features being released to different companies or different customers,” he said. “We used LaunchDarkly to make that happen—among many other things. This was our number one reason for adopting LaunchDarkly, and it's gotten even more ingrained ever since.”

Jake then explained how SPS Commerce is a SaaS company that serves retail and vendor suppliers. LaunchDarkly allows his team to build on new features and roll them out in beta to a subset of customers to ensure they function correctly. “This allows us to do continuous deployments and not have to worry about putting things out in front of customers until they're truly ready,” he said.

How do you think about the broader organizational rollout of LaunchDarkly?

One of the most overlooked aspects of starting up a new tool like LaunchDarkly is how the actual implementation process goes within the organization and its teams. Are teams excited to adopt it, or is it something they simply get around to eventually?

Jake explained that when he and his team were rebuilding an important flagship application, they realized a need for a feature flagging solution. Jake’s team was pointed to LaunchDarkly. Shortly after adoption, his team took part in several tech meetups and conferences where other users demonstrated how LaunchDarkly helps with their deployment and releases. “That really kept the ball rolling,” he said. “And as more teams were using it, they'd tell their friends, and that's how it gained steam—and continues to gain steam—within SPS Commerce.”

As for Braden, his team was initially excited about independent deploys. But when the team was shown use cases about building an API B2 without having to create an API endpoint B2, they realized the advantages of rolling out new features via feature flags instead of updating 20 services to call a new endpoint:

“We did a Launch & Learn and were shown how one team can get independent deploys this week, and then how a different team will get independent deploys that week," he said "And we have this feature flag wiki, which is basically some code examples, and a link to all the LaunchDarkly documentation. We were all excited. There was a buzz. People were excited to use it. It was almost like a ball rolling downhill.”

Want to learn more? Watch the webinar

This is only a small portion of the topics we covered during the full discussion. Watch the full video to hear answers to more questions, including:

  • Does your team use DORA metrics or other KPIs to measure these impacts?
  • How does your team manage the feature flag lifecycle in LaunchDarkly?
  • What's something that you wish you knew before implementing LaunchDarkly, and what advice do you have for others who are early in their adoption process?

Plus, you can hear Braden recount why a certain error-filled release led to him having what he describes as “one of the worst feelings I ever had as a software engineer.” You’ll also hear how a plugin Jake once worked on for a large kitchen supply company ended up bringing down their checkout for a full 24 hours—a story Keith then describes as “hilarious.” Watch it here.

Like what you read?
Get a demo
Related Content

More about Best Practices

January 25, 2022