DevOps Fundamentals: Reducing Batch Size and Eliminating Constraints

If you ask three people to describe DevOps, you will receive four different answers: some call developers who work on operations DevOps, others associate it with infrastructure and deployment automation, and some see it as a modern label for sysadmins. The term is popular, but what does DevOps actually mean?

The first way to view DevOps is to create a balanced, stable workflow across all functional areas of an organization—from gathering requirements to operating software in production—focusing on the overall system goal rather than isolated departmental objectives.

1.1 Reduce Batch Size

Work in progress (WIP) refers to work that has started but not yet finished. A large amount of WIP indicates multitasking and hampers workflow. To limit WIP, batch sizes should be reduced, a concept derived from lean manufacturing where large batches of parts are produced to minimize machine setup time.

For example, an automobile factory may produce many body panels to reduce changeovers, but this creates a large WIP inventory, lengthening delivery times and increasing the risk of discarding entire batches if defects are found.

The same idea applies to software development, where each commit to version control adds to the batch size of the value stream. A typical case is an annual production deployment: deploying once a year creates a huge batch, and any problem forces a rollback of the entire batch, requiring extensive rework and delayed feedback.

Long‑lived feature branches suffer similarly; the longer a branch stays isolated, the larger the batch, the harder integration becomes, and the higher the chance of merge conflicts and rework, which disrupts the workflow and increases lead time.

To shorten delivery time, batch sizes must be reduced. Teams should avoid long‑lived feature branches, integrate early, and deploy in small increments. By moving toward a single‑piece flow—where each commit passes through the entire value stream—feedback becomes rapid once automated checks succeed, and changes flow into production continuously.

Teams that achieve this adopt trunk‑based development, continuous integration, continuous delivery, and continuous deployment, invest in test automation, design low‑risk releases, and organize themselves to minimize handoffs, thereby reducing knowledge loss and preventing work pile‑up.

1.2 Eliminate Constraints

Continuously discovering and eliminating constraints in the workflow is key to increasing throughput and reducing lead time. As Dr. Goldratt states in "The Goal," every value stream has a single constraint, and improving anything else is an illusion.

In any value stream there is always a direction of flow and always only one constraint. Improving anything that is not the constraint is an illusion.

In a technical value stream, creating a test environment can be a constraint; if it takes hours to provision, any improvement elsewhere is ineffective.

For instance, reducing build time from ten minutes to three minutes speeds up builds, but if environment provisioning remains a bottleneck, overall flow does not improve. Moreover, faster builds can increase WIP, causing new versions to queue for the still‑slow environment. The solution is to locate the constraint, eliminate it, and then move to the next constraint.

About the author: Ze Yang is a DevOps practitioner focusing on enterprise‑level DevOps operations and development techniques. He shares practical Linux operations and DevOps course content drawn from real‑world projects, aiming to provide useful skills recognized by many learners.