Here is what we do in my company: `precommit` and `prepush` \#git hooks are used to catch issues before they are pushed upstream. * `precommit` runs only on s

Here is what we do in my company: `precommit` and `prepush` \#git hooks are used to catch issues before they are pushed upstream. * `precommit` runs only on staged files (takes few seconds) * `prepush` runs eslint typescript and unit tests (takes up to 20 seconds) Every time a commit is pushed: 1 ) We build a #docker image & bundle cypress and other development dependencies. This allows us to run all subsequent tasks using the same Docker image. It is fast. Takes 2-4 minutes. 2 ) We run 5 tasks concurrently to validate our build. * ESLint * TypeScript * jest Unit tests * cypress Integration tests * Fetch, validate & compile GraphQL schema 2 ) For every commit, we deploy a review app. Review app: * Allows anyone to preview what is being developed. * Allows anyone to preview our storybook. * Allows to leave visual reviews (WIP) 3 ) Before changes can be merged to the main branch, we use GitLab to mandate at least 1 review from the team. In addition, we use GitLab review system to advise who is the best person to review the code based on which files have changed. 5 ) When changes are merged to the main branch, we automatically deploy to production. We use argocd to implement gitops. This means that we have a detail log of everything that has been deployed, and in case of a critical error, reverting is as simple as "git revert" Receipt 6 ) Finally, we push changes regularly to the main branch. Small incremental updates, dozens of times a day. This means that if things break, they are typically small things and easy to revert / patch. We use feature flags to hide any WIP features.