Plutora Blog - Test Environment Management
Why do you need all these environments?Reading time 4 minutes
Test Environment Managers are often asked to audit everything. If there is a question about budgets they need to quickly identify opportunities to reallocate infrastructure and environments. Hardware is expensive, and resources are limited so when a business looks at the numbers and asks, “Why do we spend so much on hardware?” it means that CTOs and CIOs are asked to scrutinize spend quickly.
Before tools, like Plutora were available a test environment manager would fire up Microsoft Excel and create a spreadsheet. They would ask environment engineers and development teams to fill out this spreadsheet with the resources they are using for QA and testing. As technology improved over the years some organizations have adopted tools and systems that can automate the creation of this environment inventory, but in many companies, this is still a manual process.
During this process, there are often discussions about how many environments a particular project really needs. One project may only have one QA environment while another may have four or five. Environment managers are frequently put in a position of having to ask teams to justify why they need so many environments.
There are various reasons why a team might need multiple QA and staging environments here are just a few:
Teams are working on parallel development efforts. If a project has regular releases there’s a good chance that when a development team is finished with a feature, a QA team takes over to validate that feature. During that QA process, development teams often want to move on to the next feature. In these scenarios having two QA environments make sense as features can be delayed and releases will have to be serialized if a QA environment is “tied up.”
Long-term feature releases need to be developed while short-term bug fixes are qualified and staged. If you have a team working on a series of larger, multi-month development stories to launch a new product these efforts almost always require a dedicated environment. These are QA efforts that take months, and require customizations to databases that cannot ship to production. If you don’t have an isolated system for these longer-term initiatives you will be unable to fix bugs as they are identified in a production system.
Systems that rely on services. If you develop code that relies on back-end services that are also being modified by independent development teams these teams may require multiple environments that are configured to connect to the appropriate testing service. Service-oriented architectures and microservices cause a combinatorial increase in the number of environments required to perform end-to-end testing.
Considering all of these factors is important when a test environment manager examines the current allocation of test environments. There’s no one rule to cover the number of test environment required, but there a few things to consider when assessing a project’s environment needs:
Projects sitting in front of services often need more environments – If your application fronts a number of services under active development you will have a team that requests multiple QA systems to connect to different releases and versions of these services. If you have a multi-levelled architecture with services depending on other services you’ll see an even greater number of environments required.
Projects supporting critical, customer-facing applications need to move quickly (with more environments) – Projects support back-office operations that can wait a few days to fix bugs often don’t need multiple staging or production environments. Projects that need to respond to customer-facing bugs in hours or minutes these are the projects that need maximum agility and which may require additional environments.
It’s a trade-off – Some projects will demand tens of environments to support multi-stream development projects and QA efforts to support continuous deployment. There’s a trade-off between cost and agility, and this is a tradeoff that test environment managers have to be able to calculate and communicate.
It’s easier to do that when you have a tool that keeps track of environments all the time. That tool is Plutora, and with our Test Environment Management tool, you’ll be able to see strategic allocation challenges in a single, consolidated place. You’ll never have to fire up Excel and send emails to gather this data again.