Creating and deploying applications is like a carefully choreographed dance. One that requires balancing business goals with expectation setting. This feat includes steps like writing groundbreaking code, solving timing restrictions, and overcoming the technical obstacles between all of the teams involved. Ensuring that the dependencies and timelines between the development and testing teams are in sync and align with the hosting company and their assigned help desk engineers can be a daunting task in itself, and it often creates a bottleneck in the process. Even though this dance can be repeated countless times, it’s usually this last step that is clumsy and always results in a different outcome. What if there was a more streamlined, succinct approach to creating and duplicating environments?

What Is Killing Your Deployment Timeline?

Often, the environments in which applications are developed, tested, and deployed compose one of the biggest variables that can impact an overall timeline. The elements of the environments are the same almost every time: a carefully constructed staging environment, which is a cleaner, more stable version of the development environment, both of which closely mimic QA and production environments. When the time comes for deploying to a live environment, unless the environments closely align, inevitably something goes wrong. A setting or policy on the staging or development environments didn’t get applied to the other environments, security restrictions, different versions of installed software or libraries or replication errors can delay deployments. While the reasons can vary, it typically comes down to a difference in environments.

Applications developed in a team-based environment usually employ some type of code versioning software. Whether using GitHub, SVN, or any other flavor, the concept is the same: teams work from a code base that can be updated and merged into a central repository that everyone pulls and works from. What if teams could apply the same approach to their environments? Whether working in a local development environment or live environment, the same concepts could apply. The server needs are going to be the same: preferred operating systems patched to appropriate version for the builds, databases, installed software, code packages and libraries in designated locations and quantities. Teams could simply create a build, or stack, that works for them and provision or deploy the environments on-demand.

Automation + Application Development

The landscape of Cloud hosting and cloud-based automation makes this approach not only achievable, but streamlined, affordable, and easy to use, no matter the team size. CenturyLink Cloud has taken a developer-focused approach to cloud hosting, through current offerings like Blueprints and the upcoming release of CenturyLink Cloud Runner, a product that allows for quickly creating and managing environments through repeatable jobs. With Runner these jobs and environment configurations can be versioned, just like an application code-base, and deployed at a moments notice. With state-based, idempotent, and parallel execution, Runner makes creating and scaling environments take minutes, not days or weeks. This approach takes the guess work out of deploying applications to different environments. Say goodbye to the clumsy dance and technical obstacles around deploying to different environments with different variables and settings. With Runner you will get the same environment, same result, every time. Its never been faster or easier!

Interested in staying up to date with Runner? Want to be notified about our Beta Program as soon as it's available? Sign up here.