Как избежать построения и развертывания зависимостей, в которых нет изменений кода
Я делаю проверку концепции непрерывной интеграции, и получит ли наша команда разработчиков выгоду от автоматизированных сборок и автоматических развертываний для уменьшения человеческих ошибок. Я уже достаточно далеко продвинулся в этом процессе, но у меня есть несколько вопросов о том, как настроить наши инкрементные сборки, чтобы избежать перестраивания зависимостей, в которых не было изменений кода. Кроме того, я хотел бы, чтобы наш инструмент развертывания идентифицировал и развертывал только сборки, восстановленные в результате изменения кода.
Мы уже используем продукты Microsoft, такие как TFS для контроля версий, Visual Studio для разработки и Team Foundation Build для непрерывной интеграции. В настоящее время мы склоняемся к InRelease для развертывания, так как он хорошо интегрируется с Team Foundation Build.
Но сначала вот наша текущая настройка...
Существует более 200 файлов решений C#, каждый из которых содержит один или несколько проектов. В окружающей среде нецелесообразно объединять эти проекты в меньшее количество решений, то есть по замыслу. В проектах в решении используются ссылки на проекты для разрешения зависимостей и ссылки на файлы для проектов в других решениях. Насколько я знаю, это рекомендуемый подход Microsoft при работе с большим количеством проектов.
Мы используем стратегию "ветвления по функциям", например, изолированную разработку в ветвях с параллельными функциями, которая по завершении объединяется в стабильную основную ветку. Когда пришло время для выпуска, выпуск отделен от основного и изолирован для исправлений и развертывания. Ветви объектов и основная ветвь имеют CI-сборку, запускаемую при регистрации кода. Релизы в большинстве случаев будут выполняться вручную из InRelease для выбранной ветки релизов. Релиз будет развернут в различных средах, включая INTEGRATION/TEST, UAT и, в конечном счете, для всех наших клиентов. Мы все еще уточняем детали стратегии ветвления, но это вопрос для другого времени.
Текущие проблемы, которые необходимо решить:
1. Избегайте перестраивания зависимостей, в которых нет изменений кода...
Когда мы внедряем новую функциональность или исправление на клиенте, мы хотим использовать абсолютный минимум в файлах. Наша компания имеет очень большую клиентскую базу (тысячи клиентов) с иногда медленным интернет-соединением, поэтому полное развертывание всех сборок (более 200) для каждого клиента не вариант. Я частично решил проблему, настроив инкрементные сборки, которые корректно перестраивают только измененные проекты, как и ожидалось, но также перестраивают все зависимые проекты, даже если для них не было сделано никаких изменений кода. Это приводит как к измененным сборкам, так и к зависимостям с новыми временными метками. Если мы используем изменение временной метки, чтобы определить, какие сборки следует развернуть, это приведет к развертыванию функционально неизмененных сборок. Целью здесь является развертывание только тех сборок, в которых изменился код, и сборок, в которых происходят критические изменения.
Например:
Решение B, имеет проект под названием Project B Решение A, есть проект под названием Project A
Проект B -> Проект A (где Проект A имеет файловую зависимость от Проекта B)
Когда в проекте A вносятся неразрывные изменения, скажем, во внутреннюю часть метода, то ожидаемый результат: создается только A и, следовательно, является кандидатом на развертывание. Когда в проекте A вносятся критические изменения, которые нарушают проект B, ожидаемый результат будет следующим: и A, и B созданы и, следовательно, являются кандидатами на развертывание. В настоящее время MSBuild перестраивает все зависимости независимо от того, чего мы не хотим.
2. Автоматически определить, какие сборки следует развернуть...
У меня есть частичное решение проблемы. Когда сборка выполняется, мой шаблон процесса сборки настраивается для запуска сценария MSBuild, содержащего список решений для сборки в определенном порядке. Эта операция выполняется в рабочей области агента сборки. Каждый раз, когда выполняется новая сборка, шаблон процесса сборки создает уникальную папку для перетаскивания в формате и копирует двоичные файлы из рабочей области агента сборки в папку удаления. Это стандартная функциональность, о которой заботится стандартный шаблон процесса сборки. Сборка была настроена таким образом, чтобы не очищать рабочее пространство агента сборки, поэтому при первом запуске она строит все проекты в рамках решения, но последующие сборки будут строить только проекты, в которых есть изменения кода или они зависят от других проектов (инкрементная сборка?). Следовательно, неизмененные сборки будут иметь исходные метки времени, а измененные сборки будут иметь новые метки времени. У нас есть инструмент, который может сравнивать папки между удаленными папками и выводить результаты в текстовый файл. Это позволяет нам определить, какие двоичные файлы были добавлены / изменены / удалены с момента последнего развертывания. Это также дает нам дополнительное преимущество сравнения списка фактических артефактов с манифестом ожидаемых артефактов, как определено разработчиком. Это гарантирует, что не будут развернуты никакие сборки, которые не были определены и проверены на модульное тестирование.
Вопрос в том, как мы можем использовать InRelease для развертывания только необходимых файлов, как в приведенном выше примере, а не всех файлов в папке удаления?
1 ответ
- Установите TFS Proxy перед вашей сборочной машиной, это уменьшит сетевой трафик
- Вы начнете со стратегии ветвления, такой как Service Pack, вы можете прочитать документацию в руководстве по ALM Rangers... И адаптировать шаблон процесса к созданию только части измененного кода. Я думаю, что в BRD Lite, другом руководстве ALM Rangers, вы найдете больше информации.