Я изучаю лучший подход к автоматизации нашего процесса сборки. У меня есть свои идеи (благодаря опыту предыдущего проекта, не связанного с iOS), но мне нужны веские аргументы за и против различных возможностей.
Цель: один проект xcode с единственной целью (подумайте над белой этикеткой) должен быть встроен в 1..N различные варианты (конкретные марки) с минимальным взаимодействием с пользователем и минимальными техническими знаниями. Для AdHoc и / или AppStore.
По сути, это будет означать указание для каждой сборки; папка, содержащая значки + Splashscreen, пакет, содержащий ресурсы, относящиеся к бренду, и (предположительно?) Info.plist с указанием имени приложения, идентификатора пакета и т. д.
Вопросы, которые необходимо уважать или прояснять;
- Ручная сборка одного бренда через Idiot-Proof GUI (выберите git
филиал / тег, укажите определенный бренд, настройте приложение, например.
IAP-сервер, имя домена сервера и т. Д. Будут записаны в
info.plist)
- В предыдущих ручных тестах установка имени исполняемого файла в
лист не сработал? Извините, забыл точную проблему ..
возможно, это была только проблема Xcode Debug buildconfig, не относящаяся к
сборка дистрибутива?
- подписывания кода?!? Можно ли указать профиль
на лету? Некоторые бренды должны быть построены с собственным клиентом
профиль.
Мои личные ощущения: плагин Hudson или CruiseControl + Xcode.
Кажется, есть много документации для решения XCode, и я видел это в действии в проекте Flex, над которым я работал, с почти такими же требованиями к белой маркировке / брендингу. Конечно, это было использование скрипта Ant, хотя и не было никакой настройки поведения, чтобы уважать. Это моя единственная неуверенность здесь ... Я подозреваю, что это должно быть где-то жестко закодировано, но это не тот ответ, который порадует некоторых людей. Желательно иметь возможность задавать различные параметры конфигурации приложения (URL-адрес сервера, поддерживается ли функция Foo, отображается ли представление X и т. Д. И т. Д.) Через форму графического интерфейса при сборке вручную. Я не уверен, насколько легко было бы вставить это в типичную конфигурацию Hudson или CC?
И поэтому одно предложение, которое было сделано, - это написать приложение OSX для создания наших клиентов. Теория заключается в том, что у вас есть удобный чистый нетехнический интерфейс для ввода всех необходимых метаданных и настроек приложения, а также большая блестящая зеленая кнопка с надписью «Build». Но лично я скептически отношусь к тому, что этот подход является более гибким или более простым для реализации, чем классическое решение CI.
Итак, вопрос в том, что предпочтительнее; классический серверный, интегрированный контроль версий, подход CI или пользовательская утилита OSX?
В зависимости от того, что мы сделаем, почти наверняка потребуется запустить его через 2 или 3 дня (определенно, менее чем за неделю).