Continuous Integration & Deployments
We utilize the built-in GitLab CI system to run our tests, linters and some custom scripts for enforcing coverage rules.
Automated Test Suites
In order to guarantee that our test suites are actually used, we run them automatically on all commits that are pushed into the remote repository. The results are then linked to the issue the code belongs to and issues are only merged if (and only if) CI reports an 'all-green' status, that is if all tests run.
In order to enforce testing, all files added to the project must be 100% covered by tests and (with exceptions of some legacy components) 100% test coverage is the guideline for all projects we work on. All of this is automatically enforced through some custom scripts within our CI system.
Our deployments are always either fully or partially automated, that is, they are deployed either by a script or as part of a successful CI run. If they are deployed as part of a CI step, that means that after a successful test-run on
staging they are automatically deployed to production or the staging environment respectively.
For deployments we utilize automated deployment systems (such as capistrano for ruby projects) to allow roll-back to earlier versions if we notice problems.
Generally for most projects deployment responsibility lies with each (full-time) employee working on a project. That is, every employee deploys their own code after a successful code review. We practice continuous deployment and usually deploy features and bug fixes as soon as they are done without slicing releases.