SRE perspective about CI/CD pipelines

SRE stands for Site Reliability Engineering

Why Code ?

In a SRE model, any Change starts from the “Code”. Indeed, translating everything into Code allows you to leverage all benefits of Code:

  • Code don’t lie
  • Code is controlled by version control system (e.g: git)
  • Code is elegant, readable, maintainable
  • Code is tested & quality gates must be passed, hence, you have more confidence before the Change.
  • Code means bringing software best practices into your job and leveraging SDLC.
  • Code means Code-Review is enabled thru pull-requests, hence, risks (human mistakes,..) are mitigated before the Change takes effect
  • Code means you can continuously integrate your Changes thru CI/CD pipeline.

Now, you can confidently consider that your work is reliable.

Study Case

As consequence, BMW announced “Back2Code” as one of pillars for their DevOps transformation.

Do you think that they are learning Coding for the sake of tasting Software Engineering practices ?

Never neither, Codification approach is done for the sake of RELIABILITY.

In-Parallel CI/CD pipelines

  • All teams write Code
  • Code takes effect thru CI/CD pipeline.
  • Write Code, Push it, and Let systems talk with each others
  • All teams/All departments work on the same Story, even HR recruitment team.
  • Teams who work on global scope have to provide the software libraries ( Frameworks, Ansible roles, Terraform modules) proactively or reactively.
  • All teams delivers artifacts thru CI/CD.
  • Ideally, all artifacts can be unified by delivering container images with well customized entrypoints.
  • By definition, artifacts are immutable. Hence, reverting back to any version is possible.
  • Business analyst can join the QA team to write automated acceptance criteria directly thru gherkin/cucumber syntax“ (*.feature” file).
  • QA engineers checkout “*.feature” file, make it parametrizable and expand it with more scenario
  • Incident management looks like following: postmortem outcomes will be changed dramatically. Indeed, the list of actions will be either bug-fix in the playbook A, or hot-fix in Terraform file B. New Sprint is started and Sprint Backlog put hot-fixes

Software engineer, Cloud Architect, 5/5 AWS|GCP|PSM Certified, Owner of kubernetes.tn

Software engineer, Cloud Architect, 5/5 AWS|GCP|PSM Certified, Owner of kubernetes.tn