Onboarding a New Team
Step-by-step rollout — connect repos, set baselines, invite developers, and land first reviews.
A proven sequence for introducing ScanDrix to an engineering team without review fatigue.
Connect and grant (day 0)
Install the integration for your provider and grant 1–2 pilot repositories — not the whole org yet (Quickstart).
Set a conservative baseline
Start with warning severities for style-adjacent rules; keep only genuine security rules at critical. You can tighten later — an untrusted flood of comments in week one loses the team.
Run a Dry Run against history
scandrix rules dry-run --since 30d on the pilot repos. Tune matches until would-be findings are findings your senior engineers agree with.
Enable on pilot PRs (week 1)
Reviews go live on the pilot repos. Ask the team to mark suggestions helpful/not-applicable — feedback records now shape future review passes.
Invite the team (week 2)
Settings → Members — admins configure, members review, viewers read dashboards. Point developers at the CLI for pre-push checks.
Roll out org-wide (week 3+)
Grant remaining repositories, promote the tuned rules to organization scope, and add CI merge gates where you want hard enforcement.
What to communicate to developers
- Reviews usually finish under 60 seconds and never block CI pipelines (async queue).
- Every comment has a rule ID —
/scandrix ignore <rule> --reason ...suppresses with an audit trail. - Patch suggestions apply with one click; Drixy never pushes commits itself.
- Local equivalent:
scandrix review --staged.
Rollout checklist
- Pilot repositories chosen
- Severities set: critical blocks, warning advises
- Dry Run reviewed by an owner of the code
- Team invited with correct roles
- Merge policies configured per repository
- CLI documented in the team's dev-environment README
- Security baseline rules enabled org-wide after pilot week