从单个白标签 xcode 项目自动执行多个构建的最佳策略?

发布于 2024-12-07 02:03:37 字数 1096 浏览 8 评论 0原文

我正在研究自动化构建过程的最佳方法。我有自己的想法(通过以前的非 iOS 项目的经验),但需要支持和反对各种可能性的良好论据。

目标:具有单一目标(认为白标签)的单一 xcode 项目需要以 1..N 种不同风格(具体品牌)构建,并具有最少的用户交互和最少的技术知识。对于 AdHoc 和/或 AppStore。

从本质上讲,这意味着每个构建都需要指定;包含 Icons + Splashscreen 的文件夹,包含品牌特定资源和(大概?)Info.plist 的捆绑包,指定应用程序名称、捆绑包 ID 等。

需要尊重或澄清的问题;

  • 通过 Idiot-Proof GUI 手动构建单个品牌(选择 git 分支/标签,指定某个品牌,配置应用程序,例如 启用 IAP、服务器域名等 - 将写入 info.plist)
  • 在之前的手动测试中,设置可执行文件名称 plist 不起作用?抱歉,忘记具体问题了。。 也许只是 Xcode Debug buildconfig 问题,与 发行版构建?
  • 代码签名?!?可以指定配置文件吗 即时?有些品牌需要客户自己打造 轮廓。

我个人的感觉:Hudson或者CruiseControl + Xcode插件。

似乎有大量关于 Xcode 解决方案的文档,并且我已经在我从事的 Flex 项目中看到了这一点,具有几乎完全相同的白标/品牌要求。当然,这是使用 Ant 脚本,并且没有需要遵守的行为配置。这是我唯一的不确定性......我怀疑它必须在某个地方进行硬编码,但这并不是让某些人满意的答案。希望在手动构建时能够通过 GUI 表单指定各种应用程序配置设置(服务器 url、是否支持函数 Foo、是否显示视图 X 等)。我不确定将其硬塞到典型的 Hudson 或 CC 配置中有多容易?

因此,我们提出的一个建议是编写一个 OSX 应用程序来构建我们的客户端。理论上是,漂亮干净的非技术用户界面用于输入所有必要的元数据和信息。应用程序设置和一个标有“构建”的闪亮绿色大按钮。但就我个人而言,我怀疑这种方法是否比经典的 CI 解决方案更灵活或更容易实施。

所以问题基本上是,什么是更好的?基于经典服务器、集成版本控制、CI 方法还是自定义 OSX 实用程序?

无论我们采取哪种方式,几乎肯定需要在 2 或 3 天内(肯定少于一周)将其启动并运行。

I'm researching the best approach to automating our build process. I've got my own ideas (through experience on a previous non-iOS project) but need good arguments for and against various possibilities.

Objective: A single xcode project with a single target (think white-label) needs to be built in 1..N different flavours (concrete brandings) with minimum user interaction and minimum technical knowledge. For AdHoc and/or AppStore.

Essentially, that will mean specifying per build; a folder containing Icons + Splashscreen, a bundle containing brand specific resources and (presumably?) the Info.plist, specifying appname, bundle-id, etc.

Issues that need to be respected or clarified;

  • Manual build of a single brand via Idiot-Proof GUI (choose a git
    branch/tag, specify a certain brand, configure the app e.g.
    IAP-enabled, server-domainname, etc - will be written to the
    info.plist)
  • In previous manual tests, setting the executable name in
    the plist didn't work? Sorry, have forgotten the exact problem..
    perhaps was only an Xcode Debug buildconfig problem, not relevant to
    a distribution build?
  • Code-Signing?!? Can the profile be specified
    on-the-fly? Some brands need to be built with the customer's own
    profile.

My personal feeling: Hudson or CruiseControl + Xcode plugin.

There seems to be plenty of documentation around for an Xcode solution and I've seen this in action on a Flex project I worked on, with almost exactly the same white-label/branding requirements. Of course that was using Ant script though and there was NO behavioral config to respect. That's my only uncertainty here... I suspect it would have to be hardcoded somewhere, but that's not the answer that's going to please some people. There is a wish to be able to specify the various app-config settings (server url, is function Foo supported, is the view X displayed, etc, etc) via a GUI form, when building manually. I'm not sure how easy it would be to shoehorn that into a typical Hudson or CC config?

And hence one suggestion that has been made is to write an OSX app for building our clients. The theory being, nice clean non-tech UI for entering all the necessary meta data & app setting and a big shiny green button labelled "Build". But personally I'm skeptical that this approach is any more flexible or easier to implement than a classic CI solution.

So the question is basically, what's preferable; a classic server based, version control integrated, CI approach or a custom OSX utility?

Whichever we go for it'll almost certainly be a requirement to get it up and running in 2 or 3 days (definately less than one week).

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

咋地 2024-12-14 02:03:37

恕我直言,您可以使用 XCode 的不同目标解决所有问题。

每个目标都将共享代码,但它可以:

  • 使用不同的配置文件进行签名
  • 使用不同的 plist:这意味着具有不同的名称..
  • 使用不同的品牌图像。您只需用相同的名称命名图像并在文件检查器中选择正确的目标即可。
  • 在 XCode 中一键构建。

我希望这有帮助

IMHO you can resolve all issues using different targets of XCode.

Every target will share the code but it could:

  • be signing with diferent profiles
  • use diferent plist: this implies having different names..
  • use diferent brand images. You only have to name the image with the same name and select the correct target in file inspector.
  • Build with one click in XCode.

I hope this helps

肩上的翅膀 2024-12-14 02:03:37

很晚才回复,但我采取的方法是创建白标 IPA,然后创建一个脚本来:
1. 解压缩(将.ipa 文件扩展名更改为.zip)。
2、变更资产。
更新 info.plist (使用 Plistbuddy 命令)
再次拉上拉链。
放弃代码。

将此脚本视为起点:https://gist.github.com/catmac/1682965

An extremely later reply, but the approach I would take would be to create the white label IPA, and then create a script to:
1. Unzip it (change the .ipa file extension to .zip).
2. Change assets.
Update the info.plist (using Plistbuddy command)
Zip it again.
Resign the code.

See this script as a starting point: https://gist.github.com/catmac/1682965

演多会厌 2024-12-14 02:03:37

很晚才回答。但我会使用不同的 .xcconfig 文件和多个方案。方案名称可以是目标/品牌的组合。

Very late answer. But I would go with different .xcconfig files and multiple schemes. The scheme names could be a combination of target/brand.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文