Definition

The subdomain of Software Engineering focused on deploying software quickly.

Simple as that.

Strangely, even though DevOps is a major buzzword in tech, many online struggle to provide a useful definition for DevOps. Take a look at Microsoft’s definition:

“DevOps is the union of people, process, and technology to continually provide value to customers”

That is not a precise enough definition to be useful. There are so many things that definition applies to, a lot of them totally unrelated to tech (think about it: Even a financial consulting company would fall under such a definition).

I can end the post here, but I would like to explain DevOps one step deeper, as well as explain why there is a need for DevOps and where DevOps falls relative to coding.

Great Rec for Computer Networking [Ad]

Why DevOps is so Useful

Let’s start with a problem. After a coder, or more formally an Application Developer (AppDev), writes code, she needs to worry about publishing her code as well. This is the problem of the Software Delivery Lifecycle (SDL).

There are infinite ways to implement the SDL. The worst of which (in terms of sustainability) is to manually take the code that was written, copy it to each of the servers that will serve the application, and run them all.

DevOps provides guidelines for implementing a more sustainable solution to SDL. The DevOps guidelines ensure code quality through automated tests and ensure application availability through mature deployment automation.

DevOps Guidelines

Below is the classic DevOps Lifecycle - a visual representation of the guidelines of DevOps.

The lifecycle looks like an infinity symbol because it symbolizes the fact that coding is meant to be a process that includes potentially endless revision.

Although this graphic makes for a good logo for DevOps, it does not provide any technical direction to a prospective engineer to figure out how DevOps works. I propose the following graphic instead:

After a coder commits her code, and the code is deployed to a development environment. If all goes well, she makes a pull request to a staging environment that contains a merger of work of many coders. If the DevOps process works for the staging environment (meaning everyones’ changes played well together), then it’s ready to be merged to production. After that, the only way more code is written is if there is a new software change planned.

Through this graphic: one clearly sees how version control and environments tie into deployment of an application.

The only thing the above graphic fails to capture is how exactly these steps are defined, and how automation ties into all this. So, how exactly is the process behind graphic defined?

The DevOps lifecycle is usually defined through a build process file, like a Jenkinsfile or a GitHub Actions file, which exists in the same GitHub repo as code does, and that contains a literal list of steps to take given the code in the repo.

Below is an abstraction of a repo that contains source code (src/), tests (tests/), as well as a build process file (cicd.yaml).

Build process files can take many forms, but my favorite are GitHub actions files (any file under .github/workflows/ in a GitHub repo). The steps defined in the build process file are ran by a build process executor, like Jenkins, or like GitHub actions runners (the details don’t matter, just know that alonside a build process file comes a build process executor).

Example of what a GitHub actions looks like:

on:
  push:
    branches:
      - main

jobs:
  test:
    steps:
      - name: test python code
        run: python3 -m pytest --cov-report xml:coverage.xml --cov=./tests
      
      - name: scan code for vulnerabilities
        uses: sonarqube
        with:
            report: coverage.xml    #scan file generate from above

  build:
    needs: [test]
    steps:
    - name: push to artifactory
      run: ...
  
  deploy:
    needs: [build]
    steps:
    - name: deploy to kubernetes
      uses: helm
      with:
        values_file: environments.yaml

  register_to_monitoring:
    needs: [deploy]
    steps: [...]

# This file is not a valid GitHub actions file, it's more of an abstract image of one.
# Pay attention to the files mentioned in the steps.

These graphics should provide a much more informative description of DevOps that not only explains the high level DevOps steps, but that explains how an example of a DevOps pipeline in terms that engineers will understand.

What is CI/CD?

I propose that CI/CD are simply labels for groups of steps in the DevOps process.

CI stands for the steps related to code, and CD stands for steps related to deployment. Put visually:

Final Remarks

Now that we’ve defined the relationship between DevOps, AppDev, and Software Engineering, let’s make some important clarifications:

• Software Engineering encompasses much more than only coding
• DevOps is a branch of Software Engineering
• AppDev is a branch of Software Engineering
• AppDev == Software Dev
• WebDev and Mobile Dev are branches of AppDev

A DevOps Textbook [Ad]

So what does this mean for your LinkedIn Bio?

• If you are an AppDev, write something like “Software Engineer - App Development”
• If you are do DevOps, write something like “Software Engineer - DevOps”.

Please share this post if you thought it was informative!