Coveo application change control process

When it comes to improving its products and services, Coveo has a rigorous application change control process in place. To ensure that the quality of each release, Coveo requires any change to go through a strict validation and approbation protocol at every step of the process. All development teams at Coveo follow this protocol when making changes to Coveo and related products, and therefore all source code modifications undergo an exhaustive series of automated and/or manual tests before their release to customers. This page offers an overview of the application change control process in place at Coveo.

A change request is tracked from the moment it’s submitted to Coveo. It’s then prioritized, and the changes to make are designed and planned as part of a development roadmap. As a result, the source code can’t be edited without justification and preparation, and any change leaves a trace.

After a developer is done with a task, they submit their work to their peers and collaborators, who can then comment it and make recommendations. Once the reviewers are satisfied with the developer’s work, they approve it. While the changes are being reviewed, they also undergo a series of automated tests. From then on, at any step of the change control process, if an approval condition isn’t met, the author of the changes must fix the problem, and then their new code must then go through each step of the process again.

The change control process requires code changes to be tested in two internal environments before they’re deployed in production and accessible to customers. Once a change is approved by its reviewers and has passed the automated tests, it’s deployed in an internal development environment for more testing. Unit tests, functional tests, and integration tests are run on the environment to ensure that the new code is working as expected as well as to confirm that no regressions have been introduced. This test protocol is monitored by at least one developer.

In addition, Coveo performs at least the following compliance and security tests on all code changes:

Once the deployment and all tests are successful, a manual approval is required to deploy the build, that is, the compiled changes, to the quality assurance (QA) environment. In particular, for a build to be approved, its vulnerability and virus scan must be negative, and its Observatory score must be B+ or higher (see Observatory by Mozilla). Any build not meeting one of these criteria is rejected. The author of the changes must then modify their code so that all requirements are satisfied after a new series of tests.

About once every week, builds that were approved following the compliance and security tests as well as the development environment tests are deployed in the quality assurance (QA) environment. A date is determined for the next product release, which will consist of these builds. Just like in the development environment, each release build undergoes a series of rigorous automated tests. Moreover, the QA team tests the build manually using exhaustive tests plans to ensure that no regressions have been introduced and that the features impacted by the changes behave as expected.

Once the deployment and tests in the QA environment are successful, a final approval from the QA team is required for the build to be deployed to the production environment. Builds that don’t meet the final approval criteria are excluded from the release so that the author of the changes can look into the problem and make adjustments.

The production environment is the only environment that Coveo customers can access. On the chosen date, the release is deployed to the production environment and, over the course of several hours, traffic is progressively transferred to the new version of this environment. New features are announced on the New Coveo Platform features page and the related documentation is published on docs.coveo.com.

Once again, validation and integration tests are run on the deployed changes to ensure that the new code is working as expected as well as to confirm that no regressions have been introduced. The QA team may conduct additional manual tests as well, and developers may also double-check that their work behaves as expected.

After a project is completed, some teams hold a retrospective meeting involving the developers who worked on the project, the team leader, and the product manager. The goal of this meeting is to discuss issues encountered over the course of the project and possible improvements for future work.

Thanks to its microservice architecture, Coveo releases new features several times a week, one service at a time. Coveo favors small, frequent releases over a large release once every few months. By keeping its releases small, Coveo minimizes the risk of inadvertently introducing unexpected behaviors to preserve the stability and security of its products. In addition, smaller builds are easier to test, which means that Coveo can respond to customers' needs in a timely manner.

Introducing breaking changes in a release is actively avoided. In the rare event where such changes would be inevitable, Coveo would inform impacted customers before the release. Similarly, if breaking changes were ever inadvertently introduced and discovered after a release, Coveo would immediately undertake emergency corrective actions to resolve the issue, either by rolling back to the previous version if possible or by issuing an emergency hotfix.

The Status page is updated regularly to inform customers of any incident affecting Coveo. Customers can subscribe to updates to receive communications as soon as they’re available. For more information on the services Coveo offers, see Services.