Do you ever feel like you have no idea what you’re doing? Like you’re just kind of going along with things, doing your best but not really sure if you’re doing it right?

Here’s a little secret I’ve learned over the years: Nobody knows what they’re doing.

Denis, with his steadfast approach and surgeon-like precision? Hannah, with her pen and notebook, who writes down every detail to later review? Kendall, who is quick on the trigger to any bizarre question that upper management tosses her way and always leaves them with good laughs and big smiles?

All of them? They have no idea what they’re doing. They don’t have to know what they’re doing. They’ve unlocked the biggest secret that formal education has desperately tried to unteach us: Failing is fine! Failing is good! Failing is the fastest way to success!

In the world of software development, we’ve already accepted this as scientific fact. We embrace this and weave it into the foundation of our methodologies and systems. We know, with absolute certainty, that nothing is certain. The winner will be the little boat whose chart is scribbled on the back of a napkin and can pivot on a dime, not the monolithic Titanic who, despite the captain’s best efforts, is going to collide with that iceberg.

However, even though we recognize the advantages and the need to be agile in this industry, that does not mean that we’ve mastered all the ways to optimize this. While different Software Development methodologies can have their place for different problem spaces (just as different programming languages are better suited for some problems over others), one particular approach to failing fast has gained a lot of traction over the past decade. The DevOps methodology was forged from the fires of Agile, and today DevOps has been crowned the champion of how to build great software, quickly and wicked fast. Modern technology companies that thrive to compete place DevOps on the forefront of their mind.

What is DevOps?

If you’re not already familiar with DevOps, the term can be a little confusing. DevOps began as a cultural movement within companies. Rather than Developer teams taking their code and throwing it over the fence for the Operations team to deploy and monitor (while the Security team haughtily throws their arms in the air over any concern—be it major or minor—introduced by the other teams), DevOps works to tear down these artificial walls.

The way this works in practice is through tight feedback loops and blurring the edges of responsibility. “DevOps” has turned from an idea into a career where you build a racetrack for product development. This enables the idea-to-deployment cycle to hasten. No longer do we need to take months to plan, build, test, release, deploy, evaluate. No longer do we need to make sure every release is perfect “because there’s no going back”. Now we can do what we do best: Make mistakes.

You’ve heard of (or worked with) companies that deploy their code tens to thousands of times a day. This is incredibly powerful. Ideas always look a little different in practice and sometimes they turn out to be bad ideas. But sometimes those silly ideas that would have you laughed out of a boardroom turn out to be the ones worth their weight in gold. With the ability to experiment and quickly reset, we can fractal our way to the perfect solution for any problem.

Why do I need Environments?

If your company is big enough, has the capital, and understands the need, you may be lucky enough to have a team of DevOps Engineers who work to help make sure everyone has the environments they need, and the tools to build and deploy code.You have your build and deploy pipelines. Your code only takes one push, merge, and a couple button clicks to make its way into production. You’re. Living. The. Life.

Okay, sure, there are rough edges. The Developers and QA might be a little agitated that they have “bad data” in their databases. This bad data causes weird shadow bugs that wouldn’t exist “for a real user”. You have Product Managers and UX/UI Engineers digging around your QA and Staging Environments to make sure the feature matches the requirements, but they run into these shadow bugs and in a panic, hold a meeting to discuss “why the application is broken”.

C’est la vie. Your environments are starting to drift apart, but it’s okay. QA finds a bug, but they can’t be sure when it was introduced. The Developer isn’t sure either, there are a few features that others were working on that have all been merged into here. One major feature is ready, but the others are blocked. Hours tick into the evening as the team scrambles to fix the concerns, introducing more in their haste, until finally QA calls to cancel today’s deployment. Disappointed and mentally taxed, everyone finally goes home frustrated.

This happens regularly. It’s a clog in the system, but it is manageable. However, what you don’t know yet is that your competitor has committed to allocating resources to addressing this problem directly. It took them twelve months (a bit off from their original six-month estimate), but now the tooling is built out and QA can create a build from any branch, on the fly. Now the data is fresh, every time, freeing QA to get their hands dirty in this sandbox. The Product team is excited to be able to look at new features side by side before they’re released, and features can even be put on hold or tinkered with in isolation.

Meanwhile, your company is falling behind. The only way you’d be able to keep up is to spend the money and the time to build this for yourselves. It’s a big investment, a big time commitment, and your company is worried. What if the project fails? There’s a lot at stake here.

Environments are the key to rapid prototyping and quick feature releases, while maintaining a solid, battle-tested product. But environments are also expensive. The upfront and maintenance cost put them outside the scope for many companies and by the time a strong need rears its head, the architecture has evolved into a technical labyrinth.

At Release, we understand this problem in depth. We have customers who use Release to give themselves a competitive advantage after they realized environments were holding them back. A new concept in DevOps has emerged called Ephemeral Environments which eliminates the bottleneck of shared staging environments. An Ephemeral Environment is automatically created when a developer does a pull request and has just their changes on their branch. This environment spins up for UAT testing and when the branch is merged, it disappears. Developers never wait for access to environments as they appear as part of their development workflow.

We're using Ephemeral Environments which has put us on fast-track to shipping deliverables that we can stand behind. The unfortunate truth is that building this infrastructure is necessary to have a fighting chance against the heavyweights. But the problem is that the cost and time required can be astronomical. The Release platform specifically aims to solve this problem directly by providing Environments-as-a-Service. This way, you get all the advantages of environments, without the costs or headache of Doing It Yourself, freeing you up to focus on the business and the product needs.

In short...

Remember: Nobody knows what they’re doing. And that’s okay. Nobody’s ever known what they’re doing; we’re all just stumbling around. But if we stumble with purpose, we can fall into something that works. If we fail fast, we get to success faster. Our methodologies in software development reflect this, but in practice, building supportive infrastructure is costly. If we can get to a place where we optimtimize failing fast by deploying early and often, we can more quickly find what our product needs to be. We can find success without ever having to know what we’re doing.

Ephemeral Environments

Curious about Ephemeral Environments and what they can do for you? Check out this article on what Ephemeral Environments are and what they can do for you.