在将代码集成到咱们的开发主线之前，会运行一个继续集成过程以证实能够平安地集成更改。

咱们将 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 代码运行验证。