Я проверяю концепцию непрерывной интеграции и проверяю, выиграет ли наша команда разработчиков от автоматизированных сборок и автоматизированных развертываний, чтобы уменьшить количество человеческих ошибок. Я уже довольно далеко продвинулся в этом процессе, но у меня есть несколько вопросов о том, как настроить наши инкрементные сборки, чтобы избежать перестройки зависимостей, в которых не было изменений кода. Кроме того, я хотел бы, чтобы наш инструмент развертывания определял и развертывал только сборки, перестроенные в результате изменения кода.
Мы уже используем продукты Microsoft, такие как TFS для управления версиями, Visual Studio для разработки и Team Foundation Build для сборок с непрерывной интеграцией. В настоящее время мы склоняемся к развертыванию InRelease, поскольку он хорошо интегрируется с Team Foundation Build.
Но сначала вот наша текущая установка ...
Существует более 200 файлов решений C #, каждый из которых содержит один или несколько проектов. В окружающей среде нецелесообразно объединять эти проекты в меньшее количество решений, то есть по дизайну. Проекты в рамках решения используют ссылки на проекты для разрешения зависимостей и ссылок на файлы для проектов в других решениях. Насколько мне известно, это рекомендованный подход Microsoft при работе с большим количеством проектов.
Мы используем стратегию «переход по функции», например изолированная разработка на параллельных ветвях функций, которая по завершении объединяется в стабильную основную ветвь. Когда приходит время выпуска, выпуск отделяется от основного и изолирован для исправлений и развертывания. В ветвях функций и основной ветке есть сборка CI, запускаемая проверками кода. Релизы обычно запускаются вручную из InRelease для выбранной ветки релиза. Релиз будет развернут в различных средах, включая ИНТЕГРАЦИЮ / ТЕСТ, UAT и, в конечном итоге, для всех наших клиентов. Мы все еще конкретизируем детали стратегии ветвления, но это вопрос в другой раз.
Текущие проблемы, которые необходимо решить:
1. Избегайте перестроения зависимостей, в которых нет изменений кода ...
Когда мы развертываем новую функциональность или патч для клиента, мы хотим разместить в файлах минимум файлов. У нашей компании очень большая клиентская база (тысячи клиентов) с иногда медленным подключением к Интернету, поэтому полное развертывание всех сборок (200+) для каждого клиента не вариант. Я частично решил проблему, установив инкрементные сборки, которые правильно перестраивают только измененные проекты, как ожидалось, но также перестраивают все зависимые проекты, даже если в них не было внесено НИКАКИХ ИЗМЕНЕНИЙ КОДА. Это приводит к тому, что как измененные сборки, так и зависимости имеют новые отметки времени. Если мы используем изменение метки времени для определения того, какие сборки следует развернуть, это приведет к развертыванию функционально неизмененных сборок. Цель здесь - развернуть только сборки, в которых был изменен код, и сборки, в которых происходят критические изменения.
Например:
У решения B есть проект под названием Project B, у решения A есть проект под названием Project A
Проект B -> Проект A (где проект A имеет файловую зависимость от проекта B)
Когда в проекте A выполняется неразрывное изменение, скажем, во внутренней части метода, то ожидаемый результат таков: создается только A и, следовательно, кандидат для развертывания. Когда в проект A вносится критическое изменение, которое нарушает работу проекта B, ожидаемый результат таков: оба элемента A и B созданы и, следовательно, являются кандидатом для развертывания. В настоящее время MSBuild восстанавливает все иждивенцы независимо от того, что нам нужно.
2. Автоматически определять, какие сборки следует развернуть ...
У меня есть частичное решение проблемы. Когда сборка выполняется, мой шаблон процесса сборки настроен на запуск сценария MSBuild, содержащего список решений для сборки в определенном порядке. Эта операция выполняется в рабочей области агента сборки. Каждый раз, когда выполняется новая сборка, шаблон процесса сборки создает уникальную папку для размещения в формате и копирует двоичные файлы из рабочей области агента сборки в папку для размещения. Это готовая к работе функция, о которой позаботился стандартный шаблон процесса сборки. Сборка была настроена так, чтобы не очищать рабочую область агента сборки, поэтому при первом запуске она будет создавать все проекты в рамках решения, но последующие сборки будут создавать только те проекты, которые имеют изменения кода или зависят от других проектов (инкрементная сборка?). Поэтому неизмененные сборки будут иметь исходные метки времени, а измененные сборки будут иметь новые метки времени. У нас есть инструмент, который может сравнивать папки между перетаскиваемыми папками и выводить результаты в текстовый файл. Это позволяет нам определить, какие двоичные файлы были добавлены / изменены / удалены с момента последнего развертывания. Это также дает нам дополнительное преимущество сравнения списка фактических артефактов с манифестом ожидаемых артефактов, определенным разработчиком. Это гарантирует, что не будут развернуты никакие сборки, которые не были указаны и не прошли модульное тестирование.
Вопрос в том, как мы можем использовать InRelease для развертывания только необходимых файлов, как в приведенном выше примере, а не всех файлов в папке для размещения?
