Milestone map
Milestone map
3 milestones
Automate tests and build on every push
1–2 weeks
Set up continuous integration for a real application. Every push should run tests and a build. Make the pipeline fail when tests fail. A pipeline nobody trusts is worse than none.
Proof required
Link the pipeline config and the run history showing at least one failing run caught by tests and a later passing run.
What gets checked
- Runs on every push and pull request
- Real tests, not a placeholder step
- A failing run shown and fixed
Common mistakes
- A test step that always passes
- Pipeline only runs manually
- Ignoring red builds
Powstik Guide
CI that tests and builds every push.
Steps
- Pick your CI tool and add a config file.
- Install dependencies with a lockfile.
- Run tests, then build.
- Break a test on purpose to prove it fails.
Template
Pipeline stages 1. Checkout 2. Install (cached) 3. Lint 4. Test 5. Build Failing run link: Fixed run link:
What gets sent back
- A placeholder test step.
- Manual-only pipeline.
- No failing run shown.
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Read the pipeline config
- Check a failed run
- Check tests are real
You'll sign in first, then come straight back here.
Deploy automatically to a real environment
1–2 weeks
Extend the pipeline so passing builds deploy to a staging or production environment. Keep secrets in the CI secret store. Every deploy should be traceable to a commit.
Proof required
Link the deploy stage config, a live environment URL, and a deploy log mapping a commit to a release.
What gets checked
- Deploys only after tests pass
- Secrets stored in CI, never in the repo
- Each deploy traceable to a commit
Common mistakes
- Secrets committed to the repo
- Deploying even when tests fail
- No link between commit and deploy
Powstik Guide
Automatic, traceable deploys.
Steps
- Add a deploy stage that needs the test stage.
- Move every secret to the CI secret store.
- Tag each deploy with the commit hash.
- Show the live environment responding.
Template
| Deploy time | Commit | Environment | Result | |-------------|--------|-------------|--------| Secrets list (names only, stored in CI):
What gets sent back
- Secrets in the repo.
- Deploys that skip tests.
- Untraceable deploys.
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Search the repo for secrets
- Check stage ordering
- Match a deploy to a commit
You'll sign in first, then come straight back here.
Prove rollback works under a reviewer
1 week
Add a rollback path and demonstrate it with an engineer watching. Ship a deliberately bad release and recover. A pipeline is only safe if you can undo it fast.
Proof required
Submit the rollback method, timings from the bad release to recovery, and review notes (250+ words) with the reviewer's background and challenges.
What gets checked
- Rollback demonstrated, not just described
- Time to recover measured
- Reviewer has run production deploys
Common mistakes
- Rollback that needs manual server access
- No timing measured
- Reviewer without deploy experience
Powstik Guide
A timed rollback drill with a reviewer.
Steps
- Choose a rollback method: redeploy, blue-green or canary.
- Ship a harmless but visibly broken release.
- Start a timer and roll back.
- Let the reviewer challenge the process.
Template
Rollback drill Bad release commit: Detected at: Rollback started: Recovered at: Total time: Review session log Date: Duration: Reviewer name: Reviewer role and experience: Challenge 1 (the rollback path): What they asked: My answer: Challenge 2: What they asked: My answer: Change I made after the session:
What gets sent back
- Rollback not actually performed.
- No timing.
- A reviewer without deploy experience.
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Check the recovery timing
- Confirm reviewer background
- Read the rollback method
You'll sign in first, then come straight back here.