Putting CI checks before a change becomes a release

CI/CD is easy to describe as “automation that deploys code,” but the more valuable part comes earlier: it creates a repeatable way to catch a mistake before it becomes somebody else’s problem.

For Ledgerlane, the workflow is split into two gates. Continuous integration runs on every pull request and on pushes to main and staging. Deployment is a separate workflow, with staging deploying from its branch and public environments requiring a deliberate manual release from main.

What CI checks

The CI workflow installs the exact locked dependencies, then runs linting, TypeScript checks, unit tests, Firebase security-rule tests, deployment-guard tests, environment-rule tests, and builds for demo, production, and marketing.

That order is intentional. Fast feedback comes first, while the later checks prove that the application compiles and that the environment boundaries still behave as designed. The security-rule tests matter especially here: a rule can look sensible in a review yet still allow an unwanted read or write when it meets a real request.

Why run this before committing or merging

Local checks are the quickest place to find a typo, a type mismatch, a broken import, or an accidental change in behaviour. CI adds an independent, clean environment that uses the lockfile and runs the same checks consistently for every change. It reduces the chance that a feature works on one machine because of cached files, an overlooked environment setting, or a dependency version that nobody else has.

This does not replace review or careful design. It gives both a better starting point. Instead of discovering a basic build failure after deployment, the team can spend its review time on the workflow, the data boundaries, and whether the feature actually solves the right problem.

The deployment side

Passing CI does not automatically publish every branch. The deployment workflow repeats the important verification and security-rule checks, builds only the selected environment, and deploys through an explicit target. Each GitHub environment has its own scoped Firebase service account, so a credential intended for demo or staging cannot quietly deploy to production.

After deployment, a smoke check confirms that the expected artifact is live on both the Firebase origin and the intended custom domain. The previous Hosting release is recorded before publishing so there is a known rollback point if the release needs to be reversed.

The trade-off

These checks add minutes and require maintenance whenever the project changes. They can also produce failures that need investigation rather than a quick bypass. That friction is useful: it makes a risky change visible while the change is still small and easy to understand.

For a product that stores invoice records and proof files, a reliable release path is part of the feature. Catching errors before a commit is merged or a deployment runs is cheaper, calmer, and far safer than discovering them in a live workspace.