Автоматизация сборки поставок от внешних разработчиков
Invite pending
Все началось с того, что нам надоело собирать поставки от внешних разработчиков (ВР) вручную.
В перечень работ входили такие этапы как скачивание поставки, проверка поставки на структуру, проверка внутреннего содержания файлов, загрузка поставки согласно внутренней структуре в СКВ (Систему контроля версий).
Поставка от ВР может приходить в виде исходного кода или набора бинарных файлов. Поставку с исходниками предварительно необходимо собрать и протестировать, а тут уже могут использоваться и собственные скрипты, и TFS, и maven, и т. д. и т. п. но это уже совсем другая история…
Так же каждый ВР присылает поставки в разном формате, так как нет жесткого регламента структуры поставки.
В итоге было решено написать некий Автосборщик, который выполнял бы все действия по заранее созданному алгоритму, так же его внедрение позволяло бы выработать единый подход к формированию структуры поставки.
В качестве СКВ мы используем Git, SVN, CA Harvest (Зависит от конкретного проекта).
После недолгих раздумий и оценки парка ПО в качестве «кубиков» Автосборщика были взяты следующие компоненты:
В Jira добавили несколько необходимых полей:
Создали таблички в БД с параметрами и набором задач для каждого набора параметров "Проект + Поставщик + Контур":
— Каждый проект состоит из Процессов в определенной последовательности
— Каждая Процесс включает в себя набор параметров (жестко заданные в БД для проекта и вычисляемые)
В итоге процесс работы Автосборщика получился следующим:
Сам Автосборщик выполняет следующий пул процессов:
В случае возникновения ошибки Статус отправляется в задачу Jira, а также полный лог работы по почте пользователю, запустившему процесс автосборки, и группе сопровождения.
На данный момент в системе описаны процессы следующих типов:
Какой же Профит мы получили из всего этого:
Что планируется доработать:
P.S. Не знаю на сколько здесь нужны выдержки кода. В самих исходниках нет чего-то и необычного.
В перечень работ входили такие этапы как скачивание поставки, проверка поставки на структуру, проверка внутреннего содержания файлов, загрузка поставки согласно внутренней структуре в СКВ (Систему контроля версий).
Поставка от ВР может приходить в виде исходного кода или набора бинарных файлов. Поставку с исходниками предварительно необходимо собрать и протестировать, а тут уже могут использоваться и собственные скрипты, и TFS, и maven, и т. д. и т. п. но это уже совсем другая история…
Так же каждый ВР присылает поставки в разном формате, так как нет жесткого регламента структуры поставки.
В итоге было решено написать некий Автосборщик, который выполнял бы все действия по заранее созданному алгоритму, так же его внедрение позволяло бы выработать единый подход к формированию структуры поставки.
В качестве СКВ мы используем Git, SVN, CA Harvest (Зависит от конкретного проекта).
После недолгих раздумий и оценки парка ПО в качестве «кубиков» Автосборщика были взяты следующие компоненты:
- Jira — Обеспечивает интерфейс пользователя.
- SonicMQ — очередь для общения с Jira.
- БД – База для хранения шаблонов «шагов» по сборке
- .NET — язык разработки
- TeamCity — Через TC происходит скачивание поставок (он единственный смотрит в Глобальную паутину. Безопасность ...)
- PMD — в качестве инструмента проверки структуры файлов
- HTML — Страница с отображением информации по сборкам
В Jira добавили несколько необходимых полей:
- Путь до поставки — В данном поле через разделитель указывается список архивов для скачивания
- Контур установки (DEV, TST, PROD) — в зависимости от типа контура список действий может отличаться
- ВР(Поставщик)- это очередной флаг для инициализации набора «шагов» Автосборщика
Создали таблички в БД с параметрами и набором задач для каждого набора параметров "Проект + Поставщик + Контур":
— Каждый проект состоит из Процессов в определенной последовательности
— Каждая Процесс включает в себя набор параметров (жестко заданные в БД для проекта и вычисляемые)
В итоге процесс работы Автосборщика получился следующим:
- Jira по кнопке формирует XML файл с параметрами задачи и отправляет его в Очередь
- Сообщение из очереди вылавливает WinService и проводит первичный анализ (описана ли связка "Проект + Поставщик + Контур" в БД, все ли необходимые поля заполнены в задаче Jira)
- Если все хорошо, то WinService запускает Автосборщик с параметрами.
Сам Автосборщик выполняет следующий пул процессов:
- Работы, которые выполняем до поставок (Создание директорий, обновление репозитория ...).
- Работы, которые выполняются с архивами (Проверка контрольных сумм архива, распаковка, копирование в необходимую структуру) — Данные задачи выполняются для каждого архива в цикле.
- Работы, которые выполняем после архивов (проверка кодировки и структуры файлов, проверка структуры загрузка в СКВ).
В случае возникновения ошибки Статус отправляется в задачу Jira, а также полный лог работы по почте пользователю, запустившему процесс автосборки, и группе сопровождения.
На данный момент в системе описаны процессы следующих типов:
- Работа с СКВ (Git, SVN, Harvest)
- Процесс получения архива с FTP (Реализован с использованием REST API TeamCity)
- Работа с архивом (На данный момент используется 7zip).
- Работа с файлами и каталогами.
- Проверка соответствия структуры поставки (PMD и другие).
Какой же Профит мы получили из всего этого:
- Удалось разработать удобную структуру поставок и формирования имен файлов.
- Исчезла необходимость в получении доступа во внешнюю сеть большому количеству пользователей. Теперь достаточно одной Доменной учётной записи.
- Уменьшилось время на получение поставки и количество ошибок при приемке поставки.
- Уменьшение количества скачиваний поставок.
Что планируется доработать:
- доделать возможность работы Автосборщика в многопоточном режиме. Тут, правда, есть небольшие трудности — одновременно можно собирать только одну поставку для одного проекта.
P.S. Не знаю на сколько здесь нужны выдержки кода. В самих исходниках нет чего-то и необычного.