一个有效且组织良好的现代软件项目没有持续集成和持续交付/部署很难想象。很难想象没有某种形式的版本控制系统（VCS）的任何项目，其中最流行的是Git。
在本文中，我将讨论这些因素如何相互影响，经历设计它们的设置的思考过程，并指出一些特定于Android的优化。
VCS工作流程与CI / CD之间的互连
让我们回顾一下我们需要CI / CD的主要内容：
- 运行测试。
- 部署/发布。
但是，等等，我们可以手动完成所有操作，那么使用它的真正原因是什么？原因是我们可以指定自动执行这些操作的条件。
这给我们带来了巨大的好处：
- 保证测试能够运行，这使我们对发布的产品更有信心，并为开发人员对其代码提供了更多信心。
- 因为运行测试不再是开发人员的责任（在大多数情况下），所以他要记住的事情就更少了。这使他可以更加专注和减轻压力。
- 反馈循环可以像我们想要的那样快，这使我们能够快速解决问题。
- 发布会减少工作量，准备工作和风险，因为部署是自动化的，并且所有问题/冲突都可以事先解决。
- 由于发行变得越来越难管理，因此发行频率可能会更高。这为我们带来了快速的迭代和快速的用户反馈。
听起来不错吧？但是，让我们回想一下使用CI/CD的原因。我提到了两个主要词：“条件”和“自动”。猜猜，谁负责第一个？这是您的VCS！或更确切地说，它的工作流程。
您的VCS模型定义了可以设置运行各种自动化任务的条件。当然，这也取决于所选CI解决方案的功能集。但是它们倾向于提供相似的功能，只是形式不同。
这是设计开发工作流程时必须问自己的问题：
- 您想在什么时候推出新版本？您需要多快迭代一次？您的应用程序是否有多个分发（例如，alpha，beta，稳定版）？
- 您是否有只希望针对代码库的某些状态运行的特定测试？还是只是想分别运行越来越少的较大和较小的测试套件？
- 您想多久运行一次测试？您是否需要一个快速反馈回路，并进行频繁的可靠性测试？
- 还是优先考虑快速前进，因此，开发人员需要花费更少的时间等待CI构建完成？
- 您是否有任何时间或容量限制来运行构建？您是否可以使用某些特定的VCS设置来优化这些内容？
牢记所有这些，并了解您的工作流程设计的重要性，让我们来看看使用最受欢迎的VCS-Git时的选择。
剖析Git工作流程
在这里，我们仅讨论各种分支模型以及它们如何与CI/CD一起使用。关于合并vs变基vs squanch壁球的讨论不在本文讨论范围之内，因为这并不会真正影响CI功能。
GitFlow
Gitflow是一种非常流行的工作流程，它定义了以下类型的分支：
- master包含生产代码。
- develop：包含最新的开发更改，这些更改将包含在下一版本中。
- 功能分支：为我们使用的每个新功能创建一个新分支。我们从开发开始，一旦完成，就合并回去。
- 版本分支：从开发开始，表示一旦将该分支合并到master中，就会有一个新版本。
- 修补分支：当我们需要对生产应用程序进行紧急更改但开发尚未准备好生成发行分支时使用。从master开始，并合并为master和develop。
此工作流程的基本CI/CD设置如下所示：
- 在除master以外的所有分支上运行自动化测试。
- 每次合并到master后进行部署。
GitHubFlow
Gitflow是一个实体模型，尽管不是最简单的模型。学习它需要花费时间，并且由于需要进行大量操作，因此需要花费时间将代码库从一种状态转移到另一种状态。
随着GitHub的兴起，他们共享了自己的工作流程。它只是简单地说：“为每个新功能从master创建一个新分支，然后合并回去”。这样，根据您为部署做准备的方式，修补程序将成为另一个功能分支，而develop分支将被忽略，发行版可能不存在，或者也不是功能。
该模型可能不像以前的模型那么复杂，但是却带来了一个杀手级功能- 简单性。
GitHub Flow具有较大优势的另一个地方是开源软件。使用Gitflow的开放源代码项目有两个错误的选择-默认情况下，向访客和贡献者显示很少更新的master分支或非生产质量的development分支。
此工作流程的基本CI / CD设置如下所示：
- 在所有分支上运行自动化测试。
- 在每次合并到master或每次创建指定标签后进行部署。
GitLabFlow
GitHub Flow出现不久后，似乎开始出现了每一个VCS值得尊敬的Web服务都应该有一个以它命名的工作流。因此，GitLab Flow诞生了。
它建立在GitHub Flow的基础上，旨在解决更复杂的部署逻辑的需求，而不是每次将代码合并到master分支时都这样做。
这些要求可以是：
-
由于某些外部条件（应用程序评论（App Store），部署窗口），无法随意部署。
- 多个环境（测试，预生产，生产）或多个分发渠道（alpha，beta，稳定版）。
一次支持多个应用程序版本。
此工作流程的基本CI / CD设置如下所示：
- 在所有分支上运行自动化测试。
- 根据具体策略进行部署-可以从主分支，生产分支或多个分支进行部署。
自定义工作流程
不要害怕提出自己的定制工作流程！如果您觉得除了在线上找到的任何其他模型以外，还需要其他东西，请继续修改现有模型或从头开始创建新模型。互联网上没有人比您更了解您团队和项目的要求！
设计工作流程
在为应用程序（尤其是Android应用程序）创建工作流时，请仔细考虑一下。
开始
一个不错的起点是我们之前探讨的Git模型之一。
通常，在以下情况下，GitHub Flow可能是更好的选择：
- 您希望经常发布（对于Android系统，通常每天发布，甚至每天发布）。
- 您有一个开源项目。
- 您不确定您的要求。从简单开始并随后扩展比从复杂系统开始总是容易的，后者以后将很难拆除。
在以下情况下考虑使用GitLab Flow：
- 您对部署时间有限制。
- 您需要独立发布几种应用程序版本（例如，alpha，beta，稳定版）。
- 您需要同时支持多个应用程序版本。
最后，在以下情况下考虑Gitflow：
- 您的发布应该很少（每周或更罕见）。
- 您可能经常需要等待一段时间才能将候选版本合并到master中，但是 与此同时继续研究新功能。
- 您需要同时支持多个应用程序版本。
最佳化
我们始终希望尽可能减少CI构建的执行时间，以快速查看反馈并向前发展。有时，这样做的原因也是构建时间限制。例如，如果您使用的是免费套餐。而且由于Android版本可能会花费大量的时间，因此这个问题变得更加严重。
有几种方法可以减少构建时间：
- 完全不需要时，不要触发它们。
- 查找需要大量时间但在某些情况下可以省略的任务。
- 针对特定情况自定义任务。有时，我们可以为同一任务设置不同的配置，而这会花费不同的时间。
现在来看具体的优化示例：
- 由于我们只想构建有意义的代码，因此运行CI仅针对请求构建。通常，可以在CI设置中启用此设置。
- 为从未包含或未经测试的代码的分支跳过CI。例如，如果不需要在每次更改时都进行部署，则可以跳过master分支。只需确保在合并之前将任何新分支重新建立到主分支上即可。
- 缓存您的Gradle文件。通过避免在不更改依赖项的情况下下载它们，可以节省大量时间。
- 在其他情况下，使用
assembleRelease和assembleDebug代替bundleRelease和bundleDebug。您会节省一些时间，因为生成APK的速度比捆绑包快。
工作流程的其他最佳做法
- 始终使用拉取请求。
- 总是写好提交信息。
- 使用语义版本控制。
结论
让我们概述一下我们学到的要点。
VCS和CI/CD是现代开发过程的组成部分。我们已经讨论了它们为什么以及如何相互影响，使用它们需要了解的基础知识，以及一些需要记住的特定于Android的技巧。因此，请牢记所有这些，在进行项目之前，您应该始终花一些时间来设计能够反映产品和团队需求的工作流程。
DevOps流水线实践教程已上线，需要的同学可以点击链接获取哦。
https://edu.51cto.com/sd/36f6e