# Continuous integration

Automatically test, build, and deploy your website with continuous integration.

We offer continuous integration (CI) as a standard feature. Our CI covers the test, build, and deployment of your website. We recommend using your own CI service to have a more granular control on the build steps.

In this document, you'll learn how the continuous integration process works for deploying to the staging environment. The same steps occur for the [branch deployments](/frontend-development/deployment.md#branch-deployments) as well.

If you are using a [custom Git repository](/frontend-development/set-up-custom-repository.md), you must set up a CI yourself.

## CI steps

The CI standard process involves the following steps:

1. [Trigger](/frontend-development/continuous-integration-ci.md#trigger)
2. [Test and build](/frontend-development/continuous-integration-ci.md#test-and-build)
3. [Notifications](/frontend-development/continuous-integration-ci.md#notifications)
4. [Staging deployment](/frontend-development/continuous-integration-ci.md#staging-deployment)

This CI process completion time depends on the amount of code and tests in your repository. It can take up to 20 minutes to finish.

### Trigger

When you push changes to the `master` branch of your project in GitHub, this triggers a build in the format `Y.m.d.H.i`. A build runs on the latest commit on the `master` branch. If you push multiple commits together, the build will run only for the latest one.

Only one build is executed at a time. If two commits are pushed at about the same time, the second build will start after the first one is finished.

The build versions ending with `-test` are only for test validation and cannot be deployed.

You can check the build logs from **Developer > Continuous Integration** area in the Studio. To learn more, see [View build logs](/frontend-studio/using-the-ci-area.md#view-build-logs).

### Test and build

The CI performs the following steps in a standard Node.js Docker container with the `CI` environment variable set to `true`:

1. If a `yarn.lock` file is available at the repository root level, run `yarn install` there.
2. In the backend directory of every project (`packages/*/backend`), perform the following steps:
   1. Run `yarn install`.
   2. Run `yarn run lint`. On failure, mark the build failed, and continue with the next project.
   3. Run `yarn run test`. On failure, mark the build failed, and continue with the next project.
   4. If the `build-action` is `test`, mark the build successful, and continue with the next project.
   5. Run `yarn build`. On failure, mark the build failed, and continue with the next project
   6. Upload the build file (`build/*.js`) and the build map file (`build/*.js.map`) to the deployment server as build artifacts.

Even if only one project build fails, the whole CI process is marked as failed. Although, the artifacts for succeeding project builds might still be uploaded.

### Notifications

After finishing the build, the CI updates the build status on GitHub. If set up, you will also get the build result in your Slack or Microsoft Teams channel.

### Staging deployment

The build is deployed to the staging environment.

## Related pages

- [Area overview page with navigation](/frontend-development.md)
- [Previous page: Overview](/frontend-development/deployment.md)
- [Next page: Go-live preparation](/frontend-development/go-live-preparation.md)