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.
The standard process involves the below steps:
When you push a number of changes to the
masterbranch of your project in GitHub, this will trigger a build in the format
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).
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.
The testing of the build will then take place. We automatically run
yarn run testand
phpunitfor the PHP code (you can find this in
phpunit.xml, and the standard is
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.
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.
hotfix/*branch. It’s requested not to misuse this feature as it can cause CI overload.
- The optionally specified main branch. You must communicate this to our professional service engineer to set this up.
- Any branch is selected randomly by the CI. It’s recommended not to rely on the build order for additional branches.
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:
#build– Triggers an
ant packagein a branch other than the
masterbranch. This can be used to then deploy a branch instead of the master branch.
#clear– Clears all
node_modulesfolders. Since Yarn regularly fails to update all dependencies, we offer you this to manually trigger a fresh dependency installation on the CI server.
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.