Continuous Integration & Deployments

We utilize the built-in GitLab CI system to run our tests, linters, spell-checkers 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 having 100% test coverage is the guideline for all projects we work on. All of this is automatically enforced through custom scripts within our CI system.

Linting

In order to guarantee a common style of code, we use open source linters, which inspect the code and match it up against common anti-patterns, our preferred styles, and thus help us make our code uses a common style. To name the most common ones, for Ruby we utilize rubocop, for JavaScript eslint and for CSS scss-lint.

Deployments

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 master or 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.