DEV Community

Cover image for 🚀 Delivery Practices a Software Team Actually Needs
Zenika profile image Benoit COUETIL 💫
Benoit COUETIL 💫 for Zenika

Posted on

🚀 Delivery Practices a Software Team Actually Needs

#devops #productivity #programming #cicd

Continuous deployment is not a Netflix cosplay. It is a stack of practices that make shipping to production so routine it becomes boring. We map that stack along two axes: non-technical vs technical, and baseline vs elite — product habits first, elite last, because elite is not a universal target.

Initial thoughts

Most teams do not fail because they lack a manifesto on the wall. They fail because the advice arrives unsorted: microservices before CI is green, trunk-based theatre before anyone trusts the test suite, a "DevOps transformation" that is mostly a Slack channel named #ops-please-help.

We organize practices the way high-performing delivery research does — product / lean / culture on one side, technical capabilities on the other — and we present them non-technical first, then technical, each split into baseline (what makes frequent deploys reachable) vs elite (what removes the remaining friction). Non-technical habits prevail: a perfect pipeline shipping the wrong thing is still waste. Elite practices come last because they are not a universal target — most teams get more from a boring baseline than from canary theatre on a flaky suite.

A team of one (AI made that shape ordinary) can skip pairing, generative collaboration, and most of elite. It does not skip small batches, user feedback, WIP, or the technical baseline. Peer review without a peer means the pipeline is the other reviewer — the model does not join the on-call rotation.

Evidence (DORA, craft, agile) supports the stack; it is not the pitch. The pitch is boring production: short lead time, frequent deploys, failures that are rare and recoverable, without heroics on Friday night.

Each practice below: a short why, then concrete moves.

1. Why best practices matter? The outcomes

You do not need elite labels on a slide. You need outcomes that speak to two audiences at once — the team doing the work, and the people holding the budget. The DORA research frames this as a win/win: the same practices that make delivery faster also make it calmer and cheaper. "Boring production" is the shorthand — short lead time, frequent deploys, failures that are rare and recoverable, without heroics on Friday night.

Concretely, four outcomes describe that picture:

  1. Changes reach production in hours or days, not months.
  2. Deploys are routine — pipeline or one click, same artifact across environments.
  3. Failures are uncommon and recovery is practiced, not invented under adrenaline.
  4. Deploy (technical) and release (product) can be decoupled when needed.

For the business, those four translate into the language decision-makers actually use:

  • Time-to-market: shorter lead time means ideas reach users faster — competitive advantage, not a quarterly slide.
  • Financial savings: fewer failed changes and faster recovery mean less rework, less incident cost, less overtime billed to a budget line someone watches.
  • Wellbeing: a generative, blameless culture with sustainable pace is not a perk — it is a delivery lever. Hero cultures are leading indicators of outages and resignations.

Those outcomes are exactly what throughput and stability metrics try to capture. If you want numbers on a GitLab project, we once published GitLab: A Python Script Calculating DORA Metrics — useful as a mirror, not as a religion.

Practices are inputs, and management does not buy inputs. A slide about trunk-based development will not move a CFO; "we cut lead time from three weeks to two days, halved our change-failure rate, and the on-call rotation stopped being a resignation letter" might. The whole stack below exists to make those outcomes move — and to keep them moving after the next reorg, not just for the one-quarter spike that earns a LinkedIn post.

2. Non-technical practices — the baseline

Technical excellence ships the wrong thing beautifully if product and team habits are absent. These baseline habits do not require a VP of Transformation — and they come first for a reason.

Small batches

Slice work so feedback arrives while memory is fresh. Working in small batches is a product/process discipline as much as a git habit.

Concrete:

  1. Prefer MRs reviewable in under an hour.
  2. Split stories by user-visible outcome, not by layer ("all the SQL this sprint").
  3. If a change needs a three-page risk essay, it was already too big last Tuesday.
  4. Ship thin vertical slices; thicken later.

Stakeholder and user feedback

Early feedback tops almost every agile success list for a reason: without users in the loop, CD accelerates waste.

Concrete:

  1. Demo or expose something to a real user every iteration — even internal users count.
  2. Keep a product owner / domain expert reachable within the sprint, not "next quarter."
  3. Write backlog items as outcomes, not as technical chores in disguise.
  4. Kill features nobody uses — the backlog is not a museum.

Continuous improvement and WIP limits

