Лучшая стратегия автоматизации нескольких сборок из одного проекта white-label xcode?
Я изучаю лучший подход к автоматизации процесса сборки. У меня есть свои идеи (благодаря опыту работы над предыдущим проектом, не связанным с ОС), но мне нужны веские аргументы за и против различных возможностей.
Цель: Один xcode-проект с одной целью (думаем, white-label) должен быть собран в 1...N различных вкусах (конкретные брендинги) с минимальным взаимодействием с пользователем и минимальными техническими знаниями. Для AdHoc и/или AppStore.
По сути, это будет означать, что для каждой сборки нужно указать папку, содержащую Icons + Splashscreen, пакет, содержащий специфические для бренда ресурсы и (предположительно?) Info.plist, указать название приложения, bundle-id и т.д.
Вопросы, требующие уважения или уточнения;
- Ручная сборка одного бренда с помощью идиотского GUI (выбрать git ветку/тег, указать определенный бренд, настроить приложение, например. IAP-enabled, server-domainname, etc - будет записано в info.plist)
- В предыдущих ручных тестах установка имени исполняемого файла в plist не сработало? Извините, забыл точную проблему... возможно, это была проблема билдконфига только Xcode Debug, не имеющая отношения к дистрибутивной сборки?
- Code-Signing?!?? Можно ли указать профиль на лету? Некоторые бренды должны быть собраны с собственным профиль.
Мое личное мнение: Hudson или CruiseControl + плагин для Xcode.
Кажется, есть много документации по решению для Xcode, и я видел это в действии в проекте Flex, над которым я работал, с почти точно такими же требованиями к белой этикетке/брендингу. Конечно, в этом случае использовался Ant-скрипт, и не было никакой поведенческой конфигурации, которую нужно было бы соблюдать. Это моя единственная неуверенность здесь... Я подозреваю, что это должно быть где-то жестко закодировано, но это не тот ответ, который понравится некоторым людям. Есть желание иметь возможность указывать различные настройки конфигурации приложения (url сервера, поддерживается ли функция Foo, отображается ли вид X и т.д. и т.п.) через GUI форму при ручной сборке. Я не уверен, насколько легко это будет впихнуть в типичную конфигурацию Hudson или CC?
И поэтому было предложено написать приложение для OSX для создания наших клиентов. Теория такова: красивый чистый нетехнологичный пользовательский интерфейс для ввода всех необходимых метаданных и настроек приложения и большая блестящая зеленая кнопка с надписью "Build". Но лично я скептически отношусь к тому, что такой подход более гибкий или более простой в реализации, чем классическое решение CI.
Итак, вопрос в том, что предпочтительнее: классический подход CI на базе сервера, интегрированный с контролем версий, или пользовательская утилита для OSX?
Что бы мы ни выбрали, почти наверняка это будет требование, чтобы запустить его за 2-3 дня (точно меньше недели).