This blog post is part of a series of recaps of talks from our Trajectory conference.
If you’re waiting to use feature flags only once the code has actually been shipped, you’re missing a trick.
Ramiro Berrelleza, CEO and Co-Founder of Okteto, joined us at Trajectory to share how you can enable feedback earlier in the process and make reviewing changes more accessible for everyone (not just engineering team members) by using feature flags together with Cloud Development Environments.
We’ve summarized Ramiro’s talk, which you can watch in full below. You should definitely check out all the Trajectory talks when you have the time—there are loads of inspiring stories from LaunchDarkly customers and our own team to help you discover more ways to deliver better software, more quickly and safely.
What are Cloud Development Environments?
“Cloud Dev Environments is this concept where you have a platform where every member of your team can automatically deploy an entire copy of an application for themselves … everybody gets their own copy of your application. You can develop there, you can run your tests, all of these things,” Ramiro explained.
"So the biggest benefit, besides having an entire copy of the app for you, is that you are no longer limited by what you can run on your local machine. You get the replica of production," he said. "You don't have to wait until staging or production to do all this testing and validation, because your environment is very realistic. This is not like your local machine where you have to mock services or ignore certain dependencies. Here in the world of Cloud Dev Environments, you have everything for yourself."
Ramiro went on to explain how Cloud Dev Environments are super easy to share due to their running in the cloud: "You have a link that you can send to anybody on your team and they can play with the environment, see the latest feature, or run some experiments."
What feature flags + Cloud Dev Environments mean for feedback
For a lot of engineering organizations, when a change is requested, staging might be the first opportunity for stakeholders to see that change live and interact with it. Picking up on issues at this point is inefficient and it could take a while for them to be rectified as the dev team may have moved onto another task in the meantime. This process is pretty frustrating all round and can result in suboptimal software being released to your customers.
"When you have feature flags and Cloud Dev Environments, feedback doesn't happen just at the end of the cycle. It doesn't happen just when you have a PR ready or even worse, when your code hits production," said Ramiro. "With these two technologies together, you can enable feedback for everybody—not just developers—as soon as you write the first line of code."
Ramiro demonstrated the workflow by showing how his LaunchDarkly environment was tied to his dev environment, rather than production. "That means that I can turn flags on and off," he said, "without affecting staging, production, or any other developers." With this setup, you could have a feature flag for each change or improvement you’re working on. That way, you can share a preview of each change with a select group of reviewers ("your closest or most friendly customers") first.
We love feature flags for testing safely in production, but really, testing new functionality at any stage of your development process is going to be valuable for validating that you’re making the right changes. "Then the developer has all the confidence in the world that this is meeting the spec," Ramiro said.
So where previously you might have:
- Had to wait for a change to reach staging to be able to share it with stakeholders OR
- Needed everyone to have a local development environment set up to check out a change
Now, with feature flags and Cloud Dev Environments, anyone can preview and interact with a proposed change at any point in the process.
Involve your customers more easily
"So the PM can then take the [preview] link and go gather feedback from the CEO of the company," he said. "He can even go and do some customer research, schedule a Zoom call with two, three customers, show them this link, and get more feedback."
What’s powerful is that all of this can happen before anything is shipped—even before a PR or single line of code is committed—which allows you to include more people in the feedback cycle. You’re no longer limited to getting feedback from people who can read code.
To watch more talks from our Trajectory conference, go here.
.webp)
