我正在研究自动化构建流程的最佳方法。我有自己的想法(通过之前一个非iOS项目的经验),但需要好的理由支持或反对各种可能性。
目标:一个单一的xcode项目,一个单一的目标(白标),需要在1..N个不同的风味(具体品牌)中进行构建,最小限度地涉及用户交互和技术知识。用于AdHoc和/或AppStore。
基本上,这将意味着为每个构建指定;一个包含图标+启动屏幕的文件夹,一个包含特定品牌资源和(可能?)Info.plist的捆绑包,指定应用程序名称、捆绑ID等。
需要尊重或澄清的问题:
手动构建单个品牌通过傻瓜式GUI(选择git分支/标签,指定某个品牌,配置应用程序,例如启用IAP,服务器域名等 - 将写入info.plist)
在以前的手动测试中,在plist中设置可执行文件名称没有起作用?抱歉,已经忘记了确切的问题...也许只是Xcode Debug buildconfig问题,与分发构建无关?
代码签名??可以即时指定配置文件吗?某些品牌需要使用客户自己的配置文件进行构建。
我的个人感觉:Hudson或CruiseControl + Xcode插件。
似乎有很多关于Xcode解决方案的文档,在我参与的Flex项目中看到过这种情况,几乎具有相同的白标/品牌要求。当然,那是使用Ant脚本,而且没有行为配置需要尊重。这是我的唯一不确定性...我怀疑它必须在某个地方进行硬编码,但这不是会让某些人满意的答案。有一个希望能够通过GUI表单指定各种应用程序配置设置(服务器URL,是否支持函数Foo,是否显示视图X等等)的愿望,当手动构建时。我不确定将其塞入典型的Hudson或CC配置中有多容易?
因此,已提出一个建议,即编写一个OSX应用程序来构建我们的客户端。理论上,这种方法有一个漂亮干净的非技术UI,用于输入所有必要的元数据和应用程序设置,并有一个大而闪亮的绿色按钮标记为“构建”。但就我个人而言,我对这种方法的灵活性或实施难度比传统CI解决方案更加怀疑。
所以问题基本上是,什么更可取;经典的基于服务器,版本控制集成的CI方法还是自定义的OSX实用程序?
无论我们选择哪种方法,几乎肯定需要在2或3天内将其运行起来(绝对少于一周)。
目标:一个单一的xcode项目,一个单一的目标(白标),需要在1..N个不同的风味(具体品牌)中进行构建,最小限度地涉及用户交互和技术知识。用于AdHoc和/或AppStore。
基本上,这将意味着为每个构建指定;一个包含图标+启动屏幕的文件夹,一个包含特定品牌资源和(可能?)Info.plist的捆绑包,指定应用程序名称、捆绑ID等。
需要尊重或澄清的问题:
手动构建单个品牌通过傻瓜式GUI(选择git分支/标签,指定某个品牌,配置应用程序,例如启用IAP,服务器域名等 - 将写入info.plist)
在以前的手动测试中,在plist中设置可执行文件名称没有起作用?抱歉,已经忘记了确切的问题...也许只是Xcode Debug buildconfig问题,与分发构建无关?
代码签名??可以即时指定配置文件吗?某些品牌需要使用客户自己的配置文件进行构建。
我的个人感觉:Hudson或CruiseControl + Xcode插件。
似乎有很多关于Xcode解决方案的文档,在我参与的Flex项目中看到过这种情况,几乎具有相同的白标/品牌要求。当然,那是使用Ant脚本,而且没有行为配置需要尊重。这是我的唯一不确定性...我怀疑它必须在某个地方进行硬编码,但这不是会让某些人满意的答案。有一个希望能够通过GUI表单指定各种应用程序配置设置(服务器URL,是否支持函数Foo,是否显示视图X等等)的愿望,当手动构建时。我不确定将其塞入典型的Hudson或CC配置中有多容易?
因此,已提出一个建议,即编写一个OSX应用程序来构建我们的客户端。理论上,这种方法有一个漂亮干净的非技术UI,用于输入所有必要的元数据和应用程序设置,并有一个大而闪亮的绿色按钮标记为“构建”。但就我个人而言,我对这种方法的灵活性或实施难度比传统CI解决方案更加怀疑。
所以问题基本上是,什么更可取;经典的基于服务器,版本控制集成的CI方法还是自定义的OSX实用程序?
无论我们选择哪种方法,几乎肯定需要在2或3天内将其运行起来(绝对少于一周)。