Everything You Need to Know About Environment Management
In an ideal DevOps world, teams have the autonomy to experiment on their loosely coupled systems at speed without causing failures in their own or other systems.
However, in the real world enterprises have tightly coupled systems and the dependencies between them represent points at high-risk of failure. They persist in using outdated waterfall, project-oriented ways of working alongside heavyweight ITSM processes for change, release, and environment management that don’t optimize the balance between speed and quality.
Whether your technology team has a plan to rearchitect your monoliths or not or move to incremental, agile ways of working, managing the environments that make up your landscape reduces risk and lays the path to adopting the DevOps ways of working that accelerate your ability to deliver value to your customers.
In an ideal world, each autonomous team manages their own instances of the environments for their product or service (value stream). But in the real world, dependencies mean teams share environments – and they can’t be used simultaneously without causing versioning problems that are virtually impossible to solve later. Environment management helps releases go faster and more safely, resulting in a higher performing organization.
In this guide, you’ll learn the key essentials to Environment Management, including the latest trends and expert tips. You’ll discover how to implement Environment Management and access free templates and checklists as well as other resources.
Book
Everything You Need to Know About Environment Management
Get the PDF version of this guide to learn the Environment Management essentials, including latest trends & expert tips.
What is an Environment?
In the context of information technology, an environment is an instance of an application, product or service (or integrated set of technology components that serves a group of users or customers). This could also mean a network, but here we are specifically concerned with the software environments that enable a value stream to deliver work and changes to their customers.
In addition to the development environment and the production or live environment, there may be multiple testing and staging environments.
These environments could be running physical or virtual machines, or be containerized or serverless. Or a combination of some or all of these.
What is a Route-to-Live?
For value to be delivered to a customer, it needs to be built, tested, and deployed. As the code becomes ready for its release to the wild, it’s likely it has lived in several different environments; from the developer’s machine to various testing servers, staging servers, and then deployed to the live, production environment. These steps are what we call the Route-to-Live (RtL) AKA the Path-to-Production.
What is Environment Management?
Environment Management is a set of good practices used to provide an effective, end-to-end management service for all pre-production (e.g. developer, build, test, staging) and production environments used when releasing changes to software projects, products, platforms and services.
Having lots of teams and lots of environments, many of which multiple teams may need to use, causes two main problems:
- Environment booking conflicts, which cause delays
- Lack of technical consistency between environments, which cause quality issues
In order to mitigate those problems, individuals or teams who manage these environments are tasked with the following:
- Maintaining a central repository of all test environments, including current versions and connectivity details
- Allocation of test environments to teams as required
- Creation of new test environments as required
- Monitoring of all test environments to ensure they are available and performing as expected
- Liaising with project teams to ensure that there is appropriate cost control in place for test environments
- Deleting or updating outdated test environments and recovering resources
- Automation of all activities, including provisioning, deployment and data load activities
- Preliminary investigation of issues on the environment and coordination of issue resolution
- Analyzing data for environment issues, identifying trends and taking proactive steps to resolve issues and co-coordinating for a long-term fix
The Objectives and Benefits of Environment Management
Environment management aims to reduce the risks associated with having multiple environments across multiple teams. This means ensuring that delays, problems and incidents are not caused by issues that are traced back to environments being incorrectly set up or shared.
The benefits of getting environment management right are:
- Fast flow of work to customers
- Reduced frustration and burnout in technology teams
- Reduction in change fail rate through stages
- Time saved from less unplanned work
- Lowered infrastructure costs as improvements are visible and actioned
A Brief History of Environment Management
We’ve always had environments and infrastructure running our code but a few key things have changed in recent history:
- Environment volumes and requirements have increased for companies who have several software products, platforms, services or projects.
- The levels of interfacing, connectivity and dependencies between several systems in most organizations have increased as systems have evolved.
- As organizations seek to accelerate the rate at which they deliver change and their customers realize value, they cannot afford to compromise on quality and compliance; they aim to balance throughput and stability.
- Environments have become increasingly virtualized, even serverless, in cloud native infrastructure.
- Teams are racking up automation – for environment provisioning, DevOps toolchains and elasticity.
Digital transformation and the associated adoption of cloud and agile/DevOps has shone a light on the problems that poor environment management can cause in terms of delays, problems and incidents. Teams must proactively coordinate their efforts to ensure their underlying infrastructure doesn’t get in the way of their performance goals.
How Environment Management Works: An Overview
Environment management contributes to improving the overall quality of software development and support through the lifecycle. It encompasses a set of good practices to provide an effective, end-to-end platform management service for development and test (pre-production) roles and teams. The software test bed or development environment could consist of a client server application, databases, middleware, interfaces and APIs, daemons, customized processes (written in any software programming language), FTP utilities etc. Functional test phases such as unit, integration, acceptance, all manner of performance or non-functional testing and development phases all require environments. Here are some of the good practices that make environment management work:
- All environments, as part of the delivery cycle, should use the same components (system, software) to maintain consistency with the production environment (although sometimes this is not realistic, due to costs and the requirement to carry out parallel development and testing).
- Maintain consistency across all environments used for development, build and unit test, with any variations clearly documented with the implications for testing understood and communicated.
- Maintain version control of all components (server, workstation configurations etc.)
- Conduct technical check of applications to ensure the environment stability after every deployment, and update all design and architecture documentation appropriately.
- Centralize storage of the development packages to ensure that the deployed packages are all sourced from a single place.
- Develop a strategy to support multiple versions of the same components released as part of parallel releases.
- Automate deployment activities (server, application etc.) to reduce the risk of errors that are inherent in manual activities
- Identify and document all application dependencies, and ensuring that interfaces are either replicated or stubs are provided to support integration testing
- Track changes to the environments and utilizing a robust dedicated change management process for the test environments that links to the production change processes.
Key Terms in Environment Management
Development: The process of coding or composing code components to create changes, enhancements or fixes to a software product, platform or service.
Environment: An instance of infrastructure on which an application or portion of an application runs to be available to the teams for pre-production tasks such as develop, build or test, and to be available to the customer in production or ‘live’.
Environment Provisioning: The process of creating an environment and making it available to its users.
Functional Testing: Tests that check whether the software performs as expected from a feature perspective, including how it integrates with other systems.
Live: The production environment that the customer uses.
Non-Functional Testing: Tests that check whether the software performs as needed from the perspectives of speed, security, reliability and compliance.
Path-to-Production: The steps or stages an application or part of an application follows from development to live. The same as Route-to-Live.
Pre-Production: The activities, steps or stages prior to the software and enhancements being made available to the customer in the live environment.
Production: The version of the software and its underlying infrastructure that the customer accesses.
Route-to-Live: The steps or stages an application or part of an application follows from development to production. The same as Path-to-Production.
Testing: Quality checks for functional and non-functional requirements.
Value Stream: All of the activities needed to go from a customer request to a delivered product or service.
Key Concepts in Environment Management
It may not be the topic that has you leaping out of bed in the morning, excited at the day ahead, but getting environment management right is fundamental to powering digital transformation and harnessing the cloud and DevOps techniques that lead to higher organizational performance.
Even if you feel like you are hamstrung by legacy environments, on-premise infrastructure, and ancient processes right now, there is a path forward for you and there are ways to transition incrementally and evolve to a place where:
- Environment provisioning takes seconds not weeks
- Teams can self-service environments and housekeep them effectively
- Environment dependencies are eliminated so teams can work autonomously
- Test data is clean, useful, and immediately available for teams
- Deployments are fast and frequent and environment management causes no friction
- Environment availability is greatly increased leading to more testing, faster
Environment management touches every part of the Software Delivery Lifecycle (SDLC) from development, through build and test and into live; the Route to Live (RtL).
Challenges that Environment Management Addresses
Here are a few time-consuming and expensive problems that occur when environments are poorly managed:
- Test environments differ from production environments in terms of the operating systems, configuration, software versions, patches, etc. The wider the gap between test and production, the greater the probability that the delivered product will have more bugs/defects. This not only results in poor code quality but may also lead to product failures in production or live environments.
- Poorly managed infrastructure assets can result in budget spikes and may delay the testing process.
- Poorly administered and poorly controlled environments/infrastructure assets can result in unintended consequences. It may also result in poor configuration and change control.
- Root cause analysis of incidents and defects becomes challenging due to the misalignment of test and production environments; Mean Time to Repair (MTTR) is high as is the cost of an incident.
- Due to budget or time constraints, it isn’t uncommon for application developers as testers or for testers to be tasked with directly testing the code in production. This results in a lack of accountability but also poses a deep risk in the software development process. Regulations require that technology organizations control and have accountability in their software development processes.
- It is very common for test teams to clone or extract the production data and use it for testing purposes. This approach is time-consuming, error-prone and may not meet the data protection policies. Further, it isn’t change-controlled and cannot be audited.
- Communication plays a very critical role in any phase of the software development lifecycle. Poor communication can result in misunderstanding of the testing/business requirements and may also result in failure to identify important defects.
- Defect tracking tools need to be configured well and there should be a process in place to manage their lifecycle. It isn’t uncommon to assign defects to the wrong teams and miss important information. This not only results in wasted time/money but may also infuse more defects at later stages.
Using an environment management platform like Plutora addresses these challenges and supports the visibility, workflows and processes needed to ensure that flow is not adversely affected.
Environment Management, DevOps, and Agile
The principles of DevOps are The Three Ways;
1. Flow
2. Feedback
3. Continuous experimentation and learning
Let’s look at them in the context of Environment Management:
Environment management practices and tools like Plutora support The Three Ways by:
- Supporting automated environment configuration and provisioning and coordinating shared environment booking to reduce delays due to unplanned work and handoffs
- Ensuring environment consistency and making stages, gates and status visible so teams shorten and amplify feedback loops and act immediately when there’s a problem
- Releasing time and injecting capacity into teams that they can invest in trialing new features, enhancements and platform improvements
Environment Management and ITSM
Release management incorporates environment management in most ITSM implementations – but it’s also closely connected to other processes such as:
- Change management
- IT asset management
- Deployment management
- Infrastructure and platform management
- Software development and management
It’s a critical function for assuring the quality and speed of releases. Consistent environments use these ITSM practices:
- All environments use the same components so that they are production-like and test results can be trusted.
- Variations in any environment are documented and the implications for quality assurance are understood and communicated.
- Version control of all components is maintained and environment drift is actively avoided.
- Environment stability is tested after every deployment..
- Deployed packages are all sourced from a single, central place.
- Multiple versions of the same components can be released as part of parallel releases.
- Deployment activities (configuration and code) are automated to reduce the risk of errors that are inherent in manual activities.
- Application dependencies are identified and it’s ensured that interfaces are either replicated or stubs are provided to support integration testing.
- Changes to the environments are tracked utilizing a dedicated change management process for the test environments that links to the production change processes.
Enterprise Environment Management
Enterprise releases often involve multiple teams who have dependencies across their systems or into shared systems. Their age also means they may have high amounts of technical debt in the form of legacy systems. Enterprises often create environment manager roles to tackle the problems associated with dependencies and debt.
Environment managers understand how environments are grouped and mapped to each other.
This means they can also understand and map impacts, conflicts, and dependencies and manage work to reduce risk.
They are also responsible for managing the environments as assets and decommissioning them when they are no longer needed. They have a place at the Change Advisory (or Approval) Board (CAB) to raise any concerns.
However, heavyweight change processes, i.e., CABs, don’t correlate with higher-performing organizations. They fail to deliver the quality they are intended to and they slow processes and value streams down. Good DevOps change practice is lightweight, peer-reviewed, and has automated as many of the checks as possible. But it takes time to evolve.
Cloud has brought the possibility (and reality for many organizations) of quickly replicating and provisioning environments (spinning them up and down) as needed. It introduced the concept of ‘cattle, not pets’ where we treat our infrastructure instances (traditionally machines) as herds of livestock where we aren’t emotionally attached to them and are happy to put them down as and when we need to. This is different from when we had much-loved machines in our data center that sat there for years as we attended to them. There is a problem though – not all applications can be made cattle.
Where we have very large, monolithic, and tightly coupled applications, they aren’t suitable for this paradigm. And it can take a long time and a lot of effort to rearchitect and rebuild these applications for cloud and microservices environments. And sometimes it just doesn’t make business sense to make the move. So sometimes, we are stuck with our pets.
This has also brought challenges around exponential cloud spending caused by projects treating cloud as if it’s physical machines. Also, it requires technical know-how to provision. Audit trails of cloud environment ownership are lost and no-one is sure who to cross-charge for them.
Another issue is that digital programs have not been well monitored, leading to converting what they want to cloud, and leaving some business-critical systems behind.
Environment Management, CICD, and the DevOps Toolchain
When teams are practicing DevOps and have a Continuous Integration and Continuous Delivery pipeline (or DevOps toolchain in place), they need to be able to quickly check the status of their builds and accelerate any handoffs that exist between stages. They need a tool like Plutora that can:
- Give them a clear view of the status of all builds and ensure that application versions are correct on the path to production
- Keep everyone informed of build and test activity to ensure that everyone can view application status (success or fail) at each stage of the pipeline
- Send automated alerts to test teams when code is available
- Automatically link new builds from development to their original change ID
- Ensure accurate test coverage and identify trends impacting build quality
- Apply a build job to an environment and build on-demand, using self-service
- Assess code quality
- Show when versions were deployed
- Find bottlenecks and inefficiencies
- Track all code changes
Case Studies in Environment Management
Environment management may not be new, but progressive ways of working demand a new approach, powered by tools like Plutora See what Plutora’s customers have to about how they have benefited from the platform:
Vice President of Electronic Health Record System from a Leading Healthcare Provider
Service NSW| read more
Mark Lewis, UAT Test Environment Manager| read more
Environments Delivery Assurance Manager at a multi-national utility company| read more
Amit Bali, Lead Release Manager, eBay| read more
Danny Tobias, Project and Portfolio Environment Manager, United Energy and Multinet Gas| read more
Marc Dovico, Senior Project Manager at BT Financial Group| read more
The Environment Manager’s Job
As organizations learn to evolve from dominator hierarchies and leaders distribute authority and devolve power to multi-functional, autonomous value stream teams, the need for traditional roles created to centrally manage processes fades away. These roles are evolving too, to support progressive ways of working.
An environment manager is one of those roles. Environment management is typically a centralized function where individual environment managers are allocated to projects or programs aligned with a particular line of business. As organizations move from project to product or value stream-oriented ways of working, the role of environment manager changes.
The fact remains though that environments continue to need to be managed, dependencies still need to be understood and exceptions and risks mitigated. But the role itself evolves as the organization does:
Myths About Environment Management
- Developers must maintain, monitor and troubleshoot test environments. System testing is not tied to the development environment. Developers often want to focus on their core tasks of design and development, and are reluctant to own, drive and improve test environments. Value stream teams can also have dedicated testers, who will not only own test environments, but also be responsible for reducing downtime, increasing automation, accepting environment bookings, resolving conflicts, managing configuration, and defining and tracking SLAs, inventory, and knowledge management processes. When there are a lot of dependencies between teams and systems, having cross-team environment managers can help.
- Monitoring and observability is for production. All environments (including base infrastructure, databases, application logs, and application availability) need automated, proactive, and real-time monitoring to prevent defects, identify environment issues early, minimize incidents, and increase test environment availability and predictability. While monitoring tools can auto-create incidents for critical alerts, trend analysis of repeat issues can prevent their recurrence. Similarly, known error databases (KEDB) reduce mean time to repair (MTTR). AIOps, predictive analytics and self-healing environments all require continuous observability.
- We can’t afford any more environments. With limited budgets, many teams make do with existing, legacy testing environments. In the long run, this technology debt (ineffective infrastructure usage, legacy systems, application duplication and redundant tools) will increase the cost of operations and reduce agility. Cloud makes it possible to provision environments on-demand and through self-service. Environments can be configured and deployed from ready-made templates vastly increasing consistency through the RtL stages.
- ITSM is for live systems: In DevOps and value stream management, we connect all the way through the RtL and use ITSM standards throughout, especially for service, incident, problem, access, configuration and change management. Configuration management databases (CMDB) (the repositories of IT assets, their configuration and relationships) must also be created for environments. Environment and value stream management platforms like Plutora provide continuous compliance capabilities so teams and organizations can be confident their ITSM policies are applied throughout the SDLC.
Environment Management with Plutora
Plutora does even more than extensive value stream and release management. For environment management it enables teams to get the full picture of their entire pipeline with status reporting and tracking for every build.
With build status reporting, teams can easily view the status of builds throughout their software pipeline and identify trends that create actionable insights for improvements in quality and speed. They can know exactly what versions were deployed and when.
They can monitor utilization rates and reclaim idle resources and block out maintenance windows. They can link new builds to original change IDs and get automated alerts when code is ready for testing. In Plutora, all test results are automatically tracked and stored in a centralized data mart creating a single source of truth, which eliminates the need for someone to collect, compile data in order to roll up and distribute reports.
Environment managers can quickly identify detailed test coverage for even the most complex releases, and track testing progress, results, and discovered defects. Irrespective of the test tool used, the data is aggregated in Plutora and analytics produces test execution, coverage, and results reports that can be used to compare and contrast between value streams.
- Plutora links change IDs with new builds to support comprehensive test case planning. Its Requirements Traceability Matrix (RTM) makes activities and conflicts visible and supports test case planning.
- Manually provisioning environments is a lengthy and largely obsolete process now, thanks to automation which has matured to a robust and standard practice largely referred to as Infrastructure as Code (IaC). Teams may already have IaC tools in place and Plutora can be used here too.
- Teams and environment managers can maintain configurations in a centralized library for provisioning and scheduling. Integrations are available with CI servers to run builds on-demand to expedite code deployment.
- Environment booking requests used with existing enduring environments become self-service provisioning requests so nobody has to wait for someone else to make an environment available for them to use.
Plutora helps you gain complete control of environment management throughout the enterprise with a consolidated end-to-end view of configuration, allocation and bookings.
Table of Contents
