Skip to content

FeedbackLoop.md

Latest commit

 

History

History
25 lines (14 loc) · 2.45 KB

FeedbackLoop.md

File metadata and controls

25 lines (14 loc) · 2.45 KB

TRPM and fast feedback loop

Assuming infrastructure developers are using the github flow or something similar, you want them to have a way to test their changese (in a clean resource) before pushing their commits and opening a PR.

In the quick diagram I draw below, the inner loop (in black), is the individual developper workflow, and once they push to their team's (or public) repository, their commits enter the wider loop (colored) where their CI/CD tools orchestrate the process (ideally automatically).

image

The 2 key elements to this workflow are:

  • iterating quickly and small, to batching up changes before testing and integration with the other contributions (reducing the batch size/change scope).
  • getting fast feedback (fail fast) and improve quality by using TDD

To achieve this, the response time of the development environment is critical. The quickest you can run your test and get feedback on the changes you're making, the more you will shift testing to the left (that is, test early, not as a phase in its own later in the process).

If it takes only a few minutes to start testing from a clean VM, you can do it many times an hour.

If it takes one or more dozens of minutes, you can test from a clean test at best a couple of times an hour.

Longer and you will do it a few times a day at best...

By making local change quickly and testing them locally, you can push them to the central repository more often, reducing the scope of the integration tests running on your CI environment prior to merging to your master branch.

Another way to shorten the feedback loop is by applying the test Pyramid principle to your tests, making sure you have fast Unit tests running as early as possible in your workflow. In practice, this could be running your Unit tests, lint tests, PS Script Analyser tests as often as possible (i.e. at every file changes being saved), before you start more expensive tests. Those test must run almost instantly, or there's little benefit of moving them left in your development flow (quite the opposite, they'd delay feedback).

A word of obvious warning: don't bloat your test suites running early in your development flow, giving you information that's only required later. Optimize your feedback loop!