9 — CICD, Deployment Workflows & Observability

CI/CD, Deployment Workflows and Observability Engineering Delivery Track ENGINEERING DELIVERY TRACK CI/CD, Deployment Workflows and Observability A companion study note From branching discipline to error budgets: the why, the trade-offs, then the how. Md Ahbab Hamid Khan https://ahbab.dev/ Source deck: CI/CD, Deployment Workflows and Observability, by Md Ahbab Hamid Khan. This note is written for working engineers. It does not repeat theslide. It carries the background, the numbers and the mental models thata title slide cannot hold: what each stage of delivery costs, why theindustry settled here, and how the parts connect. 1 The delivery value stream 1.1 What the value stream is A value stream is the whole path a change takes, from the moment anengineer types it to the moment a user feels the effect. Delivery workis usually described in stages: write, review, integrate, build, test,package, deploy, watch, and respond. The word stream matters. Each stagehands work to the next, so the slowest stage sets the pace for everyone,and any queue between stages is invisible waiting time that nobody plansfor.Two numbers describe the stream as a whole. The first is lead time,which is the cloc

CI/CD, Deployment Workflows and Observability Engineering Delivery Track toknown cause. Error budgets decide when to push and when to stop. Commit and review Build Unit and static checks Package artifact Deploy to staging Integration and smoke tests Progressive release Observe and decide roll back or fix forward Figure 1. The pipeline as a loop, not a line. The two shaded boxes arethe gates that decide whether a change may continue, and the lime arrowon the left is the part teams forget to design: what production tellsyou has to travel back to the next commit within minutes, not days. Build plane: evidence gathered before release Run plane: evidence gathered from real users Engineer workstation Version con- trol server CI runners Artifact registry Deploy controller Production environment Telemetry backends On call and dashboards what we learn Figure 2. The same work drawn as systems. Most delivery problems arehandovers between the two planes: an artifact that the build planeproved is not the artifact the run plane started, or a signal the runplane holds never reaches the people editing code. 2 Version control and branching discipline 2.1 What a branch really costs A branch is a cop

CI/CD, Deployment Workflows and Observability Engineering Delivery Track 2.2 Three common models Table 1 compares the three models most teams argueabout, and Figure 3 draws the shape of the first two.Trunk based development keeps one long lived line, usually called mainor trunk. Work happens on branches that live hours or a day or two, andunfinished work is hidden behind feature flags rather than kept on abranch. GitFlow keeps several long lived lines: main, develop, plusfeature, release and hotfix branches. It was designed for software withversioned releases that users install, and it carries real overhead whenapplied to a service that deploys many times a day. Release branchingsits between the two: work goes to trunk, and a branch is cut per releasetrain so fixes can be applied to a shipped version. Table 1. Branching models compared. Read the third column first: batchsize and merge cost are what actually differ, the diagrams only lookdifferent because of that. Model How work reaches users Batch size and merge cost Fits when Trunk based Small branches merge to trunk within a day, release comes from trunk, unfinished work sits behind flags Smallest batches, lowest merge cost, need