Software Development Lifecycle

1. Overview

This document describes how AccountsAndGo 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; changes reach it via pull request
• 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

• Changes are made via pull request. Reviews 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 particular scrutiny
• Changes to Firestore Security Rules are checked with cross-tenant isolation in mind and tested before deployment
• Separation of duties: the team is small, so the same individuals both write and deploy code. We compensate with comprehensive logging, an immutable audit trail, and a planned independent control assessment, rather than implying a separation that does not yet exist

4. Static analysis & type safety

• The codebase is written in TypeScript with strict mode enabled. The production build fails on any type error
• Linting and formatting are run locally; the production build (run in CI) fails on any type error
• 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
• A suite of 690+ automated tests is run locally before release
• New features and bug fixes are expected to add or update tests covering the changed behaviour

6. Continuous integration

• GitHub Actions runs the production build (which type-checks the codebase) and a security guardrail (blocking legacy client-side auth methods) on every pull request and on main
• Deployment to production is a separate, manual step (see Deployment) — it is not triggered automatically from CI

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 deployed independently from application code
• Production deployment is a manual step (gcloud run deploy), initiated by one of a small number of named administrators from a managed workstation; deploy access is limited to those individuals

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
• Automated dependency and code scanning (Dependabot, CodeQL, secret scanning) is being implemented in CI. Security advisories are triaged on receipt and patched promptly, with 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 held in Google Secret Manager, scoped to the relevant service and injected at deploy time, 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