掌握Git与CI/CD创建有效的开发工做流程

一个有效且组织良好的现代软件项目没有持续集成和持续交付/部署很难想象。很难想象没有某种形式的版本控制系统（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