A customer raises a feature request. Before it reaches them, the change passes through checks, tests, and review. Lead time is the elapsed time from that request to delivery—not just the time spent running the pipeline. Those checks provide useful feedback, but they can also delay delivery. section 5.4
Each step has a cycle time: the time between its start and finish. Because these steps sit within the overall lead time, reducing a slow cycle time can help shorten the customer’s wait. The goal is not to remove checks indiscriminately; it is to get useful feedback without making delivery unnecessarily slow. section 5.4
Choose how checks run
Suppose a Go pipeline runs formatting, linting, vetting, and tests. Running independent checks at the same time can return results sooner and reveal multiple problems together, but it uses more machines or processes. A team may instead combine parallel and sequential steps to balance feedback speed against compute cost. section 5.4
Listing 5.8 pipeline.yml
jobs:
test:
needs:
- format-check
- lint #1
name: Test Application
lint:
name: Lint
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Lint
uses: golangci/golangci-lint-action@v2 #2
The pipeline configuration makes tests depend on formatting and linting. Such dependencies are one place to examine when deciding which checks must finish before the next stage begins. section 5.4
Track delivery time alongside build and response times, then use those measurements to choose process improvements. If a stage is slow, examine its testing approach or pipeline arrangement before changing it. The operational question is whether a change gets sound feedback and reaches the customer sooner. section 5.4 section 11.4.1
