The Essential Guide to DevOps Process Flow

The words DevOps Process Flow refers to the continuous momentum achieved using the blended functional pipeline activity performed by a dynamic team. The team will typically be made up of solution architects, programmers and testers, plus other key roles. There are of course distinct activities which drive any substantial delivery. There are 8 core stages to a successful DevOps.

First Stage: Planning

Planning is vital to get a view of intentions from the outset, to decide what is intended to be delivered, what the perceived benefits are, what types of resource are needed, how & when the benefits can be achieved. ‘Benefits’ being the overall intended aim(s) for your target delivery. Some organisations have calendar periods where deliveries need to accommodate other activities, such as audits, month end, year-end, high holiday periods, dependant deliveries or live release dates that have already been published etc.

It's imperative to keep a focus on priorities & the end results to ensure everyone is only engaged on activities which add value and bring you closer to achieving those results. Continuous value-add momentum is at the core of DevOps, which helps avoid wasted time, delays, and under-utilised resources. Close contact helps shared awareness and understanding. These two elements alone help save costs and time whilst delivering a higher quality result.

It's invaluable to produce a high-level roadmap to have an overview of the timeline and targets because it supplies a measure of progress against plan and can also serve as a guide for future planning. It's an effective method of sharing timeline targets and expectations. There must be some form of business or customer requirements – understanding these is critical to go about delivering them.

Specifically, the test function must be able to test these. Jira and DevOps are commonly used to record and support these but there are many different tools available on the market. These tools can enable tracking of work items like Epics (High-level task management), User stories (functional benefits), Features (solutions to requirements), issues, etc.

Second Stage: Coding 

We need to consider where we code. The coding stage is quite exciting because that's where the first parts of the work are developed. Daily stand-ups, collaborative sharing of ideas, airing of issues and problem solving are all key to progressing the delivery and help to support a shared level of awareness, consistency and understanding of build state. The test function actively participates here to better understand what is being developed, the technology challenges faced and how they prepare for testing.

Third Stage: Building 

Building is where the next exciting developments occur where the first draft of the product becomes available. This can be shared in a multitude of ways for diverse kinds of review by a subset of people in parallel. This way user/technical/non-technical peer reviews can find a variety of issues early in the process which saves money and a great deal of time, producing a higher quality output. Test data and environments in which to test the built solution come into play. There may be external interfaces that can only be simulated (at this stage) or harnesses that need to be built in order to drive exposed interfaces.

Fourth Stage: Testing 

Testing, one of my favourite stages, which should come as no surprise! This looks at exploring the code version deployed to a shared staging area, we call an environment. The environment is a space which has restricted access and allows work in progress and draft coding to be explored.

Once code is available for us in the testing environment, we can run a series of manual and automated testing runs to find issues such as defects in code, anomalies, measure of quality, design or system behaviour expectations.

Fifth Stage: Release 

The ‘release stage’ is when the compiled code and the actions from the pre and post activities are posted to a production environment. The technology exists so that developers can limit the release so that a subset of people, systems, locations can receive the updated code base. We can hide certain features and implement a staggered delivery if needs be where restricted function can exist and be used with new features. If not all features are ready then those that are not ready can be hidden from view so they are not accessible until they are ready. This all needs to be tested. The release team decide how and when the builds are released into production. Release notes, operational and release related documentation is compiled and shared to the target audience & user community.

Sixth Stage: Deployment 

The sixth stage, the Deploy stage is where the full code is released into production and rolled out to all users. Cost benefits begin to be realised over a given period for successful DevOps operations.

Seventh Stage: Operation 

This stage is where the software product(s) are used in a real live commercial environment. Preparation will have been considered to scale-up and accommodate peaks and troughs in the live system. Usages are managed and resources are available to address any operational concerns, technical system or network-related issues. Data is captured to understand real trends, usage, customer and system behaviour for feedback and follow up as needed.

Eighth Stage: Monitor

A vital stage to adjust the DevOps process via monitoring and feedback channels. The key points of DevOps are to deliver faster higher quality code as a team effort via collaboration, understanding objectives, sharing ideas / queries / blockers / expectations and working in parallel, to closely prioritise and optimise productivity. Testing is a key activity as it ensures the quality criteria have been met and that the user experience is central at all times. 

This is more achievable in DevOps as issues are shared and more people can suggest solutions. Work packets can be juggled according to known blockers and delays, reprioritisation and so on. As a direct result of close-knit working, we can expect answers much more quickly due to the regular progress daily stand-ups.

DevOps also supplies an ideal environment for closer working relationships and a clearer understanding of dependencies faced by each functional area. The DevOps process flow is continuous and therefore enables the product to evolve until it is no longer needed or superseded. The process however lives on and as it is refined it can continue to be applied to other products.

This is where we can help, with a wealth of experienced and professional resource!

White Paper

Our white paper 'Demystifying DevOps vs Agile' investigates the benefits and challenges of adopting DevOps strategies. It will cover top tips for optimising DevOp performance in order to help organisations understand the changes necessary to realise the benefits of DevOps without compromising on quality or delivery schedules.