Agility Throughout the LifeCycle: The Rise of DevOps

lack of outages (which often means resisting change). It is important to break down the “Great Walls of Ire” as Brad memorably put it!

This means improving global communication, and thus co-ordination. Make sure that new releases are not a surprise to operations – sprung at the last minute.

What are the Constraints for Dealing with Releases
Even if the software team doing the development and support of the tool(s) has the ability to release & deliver frequently, the organization (enterprise) may not have the capability to assimilate release as frequently:

• Some deployments/upgrades may require downtime of business-critical systems or unavailability of business-critical repositories and databases, and the business simply cant tolerate that kind of disruption as frequently or during crunch-times of any particular business-product that uses the tools

• Some software changes go hand-in-hand with some corresponding process-change and/or organizational change to the business, and the customer organizations cant begin utilizing and realizing the value of your latest software/tool changes until they have made the necessary organization & process changes (which means many of us also have to become organizational change agent/experts in addition to process & tool experts)
• Any one of many other existing business-critical systems or IT assets which are needed for the deployment of your tool (or its users) may have critical dependencies or "freeze periods" making it difficult to deploy new releases of your own tools as frequently as desired.

By improving your communications you become aware of and deal with these issues.

Reducing Risk
Big bang releases are typically much riskier than smaller more frequent releases. If too much has changed as part of a release then the cause of any problem can be difficult to determine. In such situations you may have to roll-back the complete release, including lots of totally innocent and very useful changes!

Don’t Forget Testing and Environment Management
Lurking between development and operations is usually a testing and integration phase. Changes are tested in pre-production environments which supposedly are a copy of production, but in many cases are subtly or no-so-subtly wrong.

I have been working with one client recently who recognise the problems they have in this area. Testing is a large bottleneck for them, and this is mainly due to poor deployment and environment management. It typically takes hours and sometimes days to get an environment into a situation in which they are actually able to test the new change reliably. With multiple testers being involved, conservative cost calculations showed 6 figure sums being wasted yearly.

In this case we have started with an environment audit tool to be able to show what is in the current environment and how it differs from what is in production. It is then a relatively small step to being able to automatically deploy a new environment directly from their repository.

Designing for Release
You need to consider the requirements for release at the start of your development: the use of some new piece of technology may ease development significantly but can cause major problems to the new functionality being deployed. These days this is a lot easier for many companies whose business involves customer facing web sites. The servers and technologies involved are rather more homogenous and subject to central control – you only have to update your server(s) to have all customers using the new version. Life can be considerably harder where you are releasing products, coping with the deployment of fat clients and multiple client operating systems, and also having to support multiple versions of your system at the same time.

Increasing Automation
This means automation throughout the lifecycle.