在将代码集成到我们的开发主线之前，会运行一个持续集成过程以证明可以安全地集成更改。

我们将 Travis CI 用于我们的持续集成服务。

每次将代码推送到 Spartacus 存储库时（无论是否已发出拉取请求），都会触发我们公共 Travis CI 中的构建。对于我们所有的库，构建执行以下步骤：

• 检查更漂亮的合规性
• 检查 tslint 合规性
• 运行所有单元测试
• 运行 Sonar 检查
• 构建 Spartacus 项目源
• 发布快照构建

Travis CI 构建的配置可以在 Spartacus 项目根目录的 .travis.yml 文件中找到。

端到端测试

触发构建时，还会在 Jenkins 服务器上触发并行过程，该服务器运行我们库的所有端到端 (E2E) 测试。 E2E 测试结果报告为通过或未通过 GitHub 上的 Pull Request 检查。

遗憾的是，目前 Jenkins 服务器未公开，因此外部贡献者无法看到 E2E 测试结果。我们希望在不久的将来过渡到公共服务器。

Contributing Integration Libraries to Spartacus

以下集成库由 Spartacus 核心团队发布，但归相关集成团队所有：

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

Integration Library Guidelines

对于向 Spartacus 贡献集成库的任何团队，建议遵循以下准则：

• 例如，您应该在 Spartacus 存储库中有自己的单独分支，例如 integration/cds。

• 您应该尽可能多地合并来自开发分支的最新更改（以避免合并冲突）。

• 您需要将构建、验证和测试步骤添加到分支上的 .travis.yml 文件中，这样您就可以描述您的持续集成过程。您需要包含您认为对库的持续集成所必需的测试和验证。

• 您不必在 CI 过程中运行所有 Spartacus 核心验证（尽管可能会建议这样做）。

• 在尝试将集成库本身合并到 Spartacus 主开发分支（或将新更改合并到开发分支）时，核心团队将对其进行完整验证，包括回归测试。这将不包括集成测试。作为集成库所有者，您需要确保您的集成是稳定的，并且它通过了要发布的所有要求。

• 集成库发布后，您有责任在后续版本中保持其稳定。

Reasoning Behind This Approach

Spartacus 建立在 Travis CI 之上。 必要的构建步骤在 travis.yml 文件中进行了描述，并且每个分支仅支持一个构建文件。 因此，为特定集成设置单独的分支允许每个集成团队自定义他们的构建。

Spartacus 团队没有足够的带宽来运行每个集成库的所有验证和测试作为每个构建的一部分。 同时，集成团队也不应该需要对所有核心 Spartacus 代码运行验证。