What is DevOps? Waterfall to DevOps 2.0

Intro to DevOps:

Technology is the tool we use to face challenges in this new digital world; adapting staff, processes and tools to take advantage of new methodologies and platforms, in turn boosting our bottom-line.

DevOps is one of the most frequently talked about, agile solutions that enables application development teams to meet the needs of today’s digital businesses.

Anyone that's heard of DevOps knows that it improves organizational productivity, software quality, and the security of business applications.

But how? And where did this movement begin?

In the beginning… there was Agile

Actually, let’s take a quick step back.

The software development lifecycle (SDLC) was originally the brain child of 1960’s and 1970’s developers and used what we now call the Waterfall Methodology.

In the waterfall methodology, depicted below, there are a series of defined phases which each step down, one from the other, from project start through project end.

There is no overlap of effort, no way to save time on your development, and no way to see how your software is really turning out, until you are near the end of the “waterfall”. 

The process was not designed to return to a previous phase, so issues weren’t found until late in the game and became extremely costly to correct.

This process created silo’d efforts where documentation was required to share information between disparate teams that worked on the project sequentially, creating separate efforts, that don’t lend themselves to a single cohesive joint effort.

‍

This environment created situations in which:‍

The inflexibility and cost of working in a waterfall environment can’t support the drivers that business’s face today – Agile methodologies can.

Back in 2001,  in the ski lodge at Snowbird in Utah the Agile Manifesto was written. Shortly after Agile methodologies became all the craze.  

Everyone was jumping on the bandwagon trying to find out how this innovative approach to analyzing, developing, testing, implementing and managing the software development lifecycle (SDLC) could help them solve their old problems in new ways. 

Agile had a few goals which aligned well with the direction that business was taking:

The following chart shows one sample of how an agile process can work.

Notice how the steps haven’t necessarily changed, although they can be simplified with teams working more closely together, but the relationship between them is no longer one way.

The feedback loops which continually feed data between the Design, Implement, Test and Deployment teams allow feedback for each feature or element to be collected from the entire team within a cycle, rather than requiring the start of a completely new communication stream to feed information back each silo’d team.

There are many assorted styles of Agile that have emerged since its inception.

Rapid development using Agile practices has flourished with many of them – Scrum, Lean Development, Kanban and Extreme Programming (XP), for example – supporting the development teams.

But the Agile development groups weren’t working with the Software Testing and Operations groups who continued to work in more traditional silos and methodologies.

‍

Agile is good... But DevOps is better

DevOps was born from the Agile movement in 2009.

By this time, the concept of Continuous Integration – developers integrating code into shared repositories multiple times per day – was moving closer to mainstream Development teams.

Continuous Integration promotes the use of automation tools that create a build, which is then verified, allowing teams to detect problems early in each cycle.

But this automation and sharing of information, didn’t extend to the testing or operations teams.

DevOps started with a search for a solution to a common and persistent problem.

Imagine a Senior Software Consultant working on a large project including Development, QA (software testing), and Operations teams.

He struggles with getting the groups to work together.

They each have their own processes none of which dovetail into the others.

The effort involved in merging the processes and methodologies of the “Dev” and “Ops” groups, creating a smooth and efficient flow of information,  led to Patrick Debois coining the term “DevOps” and gave rise to the DevOps movement.

By 2012 DevOps was a major buzzword and supported by DevOps Conferences around the world.

Prior this movement, development teams oversaw the gathering of business requirements the application and wrote code.

Then the QA team tests the program in an isolated development environment, confirms that all requirements are met and releases the code for operations to deploy.

Each time a software program is “thrown over the wall” to the new team, bottlenecks are created, and information is potentially lost.

DevOps addresses these challenges by establishing collaborative cross-functional teams – teams that share the responsibility for developing, preparing and maintaining the software and system.

‍

What is DevOps really?

It isn’t a fixed methodology or process. It’s a community of practices focused around a mindset and a set of principles.

DevOps encourages communication, collaboration, integration and automation among software developers and IT operations to improve the speed and quality of delivering software.

