How can we achieve top in class development to operations solution lifecycle that slashes operational outages and, at the same time delivers changes at an even faster pace?

During Part 1 I articulated the key DevOps building blocks – people, process and tools. During Part 2 I stated the key challenges that are appartent when trying to implement DevOps type capabilities. In Part 3 I will provide more views on the process principles, the environment reference model and the key environment related characteristics.

As discussed in Part 1, the entire development-to-operations lifecycle must be seen and operated as one coherent end-to-end process, rather than numerous multiple and diverse steps. Individual methodologies can be applied for individual steps – such as agile or waterfall – so long these can be connected together to form one end-to-end process.

‘Connect’ is a key aspect here. For organizations located across diverse geographies, change is global. Application development is being increasingly carried out in remote locations. Unit code as well as non-functional testing, interface and user acceptance testing, and end user training are also executed in diverse locations. However, a commonly agreed development-to-operations lifecycle is deployed.

A feedback loop runs from the live environment to the start of the cycle. Constant improvement to DevOps is an important facet of the lifecycle, and it requires these:

Instrumentation – Allowing more specific measures to be captured which are meant to be used as insights into future developments

Part of the process definition is to have a clear understanding of these three elements:

1) Principles and purposes

To deploy a common development-to-operations lifecycle one requires a clear definition of the key process principles and purposes. The development-to-operations lifecycle:

is necessary to build, test, and deliver the changes to existing applications or the implementation of new applications

plays a crucial role to manage the large volume of change associated with a multi-platform environment

provides traceability of change processes from requirements to release without any disruption Provides a single version of truth as end-to-end traceability ensures that the operations team implementing the application change has a solid understanding of the requirements. Enables a strong foundation to understand the requirements and ensures adequate validation during the integration or acceptance-testing phase of the release.

2) Environment Reference Model

Subsequent to understanding the DevOps lifecycle principles, it is crucial to define the use of various environments needed to support the different steps.

To achieve this, the characteristics and type of data, SLAs and the amount of change and release management must be clearly outlined:

Although these environments are not exhaustive, they constitute a list of possible environments and should be seen as a reference model. Once the DevOps implementation approach is in place, a decision to choose the right type of development and testing environments should be taken following a thorough analysis of the business operations. After choosing the type of environments, the IT department has to decide upon the data residency. Data may reside either on local servers or in a private or public Cloud environment.

3.) Environment Key Characteristics

Each environment is expected to have the following characteristics:

Part 4 will focus on the implementation of DevOps. Thanks for reading.

This blog post is the personal view of the author and do not express the views or opinions of Capgemini.