Модернизация разработки программного обеспечения с помощью непрерывной интеграции

2025-06-11

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

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

Непрерывная интеграция — это практика, в рамках которой системы управления версиями интегрируются с конвейерами разработки ПО для предоставления автоматизированных механизмов сборки, тестирования и получения отзывов для команд разработчиков.

Процесс непрерывной интеграции начинается, когда инженер создает запрос на извлечение из GitHub, чтобы сигнализировать системе CI о том, что изменения кода готовы к интеграции. В идеале процесс интеграции проверяет код на соответствие нескольким базовым показателям и тестам. Затем он предоставляет запрашивающему инженеру обратную связь о состоянии этих тестов.

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

Непрерывная интеграция может помочь вам быстрее предоставлять высококачественное программное обеспечение, выполнив следующие действия:

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

Автоматизация непрерывной интеграции с конвейерами

Чтобы обеспечить непрерывную интеграцию, используйте программные решения для управления, интеграции и автоматизации процесса. Распространенная практика заключается в использовании конвейера непрерывной интеграции.

Конвейер непрерывной интеграции включает в себя часть программного обеспечения (часто размещенного в облаке), которая предоставляет:

Платформа для выполнения автоматизированных тестов.
Проверки соответствия требованиям.
Отчеты.
Все остальные компоненты, составляющие процесс непрерывной интеграции.

В большинстве случаев программное обеспечение конвейера подключено к системе управления версиями так, что когда создаются пулл-реквесты или программное обеспечение объединяется в определенную ветвь, запускается конвейер непрерывной интеграции. Интеграция системы управления версиями также дает возможность предоставлять обратную связь CI непосредственно по запросам на извлечение.

Многие решения, такие как Azure Pipelines или GitHub Actions, предоставляют возможности конвейеров непрерывной интеграции.

Интеграция конвейеров с системой управления версиями

Интеграция вашего конвейера непрерывной интеграции с вашей системой управления версиями является ключом к обеспечению быстрого и самостоятельного внесения кода.

Конвейер CI запускается по вновь созданному запросу на извлечение. В конвейер входят все тесты, оценки безопасности и другие проверки. Результаты CI-тестирования отображаются непосредственно в запросе на извлечение, что позволяет получать обратную связь о качестве практически в реальном времени.

Другая популярная практика — создание небольших отчетов или значков, которые можно представить в системе управления версиями, чтобы сделать видимыми текущие состояния сборки.

На следующем изображении показана интеграция между GitHub и конвейером Azure DevOps. В этом примере создание Pull Request активирует конвейер Azure DevOps. Статус конвейера отображается в запросе на извлечение.

Снимок экрана: значок состояния Azure DevOps в репозитории GitHub.

Включение автоматизированных тестов

Ключевым элементом непрерывной интеграции является постоянное сборка и тестирование кода по мере того, как разработчики вносят свой вклад в код. Тестирование запросов на вытягивание в момент их создания дает быстрый отзыв о том, что коммит не внес ломающие изменения. Преимущество состоит в том, что тесты в конвейере непрерывной интеграции могут быть теми же тестами, которые выполняются во время разработки через тестирование.

В следующем фрагменте кода показан тестовый шаг из конвейера Azure DevOps. На шаге есть две задачи:

Первая задача использует популярную платформу тестирования Python для выполнения тестов CI. Эти тесты находятся в системе контроля версий вместе с кодом Python. Результаты теста записываются в файл test-results.xml.
Вторая задача использует результаты теста и публикует их в конвейере Azure DevOps в виде интегрированного отчета.

- script: |
    pip3 install pytest
    pytest azure-vote/azure-vote/tests/ --junitxml=junit/test-results.xml
    continueOnError: true

- task: PublishTestResults@2
    displayName: 'Publish Test Results'
    inputs:
    testResultsFormat: 'JUnit'
    testResultsFiles: '**/test-results.xml'
    failTaskOnFailedTests: true
    testRunTitle: 'Python $(python.version)'

На следующем рисунке показаны результаты теста, которые отображаются на портале Azure DevOps.

Снимок экрана: тесты конвейера Azure DevOps на портале Azure DevOps.

Тесты со сбоями

Неудачные тесты должны временно заблокировать развертывание и привести к более глубокому анализу произошедшего. Неудачные тесты также должны привести либо к уточнению тестов, либо к улучшению изменений, которые привели к провалу тестов.

