An Environment for Every Developer?

If your organization has moved to a public or private cloud you’ve had the conversation about the scope of development environments. Should every developer get an environment in the cloud?

Traditional test environment management has focused on QA and staging environments for the qualification of software for release. Your development velocity is a function of how quickly you can build and deliver software to QA environments. Your release quality is a function of how accurately your staging environments reproduce production.

The new question is this: do development environments fall under the scope of Test Environment Management? They do and they don’t, let’s explore this trend in detail.Development teams are becoming used to the idea of being able to spin up a new environment in a few minutes via an API call. If you hire developers using AWS and/or Heroku, you notice that some of them don’t develop on local workstations. Instead they are developing directly on the cloud. Example, if a developer is working on a complex application instead of configuring microservices to run on a local machine to query a local database they will simply spin up some containers or VMs on the cloud.

These are the developers who will show up in your organization expecting you to give them cloud resources for development. If you don’t expect these questions they can come as a surprise and they can put strain on your infrastructure budget.

Adapting Your Organization to Meet Developer Expectations

Let’s use Heroku as an example of an external PaaS product that often defines internal expectations for development teams. Using Heroku a development team can create an application using a standard web framework in Java, Node.js, or Python. The time between project creation and the creation of low-cost dev environments is measured in minutes. The ease with which a dev environment can be created means that many developers forgo local test environments and develop on the cloud.

This new capability changes the daily development cycle, and reduces onboarding time. New developers can have a dedicated end-to-end environment in a few minutes. Compare this to ten years ago when a new developer would only be productive after a few days of installing and configuring local software.

When these developers bring these expectations to the enterprise it creates new demands for infrastructure and changes the way test environment managers approach allocation and budgeting for software projects. If you have hundreds of developers expecting the same level of immediacy and cloud-based self-service you’ll need to find a way to satisfy these requests and you’ll need to understand how these environments fit into the overall software development lifecycle. If you don’t, you run the risk of exhausting your infrastructure, and wondering why some projects need so many different environments.

Do cloud dev environments fit under the TEM umbrella?

Yes, but they need to be self-service. Developers need tools to spin up systems without increasing the load on your TEM team. This means that your team will need to provide documentation and training for self-service cloud tools. These can be external systems such as AWS or internal clouds such as Openstack.

As development environments evolve, your developers need the freedom to innovate with new technologies and architectures. As they start to develop using cloud-based environments this creates a new opportunity for TEM teams to use development environments as a proving ground for new automation techniques.

This trend is showing up in the enterprise and it’s starting to cause friction for TEM managers who might not yet appreciate what’s driving this transition. If you’ve run a report on environments and noticed that one or two teams has hundreds of QA environments this is a signal that you have a team that is trying to transition to cloud-based development.

With Plutora you can track development environment requirements alongside QA environment requirements and you can start to enlist your developers in the efforts used to automate the setup and hydration of these test environments. It’s time to get ready for this trend and plan accordingly. You’ll need to budget for these new environments and you’ll need a tool to track demand.