AND, I repeat: a DevOps Engineer is a CICD pipeline engineer. This post is my attempt to validate myself:

{{ the CI }}

A software developer (Dev) pushes a commit and calls it a day before taking their dog (or a cat) on a walk! A DevOps guy looks at the repo and the following checks and balances come to my mind:

Dockerfile := "Is the application dockerized?"

code _overage := "Is there any code coverage? (a.k.a. testing units)"

supply_chain_security :=  [2]string {
    "What libraries are being used/implemented?",
    "Are there any known vulnerabilities and CVEs?"
}

Importantly, is the code CloudNative?

CloudNative := [3]string {
    "Environment variables are soft-coded and not hard-coded",
    "Free from api tokens, auth creds, etc and others secrets alike",
    "refers to 'localhost://db:3306' vs. potentially breaking 'db.company.com:3306'"
}

For the application to be CloudNative, it MUST be containerized:

BaseImage := "What's the base image used?"
CloudNativeOptimization := [4]string {
    "How's the container build time?",
    "How's the build layer caching strategy?",
    "Is the container image Prod optimized (ie. dev dependencies and unused libraries gone)?"
    "redundantly: Are diagnostic tools and other unused OS packages removed from Prod image?"
}

Traditionally, I could slack the Dev and provide a feedback report. That will cause a "human factor" & "human emotion" involved. And hence, the friction between Dev and Ops. Instead, I would use DevOps frameworks and tools to promote a Higher Order of Patterns [HoPs] for the DevOps culture via a CI pipeline:

git_push := "block the MR/PR push if secrets and tokens are exposed"

code_lint := "validate the code format and agreed cultural standard"
code_quality := "SonarQube, etc"
DockerfileLint := map[string]string {
    "base_image" : "Slim.ai",
    "ImageSize" : "Production readiness",
    "ProductionReadiness" : "Leaner and cleaner image",
    "Security" : "Trivy and Tracee"
}

And, bring all these findings or metrics on a proper and efficient visualizing format that's good on the Devs' eyes! Then, the dev can curse at the machine, a.k.a. pipeline for blocking their changes (I don't care) or choose to stay away from an agreed-upon culture set (not my problem)!

{{ the CD }}

# Same applies to other deployment configs:
- Terraform and Machine Images (Packer, AMIs)
- Ansible Configuration as a Code
- Kubernetes manifest yamls or Helm Charts

• Continuosly deploy to production (after dev, staging, blah, blah)

• Monitor and gather metrics:

    ContainerStats := "run time, CPU/Mem usage"
    ClusterStats := "Node & Cloud Resourses metrics"
    UX_Stats := "Apdex"
    KPIs := "request/response/latency/availability"
  

{{ the SRE }}

Visualize all these in a grafana like screen. And, let the screen yell out your DevOps culture!

• You agree upon a set of KPIs, gather metrics around those to generate SLIs

• You agree upon a set of SLOs that generates a reasonable SLAs.

Hence, "a DevOps Engineer is a CICD pipeline engineer"

validated by and for -

{{ a passionately CloudNative DevOps Practioner }}