Сведения о миграции предприятия на GitHub Actions
Чтобы перенести предприятие в GitHub Actions из существующей системы, необходимо спланировать миграцию, выполнить ее и прекратить использование прежней системы.
В этом руководстве рассматриваются конкретные аспекты миграции. Дополнительные сведения о вводе GitHub Actions в вашей организации см. в разделе "Внедрение GitHub Actions на предприятии".
Планирование миграции
Перед началом миграции предприятия в GitHub Actions следует определить, какие рабочие процессы будут перенесены и как эти миграции повлияют на ваши команды, а затем спланировать, как и когда вы будете выполнять миграцию.
Привлечение специалистов по миграции
GitHub может помочь в миграции. Также вы можете приобрести GitHub Professional Services. Контакты для получения дополнительной информации: ваш представитель или Команда по продажам GitHub.
Определение и инвентаризация целевых объектов миграции
Прежде чем перейти на GitHub Actions, тщательно изучите рабочие процессы, используемые предприятием в существующей системе.
Во-первых, проведите инвентаризацию существующих рабочих процессов сборки и выпуска на предприятии, собрав сведения о том, какие рабочие процессы активно используются, поэтому их нужно перенести, а какие можно оставить в старой системе.
Затем изучите различия между текущим поставщиком и GitHub Actions. Это поможет вам оценить все трудности при переносе каждого рабочего процесса и потенциальные различия функций. Дополнительные сведения см. в разделе Переход на GitHub Actions.
С помощью этих сведений вы сможете определить, какие рабочие процессы можно перенести на GitHub Actions.
Определение влияния миграции на команду
Переход на новые инструменты влияет на работу команды. Подумайте, как перемещение рабочего процесса из существующих систем в GitHub Actions повлияет на повседневную работу разработчиков.
Определите все процессы, интеграции и сторонние инструменты, которые будут затронуты миграцией, и запланируйте все необходимые обновления.
Подумайте, как миграция может повлиять на соответствие требованиям регуляторов. Например, будут ли имеющиеся средства проверки учетных данных и анализа безопасности работать с GitHub Actions или вам потребуется использовать новые средства?
Определите шлюзы и проверки в существующей системе и убедитесь, что их можно реализовать с помощью GitHub Actions.
Определение и проверка средств миграции
Средства автоматической миграции могут перевести рабочие процессы предприятия с синтаксиса существующей системы на синтаксис, необходимый для GitHub Actions. Найдите сторонние инструменты или узнайте больше об инструментах, предоставляемых GitHub, — вам поможет ваш представитель или Команда по продажам GitHub. Например, можно использовать GitHub Actions Importer для планирования, области и переноса конвейеров CI в GitHub Actions из различных поддерживаемых служб. Дополнительные сведения см. в разделе Автоматизация миграции с помощью средства импорта GitHub Actions.
После выбора средства для автоматизации миграции проверьте его, запустив на тестовых рабочих процессах и убедившись в корректности результатов.
Автоматизированные средства должны перенести большинство рабочих процессов, но часть из них, скорее всего, потребуется переписать вручную. Оцените, какой объем работы нужно будет выполнить вручную.
Выбор подхода к миграции
Определите оптимальный подход к миграции для вашего предприятия. Небольшие команды смогут перенести все свои рабочие процессы сразу с помощью стратегии "rip-and-replace". Крупным предприятиям лучше выбрать итеративный подход. Вы можете выбрать централизованное управление всей миграцией или попросить отдельные команды самостоятельно перенести собственные рабочие процессы.
Мы рекомендуем итеративный подход, сочетающий в себе активное управление с самообслуживанием. Начните с небольшой группы ранних последователей, которые могут продвигать новые инструменты среди коллег. Выберите несколько рабочих процессов, которые будут отражать всю полноту вашего бизнеса. В сотрудничестве с ранними последователями перенесите эти рабочие процессы в GitHub Actions, выполняя итерацию по мере необходимости. Это даст другим командам уверенность в том, что их рабочие процессы тоже можно будет перенеси.
Затем предоставьте GitHub Actions всей организации. Предоставьте ресурсы, которые помогут этим командам перенести собственные рабочие процессы в GitHub Actions, и сообщите командам, когда вы прекратите использование существующих систем.
Наконец, сообщите всем командам, которые по-прежнему используют старые системы, что необходимо выполнить миграцию до указанного срока. Вы можете продемонстрировать успехи других команд, чтобы уверить их в возможности и желательности миграции.
Определение расписания миграции
Выбрав подход к миграции, составьте расписание, описывающее, когда каждая из команд перенесет свои рабочие процессы в GitHub Actions.
Сначала определите дату завершения миграции. Например, вы можете привязать миграцию к окончанию контракта с текущим поставщиком.
Затем вместе с командами создайте расписание в соответствии с вашими сроками, но без ущерба для целей команд. Учитывайте темп вашего бизнеса и рабочую нагрузку каждой команды, которая должна будет выполнить миграцию. Работайте с командами, чтобы понять их графики доставки и составить план, позволяющий перенести рабочие процессы за один раз без помех для работы.
Миграция на GitHub Actions
Когда вы будете готовы начать миграцию, преобразуйте существующие рабочие процессы в GitHub Actions с помощью автоматизированных инструментов и вручную.
Возможно, вам также потребуется сохранить старые артефакты сборки из существующей системы, написав скрипт для архивации артефактов.
Прекращение использования существующих систем
После завершения миграции можно подумать о прекращении использования существующей системы.
Некоторое время обе системы могут работать параллельно, пока вы не убедитесь в стабильности конфигурации GitHub Actions и отсутствии проблем у разработчиков.
Наконец, отключите старые системы и убедитесь, что никто на вашем предприятии не сможет включить их обратно.