Шаблон разработки и построения конвейера DevOps - нужен совет по развертыванию множества отдельных файлов

Question

У нас есть PoC для развертывания файла на старом мэйнфрейме.Есть много типов развертываний, которые мы делаем, но этот вопрос фокусируется на отдельных файлах.Мы можем подключиться по SSH к мэйнфрейму, и у нас есть конвейер развертывания с шагами, необходимыми для получения одного файла в правильном месте.

Проблема в том, что у нас более 54 000 таких отдельных файлов.Во время выпуска мы можем развернуть всего 1-5 файлов, или большое развертывание может составить 250 файлов.У каждого из них будет свой источник и пункт назначения.Некоторые из них могут быть источниками из одной и той же папки и развернуты в той же папке, но это не гарантируется.

Можно предположить, что файлы являются неизменяемыми.Существуют проблемы как сборки, так и выпуска:

Сборка - что такое артефакт?Используем ли мы один артефакт для каждого выпуска, который может содержать 1-250 файлов?Мы не хотим иметь 250 сценариев сборки для выпуска, который мы знаем.

Release - Как мы используем конвейеры.Если вы соберете их вместе, будет ли развертывание одним щелчком мыши в этой среде?Как бы вы определили, если кто-то добавил файл к выпуску?Я предполагаю, что нам понадобится новая сборка, которая создаст новый конвейер?

Есть несколько других вещей, которые возникают, например, нам нужно проверить статус в нашей системе управления изменениями, чтобы подтвердить, что билет для этого файланаходится в статусе, который одобрен.Это этап развертывания в настоящее время.

Answer 1

Делая некоторые предположения здесь, это счастливый путь, но, возможно, это поможет вам найти окончательное решение.

1. Иметь ветку master , в которой есть папка products . Эта папка будет иметь подпапки для каждого продукта, которые имеют файлы:

   оригинал /
   Продукты /
   productA
   productB
   productN

2. Команда разработчиков будет работать с файлами в отдельных ветвях fix , а затем объединяться в master посредством запросов на получение. Вы можете настроить политики и шлюзы для аудита

3. Создание конвейера сборки с задачей сценария powershell, которая проверяет наличие ошибок ( возможный пример ) в master и копирует / публикует только эти изменения в артефакте папка назначения с таким же продуктом макет подпапки

4. Создайте конвейер выпуска, в котором есть этап для каждого продукта и / или пути назначения на мэйнфрейме. Каждый этап будет иметь пользовательскую задачу, которая копирует файлы из соответствующей папки продукта в место назначения через SSH. Вы даже можете создать группу задач, которая будет использоваться повторно, а затем просто использовать переменные для путей к папкам и т. Д. ПРИМЕЧАНИЕ. Это будет довольно много этапов, но для этого и предназначены конвейеры выпуска:

5. Запланируйте запуск конвейера выпуска в желаемое время. Вы можете настроить уведомления о сбоях, чтобы кто-то или процесс мог исследовать / повторить попытку и т. Д.

Answer 2

Я не уверен, что это «ответ» или нет, но это наш взгляд на это до сих пор:

Артефакт Мы собираемся создать файл данных "релиз". В этом файле будет список файлов для каждого развертывания. Мы организуем файлы по линейке продуктов и создадим ветку всех файлов для конкретного продукта. Затем сборка прочитает файлы и создаст артефакт из списка файлов, связанных с этим выпуском. Мы также включим файл данных в артефакт.

Развертывание Мы создадим процесс релиза Parent / Child. Родительский скрипт перебирает файл данных и вызывает дочерний скрипт. Дочерний скрипт развернет отдельный файл, который будет представлен строкой в ​​файле данных. Для развертывания в производство будет развернут только родитель. Ребенок не каждый будет развернут индивидуально.

Несколько времен развертывания / зависимости У нас есть требование для развертывания определенных файлов в определенное время. Развертывание одного рабочего файла может быть в 13:00, а другое - в 19:00 в том же выпуске. Для размещения этого мы включим время развертывания в файл данных. После того, как каждый файл будет развернут, мы узнаем, как этот файл был развернут.

Управление изменениями Мы будем проверять систему управления изменениями в каждом дочернем сценарии, чтобы убедиться, что файл готов к развертыванию. Если отдельный файл не будет утвержден, мы не прекратим обработку, мы завершим развертывание для всех других файлов в списке, которые были утверждены, а затем в качестве последнего шага в развертывании мы провалим развертывание. Нам нужно сделать «отслеживание» доступным для команд, чтобы увидеть, что привело к сбою развертывания.