11、持续集成与自动化验收测试全解析

持续集成与自动化验收测试全解析

1. 开发工作流

在软件开发中，不同的开发工作流对持续集成过程有着重要影响，常见的工作流有以下几种：
- 基于主干的工作流（Trunk-based workflow） ：这是最简单的策略。项目有一个中央仓库，所有变更都提交到这个名为“主干”或“主分支”的单一入口。团队成员克隆中央仓库到本地，直接将变更提交到中央仓库。这种工作流的问题在于，如果每个人都向主代码库提交代码，管道经常会失败。按照旧的持续集成规则，“如果构建失败，开发团队应立即停止手头工作并修复问题”。
- 分支工作流（Branching workflow） ：代码被存放在多个不同的分支中。当开发者开始开发新特性时，从主干创建一个专用分支，并将所有与特性相关的变更提交到该分支。这样多个开发者可以在不破坏主代码库的情况下开发一个特性。特性完成后，开发者从主分支重新设置特性分支的基准，并创建一个包含所有特性相关代码变更的拉取请求，经过代码审查和系统检查后，将代码合并到主代码库。不过，这种工作流虽然解决了主干损坏的问题，但引入了新问题：如果每个人都在自己的分支上开发，那么集成在哪里进行呢？一个特性通常需要数周或数月才能开发完成，在此期间分支并未集成到主代码中，因此不能真正称为“持续”集成，而且还需要不断进行合并和解决冲突。
- 分叉工作流（Forking workflow） ：在开源社区非常流行。每个开发者都有自己的服务器端仓库，这些仓库技术上是相同的。分叉意味着从另一个仓库创建一个新仓库，开发者将代码推送到自己的仓库，需要集成代码时，向其他仓库创建拉取请求。其主要优点是集成不一定通过中央仓库