The DevOps lifecycle

QuickCart’s problem isn’t bad code. It’s that each change waits for thirty-nine others, and travels round the whole process with them.

Every change to software goes through the same eight stages, whether it’s a new app feature or a one-line fix. People usually draw them as a loop.

The eight stages

The first four are often called dev, and the last four ops. The whole point of DevOps is that one team owns the whole loop. The people who write a change see it run, and see it fail.

Release and deploy are different things

They sound the same, but they’re separate steps. Release is the decision that a change may reach users. Deploy is putting the new code on the servers. Keeping them apart is useful: later in this module, feature flags let you deploy code today and release the feature next week.

The loop is only as fast as its slowest wait

Look at QuickCart’s promo-code change. The work on it took about two days. But it took 35 days to reach customers:

Most of its life, the change was sitting in a queue. That’s normal for big batches. Making people work faster barely helps. Making the batch smaller does.

Why small batches win

Small batches only work if each trip round the loop is cheap. That’s why the rest of this course automates the build, the tests and the deploy.

Follow one change round the loop. First with small batches, then switch to Big batches and send another. Watch the clock in the middle, and where the change gets stuck.

What to notice: in big batches, the red stages aren’t slow because anyone is lazy. The change is waiting: for other changes, for testers, for a release window. The work itself takes about the same time in both runs.

Free — you only read your own project’s history.

You’ll take one change you shipped recently and map its trip round the loop: when it started, when it reached users, and where it waited. This is called a value stream map, and it’s how teams find their slowest step. About 15 minutes.

You need a project in git that you’ve shipped something from, such as your own app. If you don’t have one, use QuickCart’s numbers from the table in the idea and do the last two steps.

1. Pick one change

   Choose something small that reached users in the last month or two: a bug fix or a small feature. Write down one word that appears in its commit messages, like photo or checkout.

2. Find when the work started

   Open the terminal in your project’s folder, then list the commits that mention your word, oldest first. Put your own word in place of the highlighted one:

   TerminalCopy

   git log --reverse --format="%h  %ad  %s" --date=short -i --grep="photo"

   Part	What it means
   git log	list commits, newest first
   --reverse	oldest first instead, so the first line is when the work started
   --format="%h %ad %s"	show each commit as its short ID (%h), its date (%ad) and its message (%s)
   --date=short	print dates as year-month-day
   -i	ignore upper and lower case when searching
   --grep="photo"	only commits whose message contains this word. Replace it with yours

   You should see

   19f7ca8  2026-08-31  Add photo field to menu items
   29c9c89  2026-09-02  Resize photos on upload
   15374d9  2026-09-03  Merge pull request #41 from menu-photos

   Yours will show your own commits. The first line is when coding started. A line like the last one, a merge, is when the change joined the main branch.

3. Find when it reached users

   This part isn’t in git. Look where your team records releases: the App Store Connect or Play Console release history, a release notes page, or a deploy log. Write down the date the change was available to users.

4. Fill in the map

   Copy this table into a note and fill it in for your change. Guess where you have to; rough days are fine.

   Stage	Working on it	Waiting	Waiting for what?
   Code, including review
   Build
   Test
   Release
   Deploy
   Total

   Add up each column.

   You should see

   Two totals. For most teams, Waiting is several times bigger than Working on it.

5. Find the biggest wait, and one way to shrink it

   Circle the row with the biggest wait. These are the usual causes, and the lessons that fix them:

   If it waited for	The usual fix	Where it’s taught
   Other changes, to release together	Release each change on its own	This module
   Someone to test it by hand	Automated tests on every change	Continuous integration
   An approval meeting or release window	Automated checks as the approval, and safer ways to release	Ways to release
   Someone to run the deploy	A pipeline that deploys	Continuous delivery
   A feature being finished	Ship it switched off, behind a flag	Feature flags

   Write one sentence: “Our biggest wait is ___, and we could shrink it by ___.”

6. Clean-up step: Clean up

   Nothing to delete. git log only reads history; it never changes anything.

   Keep your map. In the next lesson you’ll turn the same history into four numbers that measure how well a team delivers.