iOS用于iOS开发的分支模型。 与Bitrise持续集成

当我开始在目前的公司工作时,我们为iOS平台准备的设置完全在本地托管:用于回购的Bitbucket Server ,作为构建平台的Jenkins和用于分发的Hockeyapp自己实现(据我了解,从Hockeyapp是一个开源项目的过去)。 所有这些都由外部机构(开发我们的应用的机构)负责。

我被分配的首要任务之一是这些服务的内部化,以便变得独立并控制开发周期。

为了托管存储库,我们将使用Bitbucket CloudHockeyapp进行分发,但是由于我们公司根本不托管任何服务器(我们的基础架构主要在AWS的保护下运行),因此不能选择照旧执行Jenkins实施。 我当时在寻找新的云CI / CD平台

iOS云连续集成服务器奥运是一个很好的起点。 由于我们不是在开发仅限iOS的应用,因此未考虑buddybuild。 经过研究后,两个最终入围者是CircleCIBitrise

初始步骤

我最初的选择是CircleCI,但即使我遵循了一些教程,但也无法使签名生效。 它可能比Bitrise提供更多的自定义功能,但是对于一个不知道他在做什么的人来说,像Bitrise那样拥有一个构建模块界面在这样的早期阶段是关键

客户服务部门也迅速回答了我的问题,这也是迁移到Bitrise的另一个原因。

在链接了所有步骤(基本上使用了Bitrise推荐的模板)之后,构建平台就可以正常工作了。

局限性

我们有三个主要工作流程:暂存,候选发布和分发。

暂存和发行候选人将在我们的develop分支中建立,而发行将在master建立。

当几个主要功能准备好以更成熟的状态集成在一起,从而触发候选发布版本时,将应用相同的方法。 从betarelease将会执行手动合并,从而生成一个新的候选版本的应用程序。

此发行候选版本可能会被发送到iTunes Connect 。 如果最终测试和审核过程令人满意,则将发布该应用程序,并进行从releasemaster release的手动合并, 包括带有版本号的标签理想情况下 master 分支将包含在AppStore中发布的所有应用程序版本,并带有正确标记

  ➜git checkout主 
➜git tag v.1.2#举例
➜git push-标签

所有不同版本都会生成两个.ipa文件,一个针对我们的暂存后端,另一个针对我们的实时服务。

为了使我们(和我们的测试人员)更容易知道哪个版本针对什么,我们分配了不同的应用程序图标,包括版本名称和后端环境:

这些应用程序已上载到HockeyApp,我们的测试人员团队可以在其中查看和下载它们。

这就是我们当前的设置。 谢谢阅读! ✌️