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


Related Topics: DevOps for Business Application Services, DevOps Journal

Blog Post

Multiple QA and Staging Environments | @DevOpsSummit Serverless #CloudNative #DevOps

managing test environments brings is a huge obstacle to achieving DevOps efficiencies in enterprises today

Why do you need multiple QA and staging environments?

When a company looks at its numbers and asks, "Why do we spend so much on hardware?" it's the responsibility of CTOs and CIOs to provide a quick answer. Hardware is expensive and resources are limited, so when a business examines spending and plans budgets it needs to look at how money is being spent, and also how it could be spent. When we are talking staging environments, it falls to test environment managers to justify spend and identify opportunities to reallocate infrastructure and environments.

In the past, test environment managers worked in detailed spreadsheets. They would have environment engineers compile spreadsheets filled with the resources used for QA and testing. As technology improved, some organizations adopted tools and systems to automate the building of this environment inventory, but for many, this is still a manual process. But now, there are solutions that help organizations automatically manage multiple test environments with enhanced visibility, traceability and control.

With this additional visibility however comes 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 - and there normally is a good explanation for it, but it is sometimes hard to explain. Below are some helpful tips to talk about the need for multiple QA and staging environments.

Multiple QA and Staging Environments

There are various reasons why a team might need multiple QA and staging environments here are just a few:

Teams working on parallel development efforts. If a project has regular releases, when a development team is finished with a feature, a QA team takes over to validate that feature. During that QA process, development teams need 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 prioritized and staged. If you have a team working on a series of larger, multi-month development stories to launch a new product these efforts generally require a dedicated environment. These QA efforts 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 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 combined increase in the number of environments required to perform end-to-end testing.

A Project's Environment Needs

Considering all of these factors is important when a test environment manager examines the current allocation of test environments. There's no single rule to cover the number of test environments required, but there a few things to consider when assessing a project's environment needs:

Projects 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 require an even greater number of environments.

Projects supporting critical, customer-facing applications need to move quickly (with more environments) - Projects that need to respond to customer-facing bugs in hours or minutes need maximum agility which may require additional environments. Projects that support back-office operations that can wait a few days to fix bugs often don't need multiple staging or production environments.

It's a trade-off - Some projects will demand many environments to support multi-stream development projects and QA efforts to enable continuous deployment, which does push on resources and budgets. This is where hard decisions are made between cost and agility, and this is a tradeoff that test environment managers have to be able to calculate and communicate.

Conquering the challenges that managing test environments brings is a huge obstacle to achieving DevOps efficiencies in enterprises today. Gaining automated, real time visibility across the enterprise portfolio to establish a single source of truth to align teams and identify and resolve resource conflicts is key. A tool to keep track of environments at all times makes the job of test environment managers easier by displaying strategic allocation challenges in a single, consolidated place. Gone are the days of having to fire up Excel and send emails to gather this data again.

More Stories By Dalibor Siroky

Dalibor Siroky, CEO and Co-Founder, Plutora: Dalibor has close to 15 years of leadership, consulting, enterprise product, and operations experience in Australia, Asia, and Europe. Before co-founding Plutora, Dalibor was the founder and managing director of Finotaur, a leading provider of independent management consulting services to Wealth Management, Investment Management, Private Banking, and Payment institutions within the Asia Pacific region. Earlier in his career, Dalibor served as the CIO of financial advisory software at Macquarie Bank, head of solution architecture at Commonwealth Bank of Australia, and as a management consultant at PricewaterhouseCoopers. Dalibor holds an MS in Software Engineering with distinction from the University of Oxford and an MBA with honors from the University of Chicago. Dalibor is also a graduate of the Royal Military College of Australia and served as a Captain in the Army.