Code → Git → CI/CD
Every production system starts the same way: code is written, reviewed, built once, and promoted through environments until it reaches users. This module is about designing that path so bad code cannot reach production and every release is repeatable.
You already know what Git is. What senior interviews probe is your judgement: which branching model fits a 50-engineer team, where you place quality gates, and how you guarantee the artifact tested in staging is byte-for-byte the one deployed to production.
Code -> Git (branch + commit) -> Pull Request / Review -> Build (compile + package) -> Test (unit + integration) -> Artifact (versioned, immutable) -> Deploy (promote through envs)
Senior-level focus
- Design a Git workflow that scales to large teams without merge chaos.
- Put quality gates where they stop bad code cheaply — earlier is cheaper.
- Build the artifact once and promote the same artifact to every environment.
- Separate configuration from secrets, and both from the build.
- Make releases boring: repeatable, observable, and reversible.
Branching strategies
A branching strategy is the team agreement on how work flows into the main line. The common options are trunk-based development (short-lived branches, merge to main many times a day) and GitFlow (long-lived develop/release branches).
Trunk-based keeps branches alive for hours, relying on feature flags to hide unfinished work. GitFlow adds release and hotfix branches, which suits scheduled releases but creates painful long-lived merges. Most high-throughput teams pick trunk-based plus flags.
main ---o-------o-------o-------o--->
\ / \ /
feature o---o o---o (short-lived, merged fast)What matters in interviews
- Long-lived branches are the root cause of merge hell; short-lived branches avoid it.
- Trunk-based + feature flags decouples deploy from release.
- GitFlow fits regulated / scheduled releases, not continuous delivery.
- Branch protection + required reviews enforce the workflow in practice.
Real-world example
A 50-service org moves to trunk-based development: every service merges to main behind a flag, CI runs on every push, and releases are a flag flip rather than a branch merge — cutting integration bugs sharply.
Likely interview questions
- 1.Design a Git branching strategy for 50 engineers shipping daily. What prevents merge conflicts and broken mains?
Merge vs rebase
Merge preserves history as it happened and creates a merge commit; rebase rewrites your commits on top of the latest main for a linear history. Both integrate changes — they differ in the history they leave behind.
What matters in interviews
- Rebase local, unshared work to keep history linear and readable.
- Never rebase shared/public branches — it rewrites commits others have.
- Squash-merge gives one clean commit per PR; good default for feature branches.
- Linear history makes bisecting and reverting far easier.
Real-world example
A team standardises on squash-merge for PRs: main stays linear, each commit maps to one reviewed change, and reverting a bad release is a single clean revert.
Pull requests & code review
A pull request is the checkpoint where changes are reviewed, checked by CI, and gated before entering main. Review is both a quality gate and a knowledge-sharing mechanism.
What matters in interviews
- Required reviews + green CI as merge gates stop most defects cheaply.
- Small PRs get better reviews than large ones — keep them focused.
- Automate the mechanical checks (lint, format, tests) so humans review design.
- CODEOWNERS routes reviews to the right people at scale.
Likely interview questions
- 1.How do you keep code review effective as a team grows from 5 to 50 engineers?
Build once, deploy many
The build produces a single immutable, versioned artifact (a container image or package). That exact artifact is promoted through dev, QA, staging, and production. You never rebuild per environment.
Rebuilding per environment risks drift — different dependency versions, different base images, different bugs. Building once guarantees the thing you tested is the thing you ship; only configuration changes between environments.
Build once -> artifact v1.4.2 (immutable)
|-> Dev (config: dev)
|-> QA (config: qa)
|-> Staging (config: staging)
|-> Prod (config: prod)What matters in interviews
- One artifact, many environments — eliminates 'works in staging, breaks in prod'.
- Environment differences live in configuration, never in the build.
- Artifacts are immutable and versioned so any release is reproducible.
- Promotion, not rebuild, is what moves code toward production.
Real-world example
A release ships image sha-9f3c to staging; after sign-off the same image is promoted to production. No rebuild means no surprise dependency bump between staging and prod.
Likely interview questions
- 1.Why is 'build once, deploy many' important, and how do you enforce it in a pipeline?
Configuration vs secrets
Configuration is non-sensitive, per-environment settings (feature flags, URLs, log levels). Secrets are sensitive credentials (DB passwords, API keys). Both are injected at deploy time — but secrets need a vault, not a config file.
What matters in interviews
- Never bake config or secrets into the artifact — inject at runtime.
- Secrets belong in a secret manager (Key Vault), not in Git or env files.
- Rotate secrets without redeploying by reading them at startup / on refresh.
- Use identity (Managed Identity) over long-lived static credentials.
Real-world example
An app reads its connection string from Azure Key Vault via Managed Identity at startup. Rotating the DB password is a vault update — no code change, no redeploy, no secret in source control.
Pipeline gates & environment promotion
Gates are automated (or manual) checks between pipeline stages: tests must pass, security scans must be clean, coverage thresholds met, and a human approval before production. Promotion moves the artifact stage by stage only when each gate is green.
What matters in interviews
- Fail fast: cheap checks (lint, unit) before expensive ones (integration, e2e).
- A blocked gate should stop promotion, not be bypassed under pressure.
- Manual approval before prod is a control, not a bottleneck, when the rest is automated.
- Gates encode your release policy as code, so it is consistent every time.
Likely interview questions
- 1.Where would you place quality and security gates in a pipeline, and why in that order?
Key Takeaways
- Short-lived branches + trunk-based development scale; long-lived branches cause merge hell.
- Build one immutable, versioned artifact and promote it — never rebuild per environment.
- Keep configuration and secrets out of the build; inject at runtime, vault the secrets.
- Gates encode your release policy: fail fast, block on red, approve before prod.
- The goal is boring releases — repeatable, observable, and reversible.