DevOps Explained

In this blog we talk about DevOps, the common technologies and methodologies used, what DevOps can be used for and how it is implemented. 

What is DevOps? 

DevOps is a practice that involves Software Development and IT Operations working closely together throughout the development process. The collaboration of these two teams focuses on rapid deployment of reliable software products. 

The Origin of DevOps 

The term DevOps was coined by Patrick Debois in 2009, describing a practice which was designed to break down the barriers between developers and operations teams.  

Traditionally, developers are focused on delivering changes and new features, and operations teams care about reliability and performance. A more unified approach allows teams to communicate better, share responsibility and ultimately build better services for the customer. 

The Four Key Parts of Dev Ops 

The four key parts of Dev Ops are: 

1. Agile Methodology 
2. Continuous Integration / Continuous Deployment 
3. Infrastructure as Code
4. Git 

Agile Methodology 

Agile is an iterative software development approach that helps teams work faster and easily adapt to new changes.  

There are several different agile frameworks, such as 

• Agile Scrum Methodology 
• Lean Software Development 
• Kanban 
• Extreme Programming 
• Crystal 

• Dynamic Systems Development Method (DSDM) 
• Feature Driven Development (FDD) 

Fundamentally Agile is a way of dealing with, and succeeding in, an uncertain and turbulent environment. Agile is more than just a framework and more than just practices such as ‘stand-ups’ and ‘sprints’. It is defined in the ‘Manifesto for Agile Software Development’, which was released in 2001 and has “12 principles” at its core. Fundamentally, Agile Methodology is the idea of small, frequent, improvements.  

The Waterfall Development Model 

Agile replaces the previous methodology of ‘waterfall’ development. The classic ‘waterfall’ software development model was invented in the 1970s and was revolutionary for its time as it brought discipline and focus to the software development industry. It was based on the waterfall manufacturing method derived from Henry Ford’s 1913 assembly line innovations. Each step is clearly defined, and the requirements for the project are defined at the start of the process. 

You start at the top and work your way down with each step flowing into the next. Each step is completed and once you reach the bottom you have a piece of software ready for release and maintenance that meets the requirements that were set out at the start of the process.  

But this methodology has its problems. It is complex, subject to delays, can be stalled by problems or issues, and isn’t responsive to evolving requirements. It also requires meticulous and extensive planning. 

Agile Process 

Agile is a process a team can use to manage a software development project by breaking it up into several stages and involving constant collaboration with stakeholders and continuous improvements at each iteration. 

It is focused on delivering working software, frequently. Changing requirements are embraced for the client’s competitive advantage. Developers and business people work together throughout the entire project. Working software is the primary measure of progress. 

The diagram shows the continuous process, that is repeated several times to produce a finished product. 

The diagram above shows what ‘scrum’ would look like. The project would be broken down into several ‘sprints’. Each sprint would be for a fixed time, so has a clear start and end date, and has a specific sprint goal. Quality must be maintained during the sprint.  

There are meetings called ‘stand-ups’ during the sprint for information and progress sharing, as well as highlighting issues. The scope of the sprint can be clarified or renegotiated between the product owner and the development team as more is learned during the sprint. 

Continuous Integration / Continuous Deployment (CI/CD) 

Continuous Integration is a coding philosophy and set of practices that allow development teams to implement changes to software code and to ‘check-in’ those changes frequently into a code repository. 

Continuous Deployment automates the delivery of the software to the infrastructure where it will execute. Taking the idea of small frequent changes from Agile, CI/CD focuses on how to deliver those changes. With the emphasis of CI/CD on the automation of integration, testing, and deployment. 

As much of the lifecycle as possible is automated to make the update, testing, and release of software as simple, easy, and fast as possible. Smaller and more frequent changes allow problems to be noticed earlier, isolated quicker, and fixed faster. 

This diagram below shows the continuous CI/CD process and the clear influence of the Agile Methodology on this process. 

Infrastructure as Code (IaC) 

The idea of IaC is for managing and provisioning data centre infrastructure resources through machine readable definition files. This replaces physical hardware configuration, or interactive configuration tools. These definition files can be stored as if they were source code in a version control system. 

Not only does it make deployment easier, it also means that it’s very easy to have a testing or reference environment that is identical to your production environment. This allows DevOps teams to test software in production-like environments early in the development cycle. 

Doing this is trivial if you use IaC and is indeed how most cloud environments are deployed. IaC also allows infrastructure teams to validate and test production environments, including making any rectifications or changes to the definition files as part of the process. These changes can then be fed back to the software development teams for use in future testing. IaC reduces risk and increases speed in the deployment of an environment. 

IaC tools were originally designed on one of two methodologies – push and pull. This determined the way the item being configured acquires its configuration. Push method tools have the controlling server push the configuration to the device and pull have the device request its configuration from the controlling server. Each method has pros and cons for different use cases.  

This has been recognised by the creators of some of the tools, and new versions have been released that allow push or pull methodologies to be used, depending on requirements. 

Git 

Git is an open-source version control system. Created in 2005 by Linus Torvalds and widely adopted by organisations large and small. It is a framework for managing, tracking, and approving changes to technical documents, usually source code or configuration files.  

Specifically designed to be a distributed system that can support many users and has strong safeguards against corruption (both accidental or malicious). Originally developed by Linus Torvalds to manage the Linux Kernel source code. An open-source project that has since had many developers contribute to and maintain. The exact source of the names is unclear, ranging from a random three letter name not used by other UNIX commands, to “Global Information Tracker”. 

Git is most often the version control system of choice for DevOps and can be used to hold source code for CI/CD, as well as IaC configuration files. 

DevOps Pipeline

A DevOps Pipeline is an implementation of all the DevOps processes, tools, and methodologies used to allow developers and IT operations to build, test, and deploy software faster, more easily, and to higher quality. 

This is the actual toolset and practices used for a specific project, it can also be codified as a run book into a cloud provider’s pipeline services such as AWS’s “CodePipeline” or Azure’s “DevOps Pipeline” to tie all the tools and services together. 

DevOps Lifecycle 

DevOps has become a crucial part of most engineering organisations. It influences every phase of the application development lifecycle, where no phase is independent of the others. Each individual in development and operations is involved in nearly every phase of the project.  

DevOps Business Benefits 

There are many Business Benefits for DevOps: 

1. Improved customer experience and satisfaction 
2. Improved operational support and fast detection and fix of issues 
3. Standardised deployment processes for faster delivery 
4. Improved quality, reliability, and reusability of system components 
5. IT staff have more time for innovation and higher rates of success due to automation 
6. Better internal communication and reduced silos 

Techbuyer has a large team of technical experts who have a wealth of knowledge about all aspects of IT and will take the time to fully understand your business goals and challenges to offer the right solutions for your organisation. Find out more about Techbuyer Enterprise Solutions here.