这是一个旧的 issue，被我从 Hover 项目 issue 中移植过来，留档保存。
2017 年由 杨帆 提出
提议一个原则
- 我们应该大家密集 merge 的 develop 分支里有对应的 CI Jobs;
- 我们应该在对外使用的分支里，使用 CI jobs，比如 release，和 master；
- 我们可以在统一的对 feature 分支创建 CI job, 比如所有的以 feature/* 开头的都自动的创建一个 jobs;
我的理由和原因
- QE 应该拿统一的分支去测试，现在应该是 develop 分支（在 issue #57 有讨论创建一个 release 做这件事情，但是我和伍政还有些分歧，今天我俩再讨论下）
- developers 需要尽早的 merge 不同分支的问题，一个分支能够尽早帮我们 build 是有价值的，这样我们能够尽早知道这些事情;
- 每个大的 feature 很多事情，产品或者测试人员是期望能够提早试用， 所以我觉得应该给他们一个地方可以做这样的事情;
From ChenYuanfu：
现在 ‘Hover_release’ 对应的其实是master分支， 这个CI jobs 只做 master 的编译发布到Apple Store。 我们还需要一个对应 release 分支的 CI jobs ，对release 分支进行打包上传(蒲公英或者是fir)。以后的 master build 应该是由release 分支 ‘approve promotion’ 触发开始。
From MJXin：
在此之前，我留意到 CI 上 iOS 有4个对应版本，能否先简单介绍一下这 4个版本分别对应什么分支及如何使用呢？ 比如：
* iOS_Hover_Apple_Store_Edition_Dev，对应 Apple_Store Demo版本？
* iOS_Hover_Dev，对应 develop 分支？
* iOS_Hover_Release， 对应可能要加入 release 分支？
* iOS_MacBuild_DailyMaintain，这个版本如何维护？
From ChenYuanfu：
当前的：
* iOS_Hover_Dev 对应 ‘develop’ 分支，在 ‘develop’ 分支代码有改动时会立即开始 ‘Build’ 其中包括了打包上传到蒲公英。对应的下载地址是： 。iOS_Hover_Dev 可以开始一个 ‘Promoted build’ , 在一个版本（例如 # 44）编译通过之后，可以在这个版本中的 ‘Promotions’ 中批准一个 ‘Promoted build’。 这个将触发 ‘iOS_Hover_release’ 开始 ‘Build’。
* iOS_Hover_Release 对应的是 ‘master’ 分支，仅仅只能由 ‘iOS_Hover_Dev’ 的 ‘Promoted build’ 批准触发。’iOS_Hover_release’ 被触发会打包上传一个包到App Store。
* iOS_Hover_Apple_Store_Edition_Dev 对应 ‘develop’ 分支，用来给苹果店demo 用的版本 其中的编译条件不同： ‘APPLE_STORE_EDITION=1’ 这是与 ‘Hover_Dev’ 的区别。因为最近没有测试需求，现在是每天晚上会检查一次变化触发。
From MJXin：
今天开发过程中因为是边修 Bug 边提测，有这样的一个流程：
* 打包版本提交测试而后得到反馈。
* 针对反馈信息进行 Bug Fix 及后续开发。
* 打包给测试进行下一轮测试由于目前可供这些提交使用的 CI 只有 develop 分支，所以在开发过程中存在，需要频繁向 develop 发起 MR 来让 CI 打包以提供给测试使用。
而在我的提交中，所有内容其实同属一个 feature，所有提交都是在 fix 其中的 bug。 没必要频繁向 develop 发起 MR。
所以对于第三点：
统一的对 feature 分支创建 CI job
我认为是很有必要的
From MJXin：
目前杭州这边开发流程倾向于模块化，除了会集成入 Hover 中以外，在开发过程中，每个功能模块都是各个独立的 pod spec。
像之前的 Album， 其实就是一个可以完全独立于 Hover 运行的模块，早期内部测试过程中，也是直接抓取用户相册测试其内部功能。对于是否有必要区分北京和杭州的问题，我认为应该没有这个必要。
但正如第三点提到的，对于大的 feature 我认为首先应该考虑是否可以以模块化划分出来，尽量将不同模块独立，并为其建立一个一个 jobs。
From yangfan：
么么哒，明白了。
我觉得是这样，当前的第一步，我应该对于 Hover 这个项目做这样的事情.
但是之后，我们其实是期望每个模块都能更独立，同时能够更独立的 build/test 等等;
我的建议是，CI_CD 其实是一套比较基本的技能，我们应该都简单学习一下，了解原理_Best Practice 之后我们的模块都尽可能的利用这样的流程给大家提供方便.
大家觉得有什么问题和改进的地方么~
From 张晓旭：
我觉得没有什么问题，执行上可以再具体些，比如当前项目里还有许多远程分支是无用且无人清除的，我不希望看到 Jenkins 上也是如此