Я использую CI в качестве Сольного Разработчика.
, Когда я объединяю свое ответвление dev в мое тестовое ответвление, CI захватывает код, компилирует его, изменяет строку подключения, изменяет несколько настроек приложения и копирует его через Вне всякого сравнения к моей испытательной площадке для людей тестеры, чтобы взглянуть на.
Я сам боролся с этим, и я не могу сказать вам ничего, кроме:
Первый пункт достаточно очевиден. Во-вторых, нельзя обойти стороной тот факт, что FLA-файлы - это двоичные капли, которые содержат все ваши визуальные ресурсы и плохо сочетаются с управлением версиями, но вы можете признать тот факт, что одно содержимое часто меняется, а другое, как правило, создается один раз. а потом оставили в покое. Разделив ваши ресурсы на разные FLA, вы можете сохранить большую часть изменений в небольшом количестве нестабильных FLA, и разница между стабильным и нестабильным содержимым будет отражена в ваших версионных файлах.
Обратите внимание, что даже если вы не можете загрузить ресурсы во время выполнения, совместное использование во время компиляции по-прежнему позволяет разделить ресурсы на произвольное количество FLA. (Совместное использование во время компиляции часто упускается из виду - если вы не знакомы с ним, откройте свойства MovieClip и проверьте раздел «Источник» внизу.) Как разделить вещи будет зависеть от вашего проекта. Лучшее, что я могу предложить, - это семантическое разделение - возможно, один FLA для каждого символа, или один FLA для каждого раздела, или один FLA для каждого элемента интерфейса и т. Д. Как и во всех разработках, цель состоит в том, чтобы сгруппировать связанные ресурсы и исключить дублирование.
Третий момент: поскольку различия невозможны, нет никакого способа сохранить документ изменений. Я предпочитаю проверять FLA на управление версиями и отмечать все изменения в примечании к регистрации, но изменения также могут быть в отдельном документе. (Обратите внимание, что крайне важно, чтобы библиотеки в каждом FLA упорядочены, иначе кто-то, читающий описание изменения, не сможет найти изменение.) Однако, поскольку это может быть проблемой для некоторого содержимого, также полезно обозначить определенные FLA как " нестабильный », и не заморачиваться со списком изменений. Но если такие файлы имеют много зависимостей от других файлов, вы позже пожалеете об этом.
К сожалению, это все, что я обнаружил до сих пор. Adobe говорила о переходе на текстовый формат FLA в будущей версии, но пока это не произойдет, простого решения не существует.
поскольку это может быть проблемой для некоторого содержимого, также полезно обозначить некоторые FLA как «нестабильные» и не беспокоиться о списке изменений. Но если у таких файлов много зависимостей от других файлов, вы пожалеете об этом позже.К сожалению, это все, что я обнаружил до сих пор. Adobe говорила о переходе на текстовый формат FLA в будущей версии, но пока это не произойдет, простого решения не существует.
поскольку это может быть проблемой для некоторого содержимого, также полезно обозначить определенные FLA как «нестабильные» и не беспокоиться о списке изменений. Но если у таких файлов много зависимостей от других файлов, вы пожалеете об этом позже.К сожалению, это все, что я обнаружил до сих пор. Adobe говорила о переходе на текстовый формат FLA в будущей версии, но пока это не произойдет, простого решения не существует.
Похоже, вы застряли с FLA-файлами из-за внешних требований, но, на всякий случай ...
Если вы создаете флеш-проект с тяжелым кодом, я бы выбрал чистый ActionScript или гибкий подход, использование файлов .fla только для тех целей, для которых они подходят (анимация на временной шкале)
Flex Builder / Flash Builder - отличная среда для создания проектов Flash, где весь код находится в файловых форматах, удобных для управления исходным кодом.
Мы находимся в процессе перевода всех наших медиаплееров на основе FLA на MXML (где полезны компоненты пользовательского интерфейса Flex) и чистые проекты ActionScipt. Преимущества системы управления версиями огромны.
Если это невозможно, то, боюсь, единственное, что вы можете сделать, это переместить как можно больше файлов из FLA - двоичный формат просто не подходит для управления версиями.
Забудьте о версии - Adobe ее больше не разрабатывает (она не входит в новые пакеты CS5)
Насколько я понимаю, Adobe Version Cue не даст вам ничего, кроме того, что дает вам svn. (Конечно, я слышал только ужасные истории о Version Cue и на самом деле не использовал ее.)
После работы над большими Flash-проектами с svn раньше (большие команды и большие развертывания), лучший совет, который я могу вам дать. is:
Хорошо, ваш клиент требует всех этих FLA, но почему? Возможно, вы уже сделали это, но попробуйте немного отступить от их технических требований - что, по их мнению, они получают от этого требования?
Назначьте ОДНОГО человека менеджером выпуска Flash-приложения. Они будут нести ответственность за проверку правильности кода из svn, его сборку и обеспечение того, чтобы он попал в общее развертывание приложения. Они также ответят на вопрос, какая ревизия в какой среде (это можно легко автоматизировать).
Поместите как можно меньше кода и ресурсов в FLA. Вы должны загружать изображения и другие ресурсы из внешних источников, а затем прикреплять их к соответствующим MC и спрайтам.
Если возможно, делите команды небольшими отдельными порциями. Это снижает вероятность противоречивых изменений в FLA и увеличивает вероятность того, что все будут знать, что происходит.
[Скорее примечание о пропускной способности, меньше относящееся к этому вопросу] Относитесь к своим FLA как к библиотекам или SDK, если это вообще возможно. Если их потребность близка к «одному суб-FLA на страницу» с основным FLA, тогда имейте дополнительные суб-FLA, которые содержат активы / виджеты.Таким образом, ваши FLA страницы содержат только код конкретной страницы, и вы не перезагружаете виджеты каждый раз, когда «переключаете страницы». (Предполагается, что браузер не обновляется между переключениями страниц.)
Вероятно, стоит отметить, что это в основном нетехнические решения. Мне еще предстоит найти способ «убить одним выстрелом» для проблемы работы с двоичными файлами в системах контроля версий, особенно с двоичными файлами, которые на самом деле являются исходным кодом. И это действительно решающий аргумент: идея хранить исходный код в проприетарном двоичном формате, чтобы его можно было скомпилировать только в другой закрытый формат, является плохим вуду.