What is DevOps in SDLC?

What is DevOps in SDLC?

There are lots of opinions about what is covered under DevOps and what’s not. Is it a culture? Is it a job title? Is it a way of organizing? Or just a way of thinking? We think it’s a still-evolving movement so let’s not get stuck on limiting it too much right now. Instead, we can talk about some of the common themes, tools and ideas.

DevOps is a software development method that emphasizes communication, collaboration (information sharing and web service usage), integration, automation, and measurement of cooperation between software developers and other IT professionals.[1][2] The method acknowledges the interdependence of software development, quality assurance (QA), and IT operations, and aims to help an organization rapidly produce software products and services and to improve operations performance.

In simple words, DevOps means a software development method which stresses on communication, collaboration and coorperation between software developers and other IT professionals.

“Venn diagram showing DevOps as the intersection of development (software engineering), technology operations and quality assurance (QA)”

DevOps is the practice of operations and development engineers participating together in the entire service lifecycle, from design through the development process to production support. It is also characterized by operations staff making use many of the same techniques as developers for their system work.

The Perfect Storm of 2009.

A perfect storm of converging adjacent methodology including Agile, Operations Management (Systems Thinking & Dynamics), Theory of Constraints, LEAN and IT Service management came together in 2009 through a smattering of conferences, talks and Twitter (#devops) debates worldwide that eventually became the philosophy behind DevOps.

Agile software development paved the way, steering away from the waterfall method of software development toward a continuous development cycle. But it didn’t include the operations side so while development could be continuous, deployment was still waterfall-oriented.

In a DevOps environment, cross functionality, shared responsibilities and trust are promoted. DevOps essentially extends the continuous development goals of the Agile movement to continous integration and release. In order to accommodate continuous releases, DevOps encourages automation of the change, configuration and release processes.

DevOps tools.

The Agile Manifesto emphasizes individuals and interactions over processes and tools, but DevOps, while emphasizing collaboration and integration also looks to automation tools that can leverage an increasingly programmable and dynamic infrastructure from a lifecycle perspective. Version control and automating code deployments are two of the most impactful common tools but there are many more, including configuration management, ticketing systems, monitoring and provisioning.

Benefits of DevOps

Companies that incorporate DevOps practices get more done, plain and simple. They deploy code up to 30 times more frequently than their competition. And less than 50% of their deployments fail according to Puppet Labs 2013 State of DevOps survey.

The biggest shift in attitude in a DevOps environment is that there is one team composed of cross-functional team members including developers, QA, DBAs, business analysts,operations engineers and so forth. Collaboration across these different roles delivers many benefits.

Technical benefits:

• Continuous software delivery
• Less complex problems to fix
• Faster resolution of problems

Business benefits:

• Faster delivery of features
• More stable operating environments
• More time available to add value (rather than fix/maintain)

Practical Illustration from an entrepreneur

Gene Kim, a software researcher/ entrepreneur and one of the authors of the book “The Phoenix Project: A Novel about IT, DevOps and Helping Your Business Win”. In which he shares anecdotes about how Operations engineers work really long hours to keep production systems up and running.

Lesson 1: Business value of DevOps is undervalued.

Many leading technology providers, retailers, manufacturers, government organizations and higher educational organizations are currently using DevOps principles and practices and thereby increasing success rate and profitability.

To support the above fact, Gene shares the following statistics:

· The companies with DevOps do more frequent deployments with smaller changes and lesser preparation; they have higher lead times than peers.

1. 30 times more – frequent deployments
2. 8000 times faster – lead times than peers

· High performers are more agile and more reliable.

1. 2 times more – change success rate
2. 12 times faster – mean time to recover

· High performers win in the Marketplace.

1. 2 times more likely to exceed profitability, market share and productivity goals
2. 50% higher market capitalization growth over 3 years.

Lesson 2: DevOps is as good for Developer as it is for Ops Engineers

In 2008, for the rollout of Facebook chat, Facebook had been testing the messaging in production for over a year before they released Facebook chat for 98 million users, overnight, without a hitch. Testing in production with frequent fixes was proved to be successful for a large-scale rollout like Facebook chat.

Lesson 3: The need for high-trust management

In 2012 the company, Knight capital group, had a 15-minute deployment failure that caused 440 million trading loss and the company had to be sold immediately over the weekend⁴.

Two possibilities were reported for the failure:

(i) Change control failure

Change control team could’ve had quick detection of the failure and recovery mechanisms.

Management’s reaction:

Add one more level of approval authority.

Phoenix project’s take on this:

The number (levels) of approvers increases => implies or leads to => Deployment engineer or developer not empowered to take dynamic decisions during the deployment => multi million-dollar losses.

Resolution:

Considering the person doing the deployment knows the most about the code change, he must be empowered to take any dynamic decisions during the deployment.

(ii) Testing failure

Proper testing could’ve enabled earlier detection of the failure and prevented it from happening.

Management’s reaction:

Do more testing.

Phoenix project’s take on this:

More testing => longer development cycles => less frequent deployments => bigger chunks of changes in each deployment than before => deployments are more prone to errors.

Resolution:

Do the deployments more frequently, with smaller chunks of changes.

In most scenarios, management would disagree with the above resolutions because of low trust. Thus there is an imperative need to transform low trust organization culture to high trust where people are empowered to deliver software in safe environment.

Lesson 4: DevOps is not just for unicorns (Google, Facebook etc.) it is for horses, too.

Gene gives anecdotes of number of companies (other than the unicorns) that are using DevOps principles and thereby drastically reducing their lead-time from commit through testing through production deployment. Reducing deployment intervals decreases preparation time and technical issues, and increases product efficiency and customer satisfaction.

I will discuss on the DevOps lifecycle and other practical examples which illustrate improvised SDLC processes in my next blog.

References –

1. http://money.cnn.com/2012/08/09/technology/knight-expensive-computer-bug
2. https://en.wikipedia.org/wiki/DevOps
3. http://www.amazon.com/The-Phoenix-Project-Helping-Business/dp/0988262592

Best Open Source Business Intelligence Software Helical Insight is Here

A Business Intelligence Framework

Free
Download