Mohapatras Release Management Blog

Environments Management – Key Component for Release Management

2011-10-13T13:26:00.000-07:00

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.

Release Team provides the services for deployment on the environments and making it available during various stages of release & test cycles.

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.

Release Management Definition and Responsibilities

2011-08-03T14:33:00.000-07:00

Release Management is very critical to delivery and maintenance of IT Services.

Yet over the last number of years, Release Management as a role has been something that has been the responsibility of Build Engineers managed by development teams or an added specialty for change management and in some instances handled by Project Managers.

ITIL has defined Release Management as one of its functional areas within Service Transition Process.

Yet there seems ambiguity over defined scope of Release Management across the wide spectrum of organizations.

Reviewing the goals / definitions of Release Management..

ITIL defines Release Management as ->

The goal is to deploy releases into production and establish effective use of the service in order to deliver value to the customer and to be able to hand over to service operations.

Techopedia defines Release Management as ->

Release management is the part of the software management process dealing with development, testing, deployment and support of software releases to the end user. The team involved in this process is referred to as the release management team.

I would define Release Management as..

"Release management is a software management process to efficiently build, deploy, configure, manage & support software releases across various stages of IT Delivery Lifecycle."

The goal of Release Management is to ensure that changes in IT environment are carried out in a controlled, tested ,approved ,accountable and measurable manner.

In a nut shell some of the critical responsibilities for Release Management include à

Build Management

Management of overall build process for an organization.

Define what constitutes build, build platform, build process, build artefacts, etc..

Build Management includes Setting Up Automated Build Process, Management of Source Control Repositories, Defining Build Strategies, Defining Branching / Merge Options, Management of Continuous Integration, etc..

Configuration Management

Defining CIs (Configuration Items) across hardware / software infrastructure.

Identification and management of various configurations across suite of environments.

Depending on maturity of an organization configuration management process would relate to setting up CMDB (Configuration Management Database), Automating Configurations across the phases of release, etc.

Change Management

Changes to software / hardware that could affect software being delivered are under the scope of change management under Release Management. Any changes in source code / configurations need to be managed across the release cycle efficiently.

The process of defining and management of changes (such as patches, emergency fixes,etc) that could affect live production service is owned by Release Management.

Deployment Management

Planning of Deployments across suite of infrastructure is one of the major responsibilities of Release Management.

Deployments could be a nightmare if not planned properly. Deployment Management involves understanding artefacts of deployment and it intended purpose, various configuration items related to deployment, physical and logical infrastructure that will be affected / involved, overall planning the deployment cycle, documentation of deployment process / rollback scenario, co-ordinations with various other stakeholder, etc.

Environments Management

Environments Management is one of critical functionalities that Release Management.Environments are critical to every organization.

Infrastructure Landscape / Definition / Complexity of environment varies across organizations depending on the product. Typical example of environments could include Developer Environments, where in developers could test their software, System Test environments for System Test Team, User Acceptance Test environments for UAT Team, etc.

What makes and environment ? How is it configured ? Who Manages the Environments ? Who Uses it ? etc., are some of the questions that Release Management provides.

What makes environments management even more critical is the fact that there could be finite number of environments. The aspect of co-ordination between various business users and responsibility of ensuring stability of environments are critical for Release Management.

Release Process Management

Release Scoping, Release Planning, Release Provisioning, Release Support, etc..

Release process definition is essential in order to understand the reasons for release & facilitate releases across for delivery of services.

Maturity of Release process for organizations vary depending on size of organizations and delivery models for implementing / provisioning releases.

In order for a Release Manager to successfully contribute across various roles as defined above, Release Manager is often required to wear multiple hats and he has to be a jack of all.

Release Management Team could be critical to delivery of IT Services and appropriate definitions of process across various stages of lifecycle of software are essential for success of Release Management