iOS用于iOS开发的分支模型。 与Bitrise持续集成
当我开始在目前的公司工作时,我们为iOS平台准备的设置完全在本地托管:用于回购的Bitbucket Server ,作为构建平台的Jenkins和用于分发的Hockeyapp自己实现(据我了解,从Hockeyapp是一个开源项目的过去)。 所有这些都由外部机构(开发我们的应用的机构)负责。
我被分配的首要任务之一是这些服务的内部化,以便变得独立并控制开发周期。
为了托管存储库,我们将使用Bitbucket Cloud和Hockeyapp进行分发,但是由于我们公司根本不托管任何服务器(我们的基础架构主要在AWS的保护下运行),因此不能选择照旧执行Jenkins实施。 我当时在寻找新的云CI / CD平台 。
iOS云连续集成服务器奥运是一个很好的起点。 由于我们不是在开发仅限iOS的应用,因此未考虑buddybuild。 经过研究后,两个最终入围者是CircleCI和Bitrise 。
初始步骤
我最初的选择是CircleCI,但即使我遵循了一些教程,但也无法使签名生效。 它可能比Bitrise提供更多的自定义功能,但是对于一个不知道他在做什么的人来说,像Bitrise那样拥有一个构建模块界面在这样的早期阶段是关键 。
客户服务部门也迅速回答了我的问题,这也是迁移到Bitrise的另一个原因。
在链接了所有步骤(基本上使用了Bitrise推荐的模板)之后,构建平台就可以正常工作了。
局限性
我们有三个主要工作流程:暂存,候选发布和分发。
暂存和发行候选人将在我们的develop
分支中建立,而发行将在master
建立。
当几个主要功能准备好以更成熟的状态集成在一起,从而触发候选发布版本时,将应用相同的方法。 从beta
到release
将会执行手动合并,从而生成一个新的候选版本的应用程序。
此发行候选版本可能会被发送到iTunes Connect 。 如果最终测试和审核过程令人满意,则将发布该应用程序,并进行从release
到master
release
的手动合并, 包括带有版本号的标签 。 理想情况下 , master
分支将包含在AppStore中发布的所有应用程序版本,并带有正确标记 。
➜git checkout主
➜git tag v.1.2#举例
➜git push-标签
所有不同版本都会生成两个.ipa文件,一个针对我们的暂存后端,另一个针对我们的实时服务。
为了使我们(和我们的测试人员)更容易知道哪个版本针对什么,我们分配了不同的应用程序图标,包括版本名称和后端环境:
这些应用程序已上载到HockeyApp,我们的测试人员团队可以在其中查看和下载它们。
这就是我们当前的设置。 谢谢阅读! ✌️