The Advantages of DevOps
Many software development organizations are embarking upon a reengineering of their teams and processes into DevOps practices. The goal of these practices is to build an automated workflow that enables source code checked into a repository to be automatically built, integrated, tested, and delivered into production. Software is delivered directly to the cloud, where it is immediately put into production use.
DevOps automates the software delivery sequence so that the time from code check-in to deployment can be measured in minutes rather than weeks or months. By using automation in continuous integration, continue delivery, continuous testing, and continuous deployment, DevOps makes sure that activities are done quickly and consistently. Team members work together rather than in separate functional organizations.
DevOps is a multi-faceted approach to continuously building and releasing software that upends traditional software development processes. The changes needed are technical, organizational, and cultural. According to Nicole Forsgren, CEO of consultancy DevOps Research and Assessment, “When we talk about what DevOps is, it is CALMS: Culture, Automation, Lean, Measurement, and Sharing.”
That’s a good starting point to address the difference between DevOps and traditional software practices.
Preparing for DevOps
First and foremost, DevOps requires most teams and their broader organizations to undergo a significant cultural shift. In a room where software engineers, testers, release engineers, and IT operations professionals are all working toward the same goal, organization boundaries are broken down and it becomes easier to focus on delivering software rather than managing interactions between functions. While there are multiple skill sets and roles on any team, who does an actual task may not be who you expect, but rather who is available. Everyone pitches in to support the application, without regard to primary skill or function.
This model represents a significant change from the hierarchical and functional organization that is typical in software development. Traditional teams are typically organized around function, with developers, testers, release, and IT all having separate reporting silos. That organization also gives them different and sometimes conflicting priorities.
DevOps focuses on the end product rather than any given functional area. Many organizations need time and training to become aligned with DevOps goals and to fully embrace them. The focus on the project goals, rather than the narrow functional responsibilities, is a significant shift in mindset for traditional organizations.
Automation and the Technical Side
The language is different, and to many, the process can seem alien. At a time where many traditional teams still release one or more beta cycles prior to a production release, DevOps teams are continuously releasing directly into production. To accomplish this requires a tool chain, a sequence of automated activities that occur within those tools, and a workflow that automatically passes relevant information from one stage of the process to the next.
While this sounds straightforward, every team’s DevOps pipeline is different. They may be using different repositories, such as GitHub or Perforce, and other tools, different programming languages, different checkpoints, different workflows, and different quality requirements and measurements. Code goes in, and deployed applications come out, but the path they take can be very different.
The unique nature of DevOps implementations means that every single workflow and toolchain are different. There is no “one size fits all” in DevOps. As a result, each team has to find its own way, based on its skill sets and application needs, and there are multiple tools and workflows to choose from as a starting point.
The other point is that customization means that the entire DevOps team should be clear on the goals of the DevOps process and workflow. Without team agreement, the workflow can be ambiguous or circumvented, causing a breakdown in the process. But with agreement and strong automation, teams know what is needed for the application, and work together toward that goal.
Lean and Mean
One of the goals of a DevOps process is to reduce the amount of time spent between development and delivery activities. Whereas you may have been building and integrating weekly or nightly, with DevOps a verified check-in to GitHub or other repository automatically triggers a new build and integration, along with smoke tests. This could happen many times a day. No significant time is spent between writing the code and knowing whether or not the build is a good one.
And the rest of the workflow is designed to get rid of similar inefficiencies. Little traditional testing is done prior to deployment, because it’s impossible to replicate the cloud-based production environment on a staging site. Instead, the practice of testing incorporates unit testing, smoke testing, and testing in production.
Automation not only lends consistency to the DevOps process but also reduces the amount of time it sits waiting for the next stage to occur. This is a key contributor to the ability of DevOps to deliver new software to production multiple times a day. Without automation and a defined workflow, code would sit in the repository without moving forward into production for long periods.
DevOps and Continuous Improvement
A hallmark of the DevOps movement is that the process, and the resulting application, can always be improved. That means measuring everything about the process and workflow to look for and address inefficiencies. The team only knows how successful it is by capturing metrics such as build frequency, build success, defects, performance, script failures, and other areas that objectively describe the process and outcome.
Teams will measure different things, depending on their tool chain and workflow, but the purpose of measurement is two-fold. First, measurement keeps an ongoing assessment of the health of the application and supporting infrastructure. Second, it provides a baseline and assessment for determining improvements to the process and workflow. If, for example, you are integrating once a day, you might need to investigate if your team is doing multiple check-ins without accompanying integration, and how to better align integrations with check-ins.
But without measurement, you cannot have improvement. What individual teams decide to measure is where they think is the most potential for improvement.
Where is the Sharing?
DevOps is more than a single team; it is a global community of like-minded professionals, with many publications and dozens of conferences for meeting and exchanging ideas. DevOps engineers and team members post and discuss both successes and lessons learned. Topics range from containerization with Docker to microservices to orchestration with Kubernetes to team dynamics and psychology.
The level of information sharing within the DevOps community is incredibly high for such a young and diverse set of professionals. It’s not unusual to see software architectures and scripts posted online for others to make use of.
Team members also share their expertise with each other. Specialty skills are not kept within a single function or individual. Team members may perform tasks outside of their areas of expertise, and learn new skills in the process. Despite having a primary skill set, team members work close enough together so that they develop complimentary skills.
All CALMS Ahead
DevOps is a journey defined by CALMS – Culture, Automation, Lean, Measurement, and Sharing. Teams are not only in different phases of that journey overall, but also in different phases of these five attributes. Successful DevOps teams need to make continuous progress on all fronts in order to deliver on the promises of continuous integration and continuous delivery.
Many organizations who find the DevOps model attractive don’t know where to begin. Others may have certain skills that contribute, but lack critical experience in DevOps engineering. Some may have existing applications that they want to move to a cloud computing environment with a minimum of changes, while other may be starting an entirely new application. In the latter case, usually they want to immediately move into a DevOps model and deploy directly to the cloud.
Experienced software engineering outsources like Kanda Software can help fill any of these roles, from providing critical skills to working on an entire application. Our experienced DevOps engineers can quickly determine the right tools and approach for your business, and implement a DevOps plan that works for you.