Continuous integration of SAP e-commerce cloud Spartacus UI-Continous integration

Before integrating the code into our main line of development, a continuous integration process is run to prove that changes can be integrated safely.

We use Travis CI for our continuous integration service.

Every time the code is pushed to the Spartacus repository (regardless of whether a pull request has been issued), a build in our public Travis CI is triggered. For all our libraries, the build performs the following steps:

• Check for prettier compliance
• Check tslint compliance
• Run all unit tests
• Run Sonar check
• Build the Spartacus project source
• Release snapshot build

The configuration built by Travis CI can be found in the .travis.yml file in the root directory of the Spartacus project.

End-to-end testing

When the build is triggered, a parallel process is also triggered on the Jenkins server, which runs all the end-to-end (E2E) tests of our library. The E2E test result is reported as passing or failing the Pull Request check on GitHub.

Unfortunately, the Jenkins server is currently not public, so external contributors cannot see the E2E test results. We hope to transition to a public server in the near future.

Contributing Integration Libraries to Spartacus

The following integration libraries are released by the Spartacus core team, but are owned by the relevant integration team:

• Context-Driven Services
• Configurable Products
• CPQ Configurable Products
• SAP Customer Data Cloud
• SAP Digital Payments

Integration Library Guidelines

For any team contributing integrated libraries to Spartacus, the following guidelines are recommended:

• For example, you should have your own separate branch in the Spartacus repository, such as integration/cds.
• You should merge as many of the latest changes from the development branch as possible (to avoid merge conflicts).
• You need to add the build, verification, and test steps to the .travis.yml file on the branch so that you can describe your continuous integration process. You need to include the tests and verifications that you think are necessary for continuous integration of the library.
• You don't have to run all Spartacus core verifications during the CI process (although this may be recommended).
• When attempting to merge the integrated library itself into the main development branch of Spartacus (or merge new changes into the development branch), the core team will fully verify it, including regression testing. This will not include integration testing. As the owner of the integration library, you need to ensure that your integration is stable and that it passes all the requirements to be released.
• After the integrated library is released, you are responsible for maintaining its stability in subsequent versions.

Reasoning Behind This Approach

Spartacus is built on Travis CI. The necessary build steps are described in the travis.yml file, and only one build file is supported per branch. Therefore, setting up separate branches for specific integrations allows each integration team to customize their build.

The Spartacus team does not have enough bandwidth to run all verification and testing of each integrated library as part of each build. At the same time, the integration team should not need to run verification of all core Spartacus code.