DevOps advocates Damon Edwards and John Willis described DevOps in 2010 with the acronym CAMS (culture, automation, measurement and sharing.

Each of these elements lends themselves in a crucial way to the success of DevOps in any enterprise.

1. Culture

As you know, DevOps is a cultural undertaking. 

It’s more about fostering a safe environment for productivity and innovation, than about embracing new tools and practices.

It’s about changing the way that we manage teams, and interdepartmental communications.

It breaks down the tribal managerial styles that we have traditionally embraced and replaces it with an environment that rewards and supports inquisitive minds and solution focused thinking.

2. Automation

Automation in DevOps is for more than productivity gains.

It’s about saving time, yes, but it’s also about preventing defects, improving consistency, and enabling a self-service environment that opens up opportunities for innovations.

3. Measurement

Continuous improvement must be measured- how else do you know if improvements are being made?

Measuring and integrating feedback is a fundamental part of agile and lean practices.

Start with sharing the measurements of critical points that map to business outcomes — for example, deployment frequency, lead time for changes, mean time to recovery (MTTR), change fail rates, etc.

Basing your decisions on data, rather than impressions, allows you to create a blameless plan for improvement.

4. Sharing

Through shared knowledge, tools, discoveries, and lessons, DevOps creates a sense of collaboration amongst disparate organizational teams, and allows for new discoveries, reduction of duplicate efforts, and a keen sense of engagement within the business. 

This works not only within the organization, but outside of it as well.

The benefits of contributing to open source projects, talking about your experiences at conferences, and writing public blog posts shows pride in your team’s work, as well as opens dialogue with individuals whose ideas and experiences can benefit your organization.

‍

DevOps Biggest Impacts

DevOps impacts services across your business.

The direct changes created by allowing your development teams to focus on standardizing their development environments and automating delivery processes, improves delivery predictability, efficiency, security and maintainability.

Its ideals improve developer control of the production environment and an integrated relationship with production infrastructure operations.

DevOps empowers functionally joined teams with the autonomy to build, validate, deliver and support their own applications -  nothing gets “thrown over the wall” anymore.

The cultural changes which are driven by the DevOps movement are potentially more impactful for a business than the change in process.

Teams, including developers, testers, analysts, and operations, come together at the start of each major cycle (Sprint in Scrum) of a project.

These teams work together through each task, with every member adding their knowledge and specific skills to the task at hand.

Each member of the team has direct influence over the end results, and clients see the results of the work quickly and can give feedback. These teams are more productive, and the quality and security of your deployments is improved.  

These joint teams are more responsive to the needs of your business, and more quickly innovate solutions the better your business as a whole.

In a recent review of the 2017 State of DevOps report, issued by Puppet and DevOps Research and Assessment (DORA), it was discovered that the full integration of DevOps methodologies to build a high performing team improve business performance and responsiveness:

As the cultural changes have become more prevalent, both commercial and open source software is available to support these efforts, yet again improving the productivity of your development, testing, and operations efforts.

DevSecOps is better yet…

One of the items that is still overlooked in a DevOps environment is security.

The goal of DevSecOps is to introduce security earlier in the application development lifecycle, thereby minimizing vulnerabilities, and integrating security into the responsibilities of the entire development and operations teams.

Security is embedded in every part of the development process with core tasks being automated, as shown in the image below.

DevSecOps integrates security at the code level.

Practitioners of this methodology think of Security as Code, using an iterative approach to code releases, with aggressive automated testing tactics that strive to look at the loopholes and weaknesses that scanners may not catch.

This approach incorporates developers, testers, operations and security practitioners as a single team, with a single goal, which gives the team the power to remediate actions, instead of passing off lists of problems to the next team.

‍

High Performing DevOps Teams

Each business has its own goals and its own internal requirements, so “high-performing” may be determined, not by standards, but by your internal needs and concerns. 

The most basic level of DevOps uses the Continuous Integration (CI) approach touched on earlier, but for most high-performing teams (one of the goals of DevOps), achieving Continuous Delivery (CD), and /or Continuous Deployment (CD) of their software is nirvana.

And what about DevOps 2.0…

DevOps 2.0 takes the lessons learned with merging Development, Testing, and Operations teams, and extends that communication, collaboration, and continuous integration to the entire organization.

Through the reduction of process inefficiencies, the adoption of new tools, and making changes to the architecture of the business, the silos created between the development team and the marketing, sales, and business functions are also removed.

In this next phase in the development of DevOps, sometimes referred to as BizDevOps, the feedback from end users is integrated back into the development cycle quickly.  

This is done by using agile methodologies to decouple the selection of features from the operations team, and in turn base them on the business rules and goals.  

One implementation of this is to allow Marketing and Sales, who have the most direct contact with customers, to identify the features and functionalities that are important to the end users, which will therefore have the most impact to the company’s revenue generation.

 Using this approach, combined with one of the guiding principles of Continuous Deployment, the feature changes are rolled out to limited numbers of users in multiple phases.

Having the ability to turn a feature on or off, gives development and operations the ability to quickly reverse changes and make corrections, or push a feature to more individuals faster.

The goal of DevOps 2.0 is to sit alongside your standard Continuous Deployment efforts – so that turning on and off features isn’t dependent upon the development teams, and therefore doesn’t interfere with the current work of those teams.  

Corrections to the features can then be prioritized and scheduled, or simply not rolled out to any additional clients until such point as the development, testing, and operations teams can address any issues.

For this process to work well, real-time analytics must be implemented into the overall system which allows for the tracking and monitoring system performance.  

This allows operations to track any degradation to the system and track it to the specific feature release for correction or immediate disablement.

Conclusion 

There are a variety of options for implementing DevOps in your organization, and no single way to accomplish it. Your DevOps journey will start with a commitment to one of the Agile-style methodologies.

Astadia provides an assessment service, which can advise you on your journey. As you move toward a fully mature DevOps environment, your goal may be full automation of the software life cycle, focusing on achieving minimal human intervention after the move from coding through deployment.