Documentation

Continuous Integration

We offer Continuous Integration (CI) as standard, which can be extended to some degree. As our CI is only basic, we really recommend using your own CI service if you want to add more sophisticated build steps.

CI steps

The standard process involves the below steps:

  1. Trigger
    When you push a number of changes to the master branch of your project in GitHub, this will trigger a build in the format Y.m.d.H.i.
Information icon

Only 1 build can be run at a time. If 2 different developers commit around the same time, 1 build will run first, and then the 2nd will begin once the 1st build has finished. The 2nd build will run on the most recent state of the master branch, not for every push individually.

You can follow the progress of your build within the studio (click Developer, then Continuous Integration).

fd2b3f3 Continuous integration list

Information icon

If you see a build number and it ends with -test, this isn't a full build and is only executed for test validation. It's not possible to deploy this version.

  1. Testing
    The testing of the build will then take place. We automatically run yarn run test and yarn run check for JavaScript (you can find these tests in your package.json), and phpunit for the PHP code (you can find this in phpunit.xml, and the standard is test/php/)

  2. Building
    The JavaScript and CSS assets are then compiled. The new asset version is also linked from the default template. All of this is then committed all together into master as the new build commit.

  3. Announcing
    Once the build has finished successfully, the results will be available in the studio, and the status in GitHub will also be updated. You'll also get the build result from your Slack channel or MS Teams channel.

  4. Staging deployment
    If all of this is successful, your new build will then be deployed to your staging environment, and new Google Cloud instances will be brought up there.

This process can take anywhere between a few minutes to 20 minutes from start to finish. But it depends on how much code you have in your repository and the additional tests you've added.

CI build prioritization

Your project will have many branches to build at a point, and the CI prioritizes it in the following order.

  1. Any hotfix/* branch. It’s requested not to misuse this feature as it can cause CI overload.
  2. The master branch.
  3. The optionally specified main branch. You must communicate this to our professional service engineer to set this up.
  4. Any branch is selected randomly by the CI. It’s recommended not to rely on the build order for additional branches.

Commands

You can use your commit message to trigger some actions. Please note that the CI server only checks that last commit message, so if you push multiple commits at once, make sure the string is in the last commit message.

Embed the below string in your commit message:

  • #package or #build – Triggers an ant package in a branch other than the master branch. This can be used to then deploy a branch instead of the master branch.
  • #clear – Clears all node_modules folders. Since Yarn regularly fails to update all dependencies, we offer you this to manually trigger a fresh dependency installation on the CI server.

What next?

You'll then need to test your new build in the staging environment yourself, and once you're ready, you can use the studio to deploy to production. See the deployment article for more information.