Chapter 2 of 14 · Days 1–5
Find the pipeline
- How does code actually get to production here?
- Where can I add a check without slowing everyone down?
- What should I look for in a CI/CD setup?
The build and deploy pipeline is the most important system you will learn this month. Every line of code passes through it. Every check you add will run in it. And if someone can change what it does, they can ship anything to production with your company name on it.
Ask the pipeline owner to walk you through one real change, from a pull request to running in production. Take notes as you go. Do not try to fix anything yet.
Draw the path
- Where is the source code hosted, and who can push to the main branch?
- What runs when a pull request is opened? Tests, linting, any security checks?
- Who must approve a merge, and can that rule be bypassed?
- Where are build artefacts stored, and are they signed or checked?
- What credentials does the pipeline hold, and what can each one reach?
- Who can deploy to production, and is there a record of each deploy?
You will probably find more than one pipeline. Older services often build differently from newer ones, and a team may have its own scripts. Note each one. The old one is often the risky one.
What to look for
- Long-lived secrets stored as pipeline variables that every job can read.
- Third-party actions or plugins pulled by a moving tag rather than a fixed version.
- Jobs triggered by pull requests from forks that run with write access or secrets.
- Branch protection that admins can skip, and do.
- No link between what was reviewed and what was deployed.
The question you might not ask out loud
Is it my job to secure the pipeline, or the platform team’s?
Usually both, and that is fine. The platform team owns it day to day. Your job is to know where the risks are, explain them in their terms and help them pick fixes that do not make builds slower or flakier.
Where checks belong
Fast checks that rarely produce noise, such as secret detection, can run on every pull request. Slow or noisy checks belong on a schedule or on the main branch, with results sent to a place the team already looks. A check that adds minutes to every build and cries wolf will be turned off quietly, and nobody will tell you.
Rule of thumb:Ask before adding a blocking check. A check that fails builds needs an owner, a way to suppress a false positive and a person to call when it breaks at 6 pm.
By the end of the week, you should have a simple diagram of each pipeline with the credentials and approval points marked. Share it with the pipeline owner and ask what you got wrong. You will learn more from the corrections than from the drawing.