Retros without experiments are group therapy. WIP limits make queues visible.

Concrete:

  1. One process experiment per sprint, with a success check.
  2. Cap WIP on the board; stop starting, start finishing.
  3. Time-box spikes so research does not drift.
  4. Track aging work items; anything older than a sprint deserves a decision: finish, cut, or kill.

Generative collaboration

High-trust, high-information-flow culture — Westrum's generative type — predicts delivery performance better than tool brand loyalty.

Concrete:

  1. Blameless postmortems; fix the system, not the person who typed the command.
  2. Shared responsibility for quality and production of what you build.
  3. Make asking for help cheaper than hiding (pairing budget, public channels).
  4. Leaders say "I was wrong" in public. Culture is what happens after the slide deck leaves the room.

Pairing and knowledge transfer

Pairing is a social practice with technical side effects: fewer bus factors, faster onboarding, better reviews.

Concrete:

  1. Pair on unfamiliar or high-risk areas.
  2. Rotate ownership so no module is a single-human crypt.
  3. Write short ADRs when the why would otherwise leave with someone's badge.
  4. Budget pairing time explicitly — "when we have time" means never.

Octopus studying the practice ladder

3. Technical practices — the baseline

This is where a solo developer (or a small team) gets the most impact per hour invested — once small batches and feedback are not actively sabotaging the loop.

Version control for everything that ships

If it can break production, it belongs in version control: app code, pipelines, infra-as-code, config that is not a secret, release notes next to the code they describe.

