DevOps Class: Understanding DevOps Pipeline and Terms

7 min readOct 3, 2020

Shed some light on the confusing concepts in DevOps pipeline.

With the technological advances in the world in many development companies, the need arises to release features quickly while complying with a certain pre-defined outline. People expect to see the latest version of each app once work on it is complete.

To keep up with customers’ requirements and demands every development company needs to have an effective DevOps pipeline.

Here, we will cover all the important concepts of a DevOps pipeline, how pipelines work in DevOps environments and explains the stages has to pass through before being deployed to production.

What is DevOps?

One of the well known academic definition is: “a set of practices intended to reduce the time between committing a change to a system and the change being placed into normal production while ensuring high quality”.

Or in our language: DevOps is an IT organizational methodology where all teams in the organization, especially development teams and operations teams, collaborate on both development and deployment of software to increase software production agility and achieve business goals.

Agility: focusing on user feedback, software quality, and the ability to respond quickly to changes and new product requirements

What is a DevOps pipeline?

A DevOps pipeline contains a set of stages, which are under the responsibility of the development (Dev) and operations (Ops) teams.

“DevOps pipelines work like an assembly line”

First Stage: Plan

In this stage, product managers and project managers play an indispensable role. They plan out the entire workflow before developers start coding and create a roadmap that will guide the whole team along the process.

After receiving feedback from users and stakeholders about the plan.
The practical work is broken down into a list of small tasks that are addressed to each team member individually. Every day, there is an event called “daily” that allowed the team members to speak about their task and how it goes (this event can happen every second-day or every week depends on the team’s decision)

To increase the agility even more, teams work in sprints.

Sprints: a shorter period of time during which individual team members work on their assigned tasks.

Second Stage: Code

At this point, the developers start coding. To ensure uniform coding, all developers have to follow the same code styles and standards. Plus, it can be much better if they will use the same IDE’s or code editors.

After completing a coding task, the writer should create a pull-request to share changes with the remote repository. Another developer (preferably a senior) will check the new changes and merge it with the master branch by approving the pull-request.

Recommended tools for those two stages are Gitlab, GitHub and Jira.

Third Stage: Build

Here, developers are getting the chance to detect errors in their code before it proceeding in the pipeline. Once a developer submits his code, the build starts running and a series of end-to-end, integration and unit tests are running in the background too. If one of the tests is failed, the whole build is failed meaning the pull-request has failed too and the submitted code has to be fixed by the writer (the developer is notified about that).

So, this stage is very important because that is how the developers can be sure that their code doesn’t lead to errors that might cause the app to crash.

Note that this stage isn’t relevant for those who use an interpreted programming language like Python.

Fourth Stage: Test

After the build stage had occurred, the code automatically deployed to a staging environment for deeper testing. The test environment can be an existing hosting service or a new environment design for testing.

Recommended tools for Build and Test stages are Maven, Gradle and JUnit.

Fifth Stage: Release

Now, the developer can say his build is ready for deployment into the production environment. The release stage can take many forms, for instance, the team (or the organization) can determine that the code is automatically deploying by schedule or by every successful build that makes it to this stage of the pipeline.

In addition, the team may decide that the release is a manual job.

“Releasing without running a build-task, It’s like harnessing the cart before the horses”

Sixth Stage: Deployment

Rock N Roll, the build is finally ready and it is released into production. Note that if there is any problem with the newly released features, there should be an option to revert to an older version.

Recommended tools for Releasing and Deployment stages are Ansible, CHEF and Jenkins.

Seventh Stage: Monitor

The last stage of our chain is the one that monitors the environment. It provides analytics and data about the users (customers) behaviours and their performances. All of these are part of the feedback that the Product Manager and the Project manager need, after all — ” There is no test like production”.

This is how the pipeline suppose to look like:

Continuous Confusing ?!?

Many of developers are using CI/CD as an acronym for modern deployment practices. Let’s expose those shorthands and extend them too:

Continuous Integration (CI)

“A software development process where a branch of source code is rebuilt (and retested) every time code is committed to the source control system”.

The motivation for this process stems from one of the biggest problems in team development (especially when working on the same piece of code): changes made by one developer can impact what other developers work, what’s lead sometimes to conflicts. So, by merging smaller changes more regularly, these issues become smaller and easier to manage, improving overall productivity. CI takes care for this by its practice, it is merging a developer’s code into the centralised codebase and conducting automated testing to ensure the code is fine.

Another interesting definition called: Continuous Quality (CQ), which takes place especially in Continuous Integration (CI) — “CQ reduces the risk of security vulnerabilities and software bugs by helping developers find and fix problems as early as possible in the development cycle”.

Continuous Integration (CI) aligns with the Code, Build and Test stages of the pipeline

Continuous Delivery (CD)

Continuous delivery is an extension of Continuous Integration (CI) to make sure that the developers can release more often and quickly their new features. This means that the developers also have the ability to automated their release process and they can deploy their application by “clicking on a button”.

What really amazing in this approach is that the developer can release his new features whenever he wants to and he doesn't have to spend days preparing for a release.

Continuous Delivery aligns with the Code, Build, Test and Release stages of the pipeline

Continuous Deployment

This one takes Continuous Delivery (CD) one step ahead. In Continuous Deployment, every change that passes all stages and balances of the production pipeline is automatically released to the users.

What really astonishing in this approach is that every finished feature go live in no time (in minutes) after the committing. So, the users can see a continuous stream of improvements and if there is a bug, it is likely much easier to fix.

It’s important to understand that the developers testing culture needs to be at their best, meaning the test stage (we saw earlier) plays an indispensable role. Their tests will define the goodness of their releases.