Публикация состояния сборки

Многие разработчики показывают, что качество кода является высоким, отображая индикатор состояния в своем репозитории. На следующем рисунке показан значок Azure Pipelines, отображаемый в файле readme для проекта с открытым исходным кодом в GitHub.

Оптимизация времени сборки

Чтобы ускорить сборку, можно:

Выберите агенты, соответствующие вашим требованиям к производительности: ускоряйте сборки, выбрав нужные компьютеры сборки. Быстрые машины могут сократить время выполнения задач с часов до минут. Если конвейеры находятся в Azure Pipelines, вы можете выполнять задания с помощью размещенного корпорацией Майкрософт агента. При использовании агентов, размещенных на серверах Microsoft, обслуживание и обновление выполняются автоматически. Дополнительные сведения см. в разделе "Размещенные корпорацией Майкрософт агенты".
Оптимизируйте расположение сервера сборки: при создании кода данные отправляются по сети. Входные данные для сборок извлекаются из репозитория системы управления версиями и репозитория артефактов. Выходные данные процесса сборки необходимо скопировать, включая скомпилированные артефакты, тестовые отчеты, результаты покрытия кода и символы отладки. Важно, чтобы эти действия копирования выполнялись быстро. Если вы используете собственный сервер сборки, убедитесь, что сервер сборки находится рядом с источниками и целевым расположением. Быстрые отправки и загрузки могут сократить общее время сборки.
Масштабирование серверов сборки: для небольшого продукта может быть достаточно одного сервера сборки. По мере увеличения размера и области продукта и количества команд, работающих над продуктом, может быть недостаточно одного сервера. Масштабируйте инфраструктуру по горизонтали, распределяя её по нескольким машинам, когда достигнут предел. Дополнительные сведения см. в статье "Создание пулов агентов и управление ими".
Оптимизация сборки:
- Добавьте параллельные задания для ускорения процесса сборки. Дополнительные сведения см. в разделе "Настройка и оплата параллельных заданий".
- Включите параллельный запуск тестовых наборов, которые часто экономят много времени, особенно при выполнении интеграционных и UI-тестов. Дополнительные сведения см. в разделе "Параллельное выполнение тестов" для любого тестового средства выполнения.
- Используйте понятие множителя, чтобы масштабировать ваши сборки на нескольких агентах сборки. Дополнительные сведения см. в разделе Указание заданий в конвейере.
- Рассмотрите возможность переноса интеграционных, пользовательских интерфейсов и смоук-тестов в конвейер релиза. Переход к конвейеру выпуска повышает скорость сборки и скорость цикла обратной связи сборки.
- Опубликуйте артефакты сборки в решении для управления пакетами, например NuGet или Maven. Публикация в решении для управления пакетами позволяет легко использовать артефакт сборки.

Реализация типов сборки для соответствия рабочим процессам

Ваша организация может выбрать создание нескольких различных типов сборок для оптимизации времени сборки. Возможные сборки:

Сборка непрерывной интеграции (CI): цель этой сборки заключается в том, чтобы код компилировался и модульные тесты выполнялись. Эта сборка запускается при каждом коммите. Он служит пульсом проекта и предоставляет качественные отзывы команде im_imagestely. Дополнительные сведения см. в разделе "Указание событий, которые активируют конвейеры".
Ночная сборка: цель ночной сборки заключается не только в компиляции кода, но и в обеспечении того, чтобы любые более обширные тестовые наборы, которые неэффективно выполняются, осуществлялись на регулярной основе для каждой сборки. Как правило, эти тесты включают интеграцию, пользовательский интерфейс или тесты дыма. Дополнительные сведения см. в разделе Настройка расписаний для конвейеров.
Релизная сборка: Помимо компиляции и выполнения тестов, эта сборка также компилирует API-документацию, отчеты о соответствии, подписывает код и выполняет другие действия, которые не требуются при каждом построении кода. Эта сборка предоставляет эталонную копию, которая отправляется в конвейер выпуска, чтобы, наконец, внедрить в рабочей среде.

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

Узнайте, как создать конвейер непрерывной интеграции с помощью GitHub или Azure DevOps:

Научитесь, как отображать бейджи в ваших репозиториях.

Поделиться через