Concrete:

  1. Ban direct pushes to the default branch.
  2. Put pipeline definitions in the repo; review them like product code.
  3. Tag or record every production deploy so "what is live?" is a git question.
  4. Secrets stay in a vault — version references, not the passwords themselves. (Dave's USB stick is not a HA strategy.)

Peer code review

The cheapest early defect filter we still have, and a knowledge pump. Seniors should not be the only reviewers — we argued that at length in Every Developer Should Review Code — Not Just Seniors.

Concrete:

  1. Every change to the default branch goes through a merge request.
  2. Same-day review SLA; large MRs are a process failure, not a badge of honor.
  3. Review for behavior, risk, and clarity — not semicolon theology.
  4. Require at least one human approval; bots are assistants, not scapegoats.

CI per feature branch

Integrating only on main means the whole team pays for one person's surprise. A pipeline on every feature branch keeps the shared line green and leaves breakage with the author.

Concrete:

  1. Run build + tests on every MR / branch push.
  2. Aim for feedback in minutes, not hours.
  3. Fix red pipelines before starting new work.
  4. Keep the default branch protected and green — broken main is a team-wide tax.

Modern testing strategy (trophy, test data, TDD)

"Automated tests" is too vague. Prefer a modern testing strategy: a testing trophy bias (static checks + many integration tests + fewer brittle E2E), managed test data, and TDD where design benefits.

Concrete:

  1. Agree the trophy shape for your stack; write mostly tests that give confidence without a flaky UI circus.
  2. Gate merge on fast, trusted suites; keep E2E thin and stable.
  3. Quarantine flaky tests within 48 hours — mute-and-forget turns green into fiction.
  4. Provide disposable, seeded test data; never depend on a shared "QA database" that three teams mutate like a commons pasture.
  5. Use TDD for new behavior and tricky logic: failing test → minimal code → refactor. Skip TDD on throwaway spikes.

Environment per feature branch

A green unit suite is not the same as "this feature works in a real stack." A green pipeline on main tells you the code integrates; it tells you nothing about whether the new endpoint actually answers in a real browser, against a real database, next to the other half-merged features of the sprint. An environment per branch (or ephemeral preview) closes that gap before merge — it turns "works on my machine" into "works on a machine that looks like prod," without a calendar invite.

Concrete:

  1. Deploy each long-lived feature branch to an isolated URL / namespace.
  2. Use it for manual checks and a few targeted E2E runs.
  3. Tear environments down automatically — zombie previews are how cloud bills invent folklore.
  4. Prefer the same deploy path as production, with smaller sizing.

Documentation-as-code per branch

Docs that live only on main lag reality. Build and publish documentation from the same branch as the change — preview sites, generated API refs, runbooks in the repo. We explored why this pattern wins in Documentation-as-Code Has Silently Won For Tech Content, and the same per-branch preview trick we used for GitLab Pages per Branch: The No-Compromise Hack to Serve Preview Pages is what makes the docs preview real on every MR.

Concrete:

  1. Keep docs in the repo next to the code they describe.
  2. Pipeline job: build docs on every branch; publish a per-branch preview (Pages, Storybook, OpenAPI UI…).
  3. Review doc diffs in the same MR as behavior changes.
  4. Link the preview URL in the MR description — reviewers should not need a séance to find the new endpoint.

Continuous delivery (always releasable + automated deploy)

Here we merge what tool vendors often split: continuous delivery means the software is always in a releasable state and the path to production is automated. Manual SSH snowflakes are not "careful"; they are unpaid drama. Continuous deployment (every green commit goes to prod) is optional once CD is real — a policy choice on top of the same machinery.

Concrete:

  1. One artifact promoted across environments; no "rebuild for prod."
  2. Deploy via pipeline or one approved click — identical steps every time.
  3. Keep main deployable; fixing releasability beats starting the next epic.
  4. Separate deploy from release with flags when the product is not ready for all users — this deploy/release decoupling use of flags is baseline; using flags to hide incomplete work behind trunk-based development is the elite form covered in section 5.
  5. Rehearse rollback / roll-forward on a boring Tuesday. (Friday deploys are fine when Tuesday already proved you can undo them.)

A pipeline you dare not touch is folklore, not automation — feed it continuously, as we argued in Keep Feeding Your CI/CD — Or Watch It Die.

Monitoring and observability

Daily deploys without eyes on production is Schrödinger's release: simultaneously fine and on fire until someone opens the dashboard.

Concrete:

  1. Track golden signals: latency, traffic, errors, saturation.
  2. Structured logs with correlation IDs across services.
  3. Alert on actionable symptoms; paging for disk at 71% trains people to ignore the building on fire.
  4. Attach a runbook link to every alert that can wake a human.

Security shifted left

Security bolted on at the release CAB is how you discover CVEs during the demo. The cost of a finding grows roughly with the distance between where it was introduced and where it was caught — a vulnerable dependency caught in the MR is a version bump; the same dependency caught at the CAB is a release slip, and caught in production is an incident report. Shifting left is mostly an economic argument, not a moral one.

Concrete:

  1. Dependency and container scanning in CI.
  2. Secret detection on push.
  3. Threat-model new surfaces in the MR that introduces them.
  4. Fix criticals on a clock, not on vibes.

Simple design, refactoring, and managed debt

Craft is not a separate religion; it is how the baseline stays cheap over years.

Concrete:

  1. Boy-scout rule on touched files.
  2. Prefer delete over another abstract factory of abstract factories.
  3. Keep a visible debt list with cost-of-delay; budget a fixed capacity slice for structural work.
  4. Upgrade dependencies on a cadence before they become a liability.

Octopus checking a ranked holographic list

4. Non-technical practices — elite

Elite culture and product habits turn a working pipeline into a learning system — the baseline ships reliably, these practices decide what gets shipped and whether the team survives shipping it. Skip them until the non-technical baseline is real; they are not a participation trophy.

Team experimentation and product hypotheses

Elite product management: try ideas without a twelve-signature approval pilgrimage.

Concrete:

  1. Frame work as hypotheses with kill criteria.
  2. Use flags and analytics to validate before scaling.
  3. Empower the team to run small experiments without leaving the team for permission.
  4. Celebrate killed experiments — they bought information cheaper than a full build.

Value-stream visibility

See the path from idea to production; attack waits, not only busy coding.

Concrete:

  1. Map the flow once; find the longest queue.
  2. Make blocked states visible on the board.
  3. Measure lead time by stage (code, review, QA, change board, prod).
  4. Optimize the bottleneck you measured, not the one that feels dramatic in standup.

Transformational leadership and wellbeing

Tools cannot compensate for a meat grinder. Leadership that enables learning, clarity, and sustainable pace shows up in delivery performance.

Concrete:

  1. Protect improvement time the same way you protect feature time.
  2. Remove approval steps that add delay without reducing risk.
  3. Watch burnout signals; hero culture is a leading indicator of outages.
  4. Hire and promote for teaching and collaboration, not only for lone-genius throughput.

5. Technical practices — elite

Baseline makes continuous delivery reachable. These practices remove remaining drag — adopt them when the baseline is already boringly reliable. Most teams should stay on the baseline longer than their slide deck suggests.

Trunk-based development and feature flags

Short-lived branches, frequent integration to trunk, incomplete work hidden behind flags. Powerful — and a mess if CI and tests are not trusted yet. The elite move here is TBD-driven flag usage: flags not just to decouple deploy from release (that is baseline), but to keep trunk always green while half-built features ship dark. See trunk-based development.

Concrete:

  1. Branch lifetime in hours/days, not weeks.
  2. Integrate to trunk at least daily.
  3. Feature flags for incomplete or risky exposure; product can toggle without a redeploy.
  4. Delete flags after rollout — flag archaeology is a special kind of haunted house.

Database change management

Schema changes are where "always releasable" goes to die if nobody owns the migration path.

Concrete:

  1. Migrations in version control, applied by the pipeline.
  2. Expand/contract for breaking changes; no dual-write hacks without a plan.
  3. Forward-only in production; rehearse rollback strategy when truly needed.
  4. Never "run this SQL from an email" as a release step.

Loosely coupled deployability

A team (or module) can deploy without a twelve-team release train. Note: a well-factored modular monolith is often the prerequisite that makes this decoupling reachable — splitting a tangled monolith into fashion microservices before you can deploy the monolith cleanly is a category error.

Concrete:

  1. Clear API contracts; version or expand carefully.
  2. Prefer a modular monolith before fashion microservices if you still have more services than users.
  3. Independent deploy pipelines per deployable unit.
  4. Contract tests between consumers and providers.

Advanced deployment strategies

When downtime or blast radius matters: blue/green, canary, dark launch. Feature flags often cover a surprising amount before you need full traffic-shifting machinery.

Concrete:

  1. Canary a percentage of traffic; watch error budgets before full rollout.
  2. Blue/green when you need instant cutover and easy revert.
  3. Dark launch: code live, users unaware — validate load before the marketing email.
  4. Automate the promotion criteria; humans confirm policy, not click fifty servers.

Internal platform and flexible infrastructure

Golden paths beat ticket queues — when the platform is a product, not a new bottleneck. Containers and IaC help reproducibility; they do not replace a green CI.

Concrete:

  1. Self-service: create preview env, run pipeline, deploy — without a week-long ticket.
  2. Infra-as-code for environments that matter.
  3. Autoscale runners and app capacity so branch previews do not block everyone else.
  4. Measure platform adoption and time-to-first-deploy for a new service.

6. Where to start (solo vs team)

Start with the non-technical baseline: small batches, stakeholder and user feedback, WIP. Pairing and generative collaboration when there is a second human. Without that loop, faster deploys just accelerate waste.

Solo — then the technical baseline, in roughly this order:

  1. Version control + CI on every branch (self-merged MRs are fine if CI is the gate).
  2. Modern testing strategy until the suite is trusted.
  3. Automated deploy path + monitoring (CD).
  4. Env + docs per branch when feedback before merge still hurts.
  5. Design / debt hygiene as a continuous tax.

Skip most of elite until this is dull.

Team with mandate — run non-technical and technical baselines in parallel. A collaborative team without CI is still slow; a perfect pipeline shipping the wrong thing is still waste.

Elite practices (product experimentation, value-stream mapping, TBD + flags, advanced deploys, platform) come after both baselines are dull. Trying trunk-based theatre on a flaky suite is how you invent new genres of merge conflict.

Wrapping up

Boring production is a stack, not a slogan. Split practices non-technical / technical, then baseline / elite — non-tech first because it prevails, elite last because it is not for everyone. Small batches, feedback, and WIP keep the loop pointed at value; pairing joins when there is a second human. A developer alone should then lean on the technical baseline: version, CI per branch, modern tests, CD with eyes on prod, docs and previews on the branch, craft that keeps the loop cheap — the pipeline is the other reviewer. Elite moves amplify a system that already works.

If you need one retro question: Which baseline practice — non-technical or technical — made boringly reliable, would shorten our path to valuable production most in the next ninety days? Fund that. Leave the Netflix costume in the closet.

Octopus between two holographic boards

Illustrations generated locally by Draw Things using Flux.1 [Schnell] model

Further reading

All Articles by Theme
bcouetil profile

All Articles by Theme

#automation #devops #gitlab #kubernetes
11
Comments 1
8 min read

This article was enhanced with the assistance of an AI language model to ensure clarity and accuracy in the content, as English is not my native language.

Top comments (0)