Work
Engineering the developer feedback loop
Engineering the developer feedback loop
Three independent developer tools for a common engineering problem — make feedback faster, test priorities clearer, and delivery policy easier to inspect.
Impact & evidence
Inspect the source, tests, and usage documentation
Independently authored and maintained; public source is the evidence.
CI/CD & Developer Tooling
bb-run (source, opens in a new tab)
Run Bitbucket Pipelines locally from your existing pipeline file before pushing.
Python / Source, tests & documentation
Quality & Testing
testrisk (source, opens in a new tab)
Rank the highest-value Python test gaps from coverage, AST, and git churn.
Python / Source, tests & documentation
Policy-as-Code & Security
pipeguard (source, opens in a new tab)
Policy-as-code validation and rule enforcement for Bitbucket Pipelines.
Go / Source, tests & documentation
On this page
Problem
- Pipeline failures are expensive to discover only after pushing a commit.
- Delivery policies and environment assumptions are difficult to maintain when they live only in documentation.
- Coverage alone does not tell engineers which test gaps deserve attention first.
Decisions
- Build focused tools with explicit inputs and outputs rather than one all-purpose developer platform.
- Use Python for local pipeline workflows and test-risk analysis, and Go for pipeline policy validation.
- Keep usage, implementation, and tests available in public repositories so the work can be inspected.
Evidence
Outcome
- Three public tools covering local CI, test-risk analysis, and policy checks.
- Source code and usage documentation provide technical proof beyond a portfolio description.
The common thread is the feedback loop around software. A pipeline definition, test report, or deployment policy is useful only when engineers can exercise it and understand the result. These projects approach that problem at different layers.
bb-run: local feedback
bb-run runs Bitbucket Pipelines locally from an existing pipeline file. It moves a portion of the commit-push-fail loop onto the workstation. Local execution is a development aid, not a replacement for authoritative CI.
testrisk: test priorities
testrisk combines coverage, code structure, and git churn to help prioritize Python test gaps. A risk ranking directs attention; it is not a substitute for checking behavior.
pipeguard: delivery policy
pipeguard checks pipeline definitions against policy. It makes delivery constraints inspectable alongside the configuration they govern. Its repository documents the supported rules and invocation.
These tools address complementary developer-platform concerns. Each has its own boundary, documentation, and implementation.
What to inspect
Start with the README and supported inputs, then follow the implementation and tests. Look for how errors are reported, how configuration is represented, and which assumptions the tests actually exercise.