Watch an elite engineering group for a month and a pattern emerges: nothing they do is dramatic. The gap between them and everyone else is a set of small, repeatable habits, held consistently and measured honestly. The delivery research behind the term DevOps has documented these habits for over a decade. Here are nine of them, each defined precisely enough to copy.<\/p>\n
Elite teams merge small changes into a single shared branch at least daily and retire long-lived branches entirely. Trunk-based development removes the slowest, riskiest event in ordinary delivery \u2014 the big merge \u2014 by making sure it never accumulates. Integration happens in increments of hours, so conflicts are trivial and the mainline is always close to releasable. Feature flags carry the unfinished parts, which is what keeps the merges small enough to stay honest.<\/p>\n
The pipeline that validates a change returns its verdict fast. Around ten minutes is the working sweet spot: enough time for real build and test coverage, short enough that the author stays at the desk to act on the answer. Feedback slower than a coffee break gets deferred, and deferred feedback is how defects travel happily from Tuesday to Friday. When a pipeline cannot answer inside ten minutes, elite teams shrink the test suite’s slowest tier rather than accept the wait.<\/p>\n
How long a change takes to land, how often code ships, how quickly a failed service is made healthy again, what share of changes fail \u2014 plus rework rate, the fifth, added in 2024, one year after the definition of recovery was narrowed to change-caused failures. Top performers read the set as a whole, because the research never found teams that maximise every number at once. A dashboard that flatters one metric while hiding three is decoration. Weekly review, whole set, no exceptions \u2014 the discussion of trade-offs is where the improvement ideas actually come from.<\/p>\n
Returning to the previous working version is practised on quiet days, timed like a fire drill. The case for it is stark: one documented team, facing a payment service rejecting four percent of transactions, spent a hundred and ninety minutes recovering the first time they tried it cold; a rehearsed run of the same operation takes about twenty. The drill also settles the policy case \u2014 if the last change carried a migration that cannot be undone, the runbook already says to disable the feature by its flag or carry the fix forward instead. The drill’s output is two numbers \u2014 time taken, and owner \u2014 posted where the team plans its work.<\/p>\n
Feature flags separate two events that most organisations wrongly fuse: putting code into production and letting users see it. Work in progress ships dark, switched off, whenever it is ready to travel \u2014 which means deploys stay small and releases become a business decision, made in daylight, reversible with a toggle. Flags get cleaned up when the work settles, because a flag that lives forever is just untested code wearing a costume.<\/p>\n
New versions meet a canary audience first \u2014 a small slice of traffic, watched against error rates and latency \u2014 and expand only while the numbers hold. A defect discovered by one percent of sessions is a data point. The same defect discovered by everyone at once is an incident with a post-mortem and a press quote. Automatic rollback on error-rate thresholds turns the canary from a virtue into a mechanism.<\/p>\n
When a failure lands, the team has five working days to hold a review that interrogates the system rather than the people. Blameless does not mean consequence-free; it means the document asks how the process allowed the failure, because that is the level at which it can be prevented. Westrum’s research on organisational culture explains the mechanics: messengers of bad news must be safe, or the next bad news travels slowly or not at all. The review closes with actions that have owners and dates, or it was a meeting, not a review.<\/p>\n
Schema changes never ship in one move. The expand-and-contract pattern widens first \u2014 add the new column, write to both, backfill at leisure \u2014 and narrows later, once the old path is provably unused. Combined with least-privilege access and short-lived credentials issued through OIDC, this is also how teams in strictly regulated settings automate their controls instead of stacking approvals. Every approval gate added after an incident slows delivery without reducing risk; the research on heavyweight change-approval boards is unambiguous about that. Regulated and unregulated teams alike end up preferring controls a machine can verify over opinions a committee can minutes.<\/p>\n
Rather than inspecting every release, elite groups pull roughly ten random changes each quarter and audit those, logging any break-glass merges as signals worth reviewing. Sampling keeps assurance honest at a fraction of the cost, and \u2014 crucially \u2014 it cannot be gamed the way a known approval checkpoint can. Governance becomes a measurement activity instead of a queue. Break-glass usage is reviewed in the same breath \u2014 spikes in it are information, and silence about it is worse.<\/p>\n
Sequencing matters more than ambition. The Three Ways, flow, feedback and continuous learning, suggest the order: start with the habits that make flow visible, namely the first three, then buy safety with the drills, flags and canaries, then lock in learning with reviews and sampling. Ninety days is a realistic envelope for the first pass: two weeks to see the stream, four to automate it, four to govern it. Avoid the two classic corruptions:<\/p>\n
The CALMS reminder, culture, automation, lean, measurement and sharing, keeps the human scaffolding upright while the technical habits set. Deeper background lives in an overview of how DevOps bridges development and operations<\/a>, the tools worth learning hands-on are catalogued in a practical guide to essential DevOps tooling<\/a>, and the traps on the way are collected in this list of common adoption mistakes<\/a>. For the full research picture behind every habit above, xOps School’s detailed DevOps guide<\/a> is the single best follow-on read. None of the nine requires permission to start; the first can begin with tomorrow morning’s next merge, which is precisely why elite teams look unremarkable and sound unremarkable \u2014 the remarkableness is the streak, not the moves.<\/p>\n","protected":false},"excerpt":{"rendered":" High performers are not lucky; they run specific, repeatable habits. Nine practices that consistently show up in elite delivery organisations, precisely explained.<\/p>\n","protected":false},"author":4,"featured_media":1103,"comment_status":"","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[168],"tags":[],"class_list":["post-1102","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-devops"],"_links":{"self":[{"href":"https:\/\/cotocus.in\/blog\/wp-json\/wp\/v2\/posts\/1102","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/cotocus.in\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/cotocus.in\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/cotocus.in\/blog\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/cotocus.in\/blog\/wp-json\/wp\/v2\/comments?post=1102"}],"version-history":[{"count":0,"href":"https:\/\/cotocus.in\/blog\/wp-json\/wp\/v2\/posts\/1102\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/cotocus.in\/blog\/wp-json\/wp\/v2\/media\/1103"}],"wp:attachment":[{"href":"https:\/\/cotocus.in\/blog\/wp-json\/wp\/v2\/media?parent=1102"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/cotocus.in\/blog\/wp-json\/wp\/v2\/categories?post=1102"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/cotocus.in\/blog\/wp-json\/wp\/v2\/tags?post=1102"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}