Introduction
Agile software development practices & faster turnaround of IT projects to deliver has increased the demand for software environments.
In rapid IT delivery cycle Software Test environments provide the platform on which applications are validated through various test phases such as System Test, Regression Test, User acceptance Test, etc.
Management of Software test environments and challenges exponentially increases with complexity of test applications landscape, number of applications under scope, integration architecture and technology variants.
Depending on the complexity of test phases & deployment /infrastructure architectures, provisioning of test environments could be cumbersome and time consuming. In addition to the above depending on factors such as ->
- Complexity of Deployments
- Demand for Environments
- Demand & Supply of Shared Infrastructure Resources
Test Environments can cause a major bottleneck in release cycles.
If Test Environments are not defined and managed it could derail the overall release process.
Release Managers own the process through which deployments are released to environments. Release Manager would be responsible for environments management activity such as Defining Environments, Provisioning, Allocation and Managing.
Nuts and Bolts of Software Environments
How does one define an Environment ?
What is a Software Environment ?
What are the components of an Environment ?
What are the types of Environments?
Environments are deployment platforms on which applications are deployed / configured and made available during various phases of Deployment Life Cycle.
- Software Environment is a collection of hosted servers and application software that provides platform for execution & testing of applications. Typically an environment would consist of ?
- One or More Physical or Virtual Servers.
- Hosted Applications which could include deployments/installations/releases on Web Servers / Application Servers / Database Servers / Legacy Applications / etc.
- Deployment Environment configurations.
- Network Infrastructures such as Firewalls / SAN Storage / Network Switch / etc.
Relationship between Environments & Deployments
Environments and Deployments may sound similar but are slightly different.
Deployment Management has prime focus on planning, executing and managing deployments.
Whereas Environment Management relates to identification and sandboxing a set of resources on which Deployments can be done.
Deployments are done only after environments have been identified & scoped.
Environments management is a part of the Release Management process but it overly involves –
• Environments Planning
• Environments Configuration
• Environments Verification
• Environments Communication
Environments are planned and created based on Release and Test strategy during IT Development Life Cycle. Software test environments often differ based on their purpose and line of business supported (revenue, customer facing, operations, etc.).
For example when development activity is in initial stages there would be demand for Development Environments and as Test Teams get involved in testing the applications, other environments are created and managed based on the requirements of test & release cycles.
Typically Release Environments fall on the following categories ->
• Development Environments – As the name suggests these environments are used by development teams. These environments are used by development team to validate builds/releases done by/for development teams.
• System Test Environment – As software progresses to QA Testing, System Test Environments are created for Application System Test.
• User Acceptance Test Environment – UAT Environments are test environments for User Acceptance Testing of application.
• Pre-Production Environment – Release Environments that emulate live Production. The hardware/software deployment/configuration should be similar to Live Production.Such environments are provisioned to test/validate issues seen on Live.
• Performance Test Environment / Capacity Testing Environment – Release Environments for Performance & Load Testing.
• Live Environment – Release Environment where in Applications are deployed and configured on live production servers for customer.
Environments Management Process
Environments Management Process is closely related to Release Management and it involves identifying, scoping, planning, allocation and management of environments. Environments Management is an iterative process and it involves the following à
· Environments Planning
This is the planning phase of environments management.
In this phase Release Manager would interact with stakeholders such as QA Manager, Development Manager, Technology Architects(Infrastructure / Software),etc. to understand the requirements of environments. It involves Release Manager defining & managing the following activities à
o Identification à Define software environments in the context of software project / product being released / tested. Identification of environments requirements in order to align with Release Cycles / QA Test Phase / Training Requirements of projects.
o Scoping àIdentification of hardware / software resources required for environments. Typically in this phase Release Team should be looking at getting overview of all the different interfaces / applications / hardware /network requirements /etc., required for provisioning of release to environments.
o Planning à Plan creation / allocation of environments in line with environments requirement. It would be a standard practise for Release Manager to Create /Update Environment Plans. An Environment Plan could be as simple as an excel spread sheet or can be detailed Project Plans.
· Environments Configuration
An important element of Environments Management is Environment Configuration. Typically environments are different because the configurations used across the environments differ.
What is Environments Configuration? How do we manage them?
Environments Configurations are changes introduced to applications within an environment that affect the run time functionality of applications. Configurations could be as simple as database connectivity or can even be very complex.
Most importantly the basic idea behind configurations is to ensure that you build applications once and deploy the applications across multiple environments by changing configurations.
Configuration Items (CI) are changes or configurations that need to be identified / managed on environments.
· CI Identification
Identification of CIs is one of the critical functionalities in Environments Configuration.
In order to identify CI, the Release Team needs to define a process wherein CIs introduced/changed during release cycle is identified.
It’s the worst nightmare when development configurations have been applied to Live.
· CI Management
Management of Configuration Items so that the CIs identified are managed and consistently applied to various environments in the release cycles.
In order to manage CI, the Release Manager needs to look into introducing a process for managing CIs and this process could include à
o Introduction of CMDB
Configuration Management database is a repository for persisting CIs. This would be the centralized location for managing CIs that are then used for various releases.
The structure of CMDB and its design is based on factors such as release cycles, environments and projects supported.
o Control of CIs
Something that I have come cross regularly is that CIs have been changed or modified regularly on the environments after the release and deployment. It is very hard & time consuming to debug environment problems when CIs are not controlled.
CMDBs help the issue where in one can refresh the CIs from CMDB to help resolve the issue.
Sometimes changes are introduced in the environments on the fly in order to help QA Team progress in their test cycle but in due course the changes done are not managed. This would cause release team to resolve the same CI issues across multiple environments. In due course if this is not persisted in CMDB, it gets forgotten till a major issue is realized later.
It’s often a good practice to identify CI and manage it in CMDB.
· Environments Verification
Environments Verification is a process where in Release Manager validates environments used across the broad spectrum of projects / team regularly.
It’s quite common that environments are allocated during planning phase to projects and over a period environments may not be required. Environments Verification process provides general housekeeping activities on environments and validates usage of resources / environments regularly.
Environments Verification process provides means for collecting metrics and providing feedback to management à
· Visibility and information to feed projects plan and delivery commitments such as what is available? When it is available?
· Data and metrics to calculate cost (hardware, software and people) & ROI as part of individual project and organisation as a whole.
· Measurement for utilization, productivity and costs associated with the resources.
· Informational data of what do we have and what we need or don’t need in future.
· Environments Communication
What needs to be communicated?
Who needs to know?
How to communicate?
It’s a common scenario where multiple environments share resources.
The resources could be physical/virtual servers, application servers, database servers, etc. Shared resources could affect environments functionality where in changes done due to releases / changes in external interfaces & networks could affect the behaviour / testing capabilities of other environments. Information pertaining to changes because of which environments are affected needs to be actively communicated.
The prime stakeholder for the environments communication would include à
o QA Teams
o Project Teams
o Release Team
o Operational Support Team
o Architect Team (Software / Infrastructure)
o Business Stakeholders
Release Managers also need to introduce communication medium where all the stake holders of environments have information pertaining to resources used by environments. Some common mediums through which information on environments is provided include à
o Environments Dash Board.
o Environments Usage Wiki.
o Environments Catalogue.
o Excel spread sheets, etc.
Conclusion
Environments are important in the release cycles of IT Projects. Environment issues in non-production environments can cause lost time on IT projects. Organizations should look at efficiently introducing and managing Environments Management Process. Environment Management improves quality, availability and efficiency of environments in order to meet milestones and ultimately reduce time-to-market and costs.
No comments:
Post a Comment