SRE perspective about CI/CD pipelines

SRE stands for Site Reliability Engineering

Why Code ?

You may think that “Coding” is done only by Development teams. However, this is not the case with company following SRE model.

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

BMW company realized that Code must be learnt by all departments even HR.

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

If we imagine that all departments start their changes from the Code, this is my perceptive about how CI/CD pipelines are orchestrated among all Codes written by all parties:

• 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