A recent McKinsey study revealed the positive effects of “Developer Velocity” on the overall success of a business. “Developer Velocity” is defined as: “empowering developers, creating the right environment for them to innovate, and removing points of friction”.
To measure this, McKinsey created a measurement called the Developer Velocity Index (DVI), pinpointing the most critical factors in achieving Developer Velocity.
The study found that DevOps tools had a particularly significant impact on developer velocity and business performance.
We at Livecycle could’t agree more. Through our market research and our own experience as developers, we also recognized the importance and potential of empowering dev teams with better tools to optimize their developer experience. And that’s why one of the key features of Livecycle is the ability to create “ephemeral environments” from every pull request.
Now, some of you reading this are probably thinking - “That’s absolutely incredible…”, while others among you are probably asking: “what the hell is an ephemeral environment in the first place?!“.
Well, today is your lucky day, regardless of what’s actually going on inside your head. Because we’re going to give you a quick overview of what an ephemeral environment is, and also tell you why it is indeed, so absolutely incredible for developers and development teams.
The dictionary defines ephemeral as ‘lasting a very short time’. So technically, an ephemeral environment is a disposable environment of some kind that doesn’t last forever. The environments we’re referring to are part of the CI pipeline, allowing stakeholders to get a quick, playable glimpse of some version of the code. They are stand-alone, live environments that are disposable by nature and by definition.
But this is only part of the story.
Other (and perhaps more accurate) names used for these environments in a development context include: ‘live previews’, ‘deployment previews’ and ‘on-demand environments’. These environments represent a powerful solution for developers specifically, and for dev-centric teams more generally.
And in order to fully understand what these environments offer as a solution, let’s first appreciate some of the problems that they have the power to address.
Product development is usually a team sport involving coders, designers, marketing folks, PMs, QA people and beyond. On the one hand, we need everyone’s involvement to get the product out. On the other hand, the need to incorporate so many stakeholders into the workflow introduces several challenges. We’ll list a few that are pretty common:
- Pre-production product visibility: Like it or not, developers hold the keys to the start of the feedback loop. Everybody wants and needs to give input on the latest changes, but they are totally dependent on the coders for checking in the code, building it and sharing it with them in order to get things going. This can create a frustrating bottleneck that impacts everyone, especially when it involves spinning up new pre-production servers and merging stuff to staging.
- Limiting unnecessary interruptions: Uninterrupted focus is key to productivity, especially for coders. But when everyone else is dependent on them to generate, distribute and even explain the latest changes - coders can find themselves context switching way too often. Even once the latest code is compiled and shared, there’s the inevitable avalanche of “quick questions” about permissions needed to access the staging environment, what exactly made it into this build, or similar.
- Clear and timely product review feedback: Feedback loops are called “loops” for a reason. And it’s probably because they can leave your head spinning and make you dizzy. With agile product teams constantly revving new features, it’s critical that everyone involved be able to give clear, timely feedback. Development teams often waste time on feedback that is either not understood, or no longer relevant since it was given on a version of the code that is already outdated.
Now that we’ve sufficiently enjoyed the problems, we can better appreciate how ephemeral environments can address them, provided that the environments possess the following characteristics:
- They mimic a subset of production
- They are automated and on-demand
- They are easily shareable and accessible
With these characteristics, ephemeral environments respond to the common workflow challenges we described above:
- Pre-production product visibility: Automated ephemeral environments give all stakeholders access to the review the latest code without any ongoing dependency on the developers themselves. And developers no longer need to worry about enlisting DevOps or spinning up more servers themselves, since the preview environment provides everything on a silver platter.
- Limiting unnecessary interruptions: Once this bottleneck and developer dependency is relived, developers have a lot less to do and a lot more focused times to focus on coding the next feature.
- Clear and timely product review feedback: Since all stakeholders have instant access to actually interact with a live version of the latest and greatest code changes, subsequent feedback loops can be tighter and faster with contextual, clear feedback on the latest versions of the product.
In founding Livecycle, we thought a lot about the challenges development teams across the board seem to face sprint after sprint. We came to the conclusion that automated ephemeral environments for every pull request is a great way to relieve the early workflow bottlenecks and reduce dependency on developers.
It’s a great example of a developer tool that can be a key driver in improving developer velocity and pushing the entire team, product and business to succeed.
This is why a core functional pillar of our platform is the ability to automatically generate and share these environments with the relevant stakeholders with every commit.
Now, coders continue to focus on coding without worrying about no complicated staging setup is necessary, and other stakeholders receive instant, one-click access to the latest and greatest version.
