Software Development Lifecycle

1. Overview

This document describes how ManageYourTax is built, tested, deployed and maintained. It is published to provide transparency to customers, auditors and partners — including our Consumer Data Right Principal — about how changes reach production.

2. Source control

• All application code is stored in Git, hosted on GitHub
• main is the production branch; only reviewed code reaches it
• Feature work happens on short-lived branches merged via pull request
• Commits use conventional commit prefixes (feat, fix, chore, etc.) for traceability
• Secrets, credentials and customer data are never committed to source control

3. Code review

• Pull requests are reviewed before merge. Reviewers check correctness, security posture, test coverage, type safety and adherence to the project's conventions
• Security-sensitive areas (authentication, authorisation, CDR data handling, payment processing) receive heightened review
• Changes to Firestore Security Rules are reviewed by a maintainer with cross-tenant isolation in mind and tested before deployment

4. Static analysis & type safety

• The codebase is written in TypeScript with strict mode enabled. The production build fails on any type error
• Linting runs locally and in CI; format and style violations block merge
• A CI guardrail prevents reintroduction of legacy client-side Firebase auth methods, ensuring sign-in continues to route through the audited platform OAuth flow

5. Testing

• Unit and integration tests are written in Vitest. The test suite covers the accounting engine, BAS calculator, GST reconciliation, payroll, billing, report generation, API routes and authentication flows
• 500+ automated tests run on every change; failing tests block merge
• New features and bug fixes are expected to add or update tests covering the changed behaviour

6. Continuous integration

• GitHub Actions runs the build, type-check, lint, security guardrail and full test suite on every pull request and on main
• A change cannot reach production until all checks pass

7. Deployment

• Production deployments target Google Cloud Run (Sydney) for application services and Firebase Hosting for the customer-facing edge
• Cloud Run uses revision-based deployments: every release creates a new immutable revision. Traffic is shifted only after the revision is healthy
• Firestore Security Rules are deployed as a discrete artefact; rule changes are versioned and reviewed independently from application code
• Deployments are initiated by an authenticated administrator from a managed workstation

8. Rollback

Because every release is an immutable revision, rollback is a single command: we pin traffic back to the last-known-good Cloud Run revision and roll Firebase Hosting to a prior version. Firestore Security Rules can be reverted to any previously deployed version via the Firebase console.

9. Dependency management

• Production dependencies are pinned in package-lock.json for reproducible builds
• Dependencies are scanned for known vulnerabilities. Security advisories are triaged on receipt and patched promptly, with the urgency determined by exploitability and exposure
• New runtime dependencies are reviewed for licence, maintenance posture and security history before adoption

10. Secret management

Runtime secrets (API keys, third-party credentials, signing keys) are stored as Cloud Run environment variables, scoped to the relevant service, and never committed to source control. Local development uses an .env.local file that is excluded from version control and from the production build context.

11. Change records

Every production change is recorded in the public Git history with a descriptive commit message, traceable to the deploying revision. This provides an audit trail of who changed what, when, and why, and supports incident analysis, compliance review and customer support.

12. Contact