From the CEO and Co-Founder of Leading DevOps Company Plutora

Dalibor Siroky

Subscribe to Dalibor Siroky: eMailAlertsEmail Alerts
Get Dalibor Siroky: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Blog Feed Post

Why do you need all these environments?

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-leveled 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.

The post Why do you need all these environments? appeared first on Plutora.

Read the original blog entry...

More Stories By Plutora Blog

Plutora provides Enterprise Release and Test Environment Management SaaS solutions aligning process, technology, and information to solve release orchestration challenges for the enterprise.

Plutora’s SaaS solution enables organizations to model release management and test environment management activities as a bridge between agile project teams and an enterprise’s ITSM initiatives. Using Plutora, you can orchestrate parallel releases from several independent DevOps groups all while giving your executives as well as change management specialists insight into overall risk.

Supporting the largest releases for the largest organizations throughout North America, EMEA, and Asia Pacific, Plutora provides proof that large companies can adopt DevOps while managing the risks that come with wider adoption of self-service and agile software development in the enterprise. Aligning process, technology, and information to solve increasingly complex release orchestration challenges, this Gartner “Cool Vendor in IT DevOps” upgrades the enterprise release management from spreadsheets, meetings, and email to an integrated dashboard giving release managers insight and control over large software releases.