Introducing DevOps

For a long time, development and operations had been divided into isolated modules with both separate concerns and responsibilities. Developers wrote the code and made sure that it worked on their development systems, while the system administrators were responsible for the actual deployment and integration in the organization's IT infrastructure.

As there was limited communication between these two isolated modules, both teams worked mostly separated on their projects. However, they heavily depended on each other because there was no cross-platform knowledge across the different teams.

This fitted in nicely with the Waterfall Methodology that was used for most projects. The Waterfall Methodology is based on the Software Development Life Cycle (SDLC), which has clearly defined processes for creating software. The Waterfall Methodology is a breakdown of project deliverables into linear sequential phases, where each phase depends on the deliverables of the previous phase. This sequence of events may look as follows:

Figure 1.1 – Waterfall Methodology

The Waterfall Methodology is well suited for projects in the following circumstances:

• Early in the development life cycle, customers and developers agree on what will be delivered, with minimal to no changes during the development of the project.
• For integration with external systems, it is common for multiple components of the software to be designed in parallel. In these cases, it is desirable to have the design document complete at an early stage in the development life cycle.
• Various team members are involved in other projects simultaneously as well. For example, business analysts can gather the requirements and create the design while developers are working on another project.
• Where it is not possible to break down the requirements phase, customers are not fully engaged in smaller deliverables.

However, customers may not exactly know what their requirements are before they see working software. This can result in changing the requirements, thus leading to redesign, reimplementation, and reverification. This can dramatically increase the costs of the project.

Due to this, Agile and DevOps were introduced in 2009 and have slowly taken over the world of software development. They replaced the Waterfall Methodology for most projects that are out there. DevOps is a natural extension of Agile and continuous delivery approaches, and it stands for development and operations. It is a practice that merges development, IT operations, and quality assurance into one single, continuous set of processes.

The following diagram illustrates the different parts that DevOps consists of:

Figure 1.2 – DevOps methodology

It is a team-based and iterative approach to development where all stakeholders, such as developers, administrators, testers, and a representative of the customer, are part of the same team. Applications are delivered in functional components, and rather than creating schedules and tasks at the start of the project, the project is divided into smaller phases, called sprints. The duration of each sprint is defined up front and has a list of deliverables that are planned at the start of each sprint. All those deliverables are defined together with the customer and prioritized by business value by the customer. At the end of each sprint, when work is completed, it is reviewed and evaluated by the team through daily builds and end-of-sprint demos.

This results in the following advantages:

• By working directly with the project team throughout the whole project, the customer will experience a stronger sense of ownership.
• The customer has opportunities to see the work being delivered in an early stage of the project and can make appropriate decisions and changes to it.
• Development is more business and value focused. This is a result of working closer with the customer and having a better understanding of their needs.
• An Agile way of working enables us to quickly create a base version of the product, which can be built upon in the next iterations.

Now that we have covered a very brief introduction to DevOps, we are going to look at the different DevOps principles.