CI/CD для монорепозиториев
Изучите стратегии оптимизации конвейеров CI/CD в монорепозиториях, включая выборочный запуск заданий на основе изменённых файлов.
«CI/CD для монорепозиториев» — бесплатный урок CI/CD with GitHub Actions & DevOps Pipelines на CoddyKit. Это урок 1 из 4. Ты можешь прочитать весь урок бесплатно ниже — а потом практиковать его прямо в браузере с встроенным редактором кода и ИИ-репетитором 24/7. Это часть пути обучения CI/CD with GitHub Actions & DevOps Pipelines, и твой прогресс синхронизируется между веб-версией и приложением CoddyKit. Курс CI/CD with GitHub Actions & DevOps Pipelines содержит 4 уроков всего.
Что такое монорепозиторий?
Монорепозиторий — это единый репозиторий, содержащий код множества проектов или приложений. Вместо отдельных репозиториев для каждого сервиса или библиотеки все находится в одном месте.
Представьте большую библиотеку, в которой много книг (проектов) находятся в одном здании (репозитории), а не в отдельном здании для каждой книги. Такой подход имеет свои преимущества и недостатки, особенно в отношении непрерывной интеграции и доставки.
Проблемы непрерывной интеграции и доставки в монорепозитории
Хотя монорепозитории упрощают, например, совместное использование кода, они могут создавать сложности для конвейеров непрерывной интеграции и доставки (CI/CD):
- Медленные сборки: если каждое изменение запускает полную сборку и набор тестов для *всех* проектов, конвейеры становятся очень медленными.
- Растрата ресурсов: ненужный запуск заданий, не связанных с изменениями, расходует минуты сборки и ресурсы.
- Недовольство разработчиков: длительные циклы обратной связи могут замедлить разработку.
Необходимость выборочной непрерывной интеграции и доставки
Ключ к эффективной непрерывной интеграции и доставке в монорепозитории — избирательность. Наши конвейеры должны достаточно разумно уметь:
- Определять, *что* изменилось.
- Запускать задания непрерывной интеграции и доставки *только* для проектов, затронутых этими изменениями.
Такой подход экономит время, снижает потребление ресурсов и обеспечивает разработчикам более быструю обратную связь.
Запуск по путям: `on.paths`
GitHub Actions предоставляет мощный способ добиться избирательности с помощью фильтра paths в триггерах рабочего процесса. Вы можете указать каталоги или файлы, изменения в которых должны запускать рабочий процесс.
Если изменится файл вне этих путей, рабочий процесс не запустится. Это идеально подходит для монорепозиториев!
on:
push:
branches:
- main
paths:
- 'apps/frontend/**'
- 'libs/shared/**'Фильтр путей в действии
Ниже приведен простой рабочий процесс, который запускается только при отправке изменений в файлы внутри каталога apps/backend или в конкретный файл README.md.
Это гарантирует, что для серверной службы запускаются только относящиеся к ней тесты или сборки.
name: Backend CI
on:
push:
branches:
- main
paths:
- 'apps/backend/**'
- 'README.md'
jobs:
build-backend:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- name: Build backend app
run: echo "Building backend..."Игнорирование путей: `paths-ignore`
Иногда нужно, чтобы рабочий процесс запускался для *большинства* изменений, но не запускался, если изменены только определенные файлы (например, документация или файлы журналов). Для этого отлично подходит фильтр paths-ignore.
Он работает подобно фильтру paths, но указывает файлы, которые *не должны* запускать рабочий процесс.
on:
pull_request:
branches:
- main
paths-ignore:
- 'docs/**'
- '**/*.md'Динамические выборочные запуски с помощью `git diff`
Для более сложной логики можно использовать команды Git, например git diff, внутри этапов рабочего процесса, чтобы динамически проверять изменения. Это позволяет создавать собственные условия.
Например, можно проверить, произошли ли изменения в определенной папке, и задать выходную переменную, которая определит, следует ли запускать последующее задание.
Пример условного выполнения задания
Этот этап рабочего процесса использует git diff, чтобы проверить, изменились ли какие-либо файлы в apps/api/ между текущей фиксацией и базовой веткой. Если да, он задает выходную переменную api_changed со значением 'true'.
Затем этот результат может управлять запуском задания «развернуть API».
jobs:
check-changes:
runs-on: ubuntu-latest
outputs:
api_changed: ${{ steps.diff.outputs.api_changed }}
steps:
- uses: actions/checkout@v4
- name: Check API changes
id: diff
run: |
if git diff --quiet ${{ github.event.before }} ${{ github.sha }} -- apps/api/;
then
echo "api_changed=false" >> $GITHUB_OUTPUT
else
echo "api_changed=true" >> $GITHUB_OUTPUT
fi
deploy-api:
needs: check-changes
if: needs.check-changes.outputs.api_changed == 'true'
runs-on: ubuntu-latest
steps:
- name: Deploy API
run: echo "Deploying API..."Структура монорепозитория для непрерывной интеграции и доставки
Организованная структура монорепозитория значительно упрощает выборочную непрерывную интеграцию и доставку. Группировка связанных файлов и проектов в четко определенных каталогах облегчает эффективное использование фильтров paths.
/apps/frontend/apps/backend/libs/shared/docs
Четкое разделение позволяет точно выбирать цели рабочих процессов.
Тест по непрерывной интеграции и доставке в монорепозитории
Оптимизация непрерывной интеграции и доставки для монорепозиториев имеет решающее значение для поддержания темпа разработки и эффективного использования ресурсов. Подумайте, какие стратегии лучше всего решают проблемы большой объединенной кодовой базы.
Итоги и дальнейшие шаги
Вы узнали, как решать проблемы непрерывной интеграции и доставки в монорепозиториях с помощью выборочного выполнения заданий. Используя фильтры paths GitHub Actions и расширенные методы git diff, Вы можете гарантировать, что конвейеры запускают только необходимые операции.
Это обеспечивает более быструю обратную связь, снижает расходы и делает процесс разработки более удобным. Продолжайте изучать способы точной настройки рабочих процессов для еще большей эффективности!
Часто задаваемые вопросы
Урок «CI/CD для монорепозиториев» бесплатный?
Да — полный текст урока «CI/CD для монорепозиториев» бесплатно доступен здесь в веб-версии. Чтобы практиковать его интерактивно (встроенный редактор кода и ИИ-репетитор 24/7) и разблокировать остальной курс CI/CD with GitHub Actions & DevOps Pipelines, подпишись на CoddyKit PRO. Курс CI/CD with GitHub Actions & DevOps Pipelines содержит 4 уроков всего.
Чему я научусь в уроке «CI/CD для монорепозиториев»?
Изучите стратегии оптимизации конвейеров CI/CD в монорепозиториях, включая выборочный запуск заданий на основе изменённых файлов. Ты практикуешь CI/CD with GitHub Actions & DevOps Pipelines с помощью реального кода, который запускаешь прямо в браузере, и ИИ-репетитор 24/7 отвечает на твои вопросы во время урока.
Нужен ли мне опыт, чтобы начать CI/CD with GitHub Actions & DevOps Pipelines?
Предыдущий опыт не требуется. CI/CD with GitHub Actions & DevOps Pipelines на CoddyKit структурирован для всех уровней — от новичков до продвинутых, поэтому ты можешь начать отсюда или с самого начала и учиться в своем темпе. Это урок 1 из 4.
Сколько времени занимает урок «CI/CD для монорепозиториев»?
Большинство уроков CoddyKit занимают около 5–10 минут. Каждый из них компактный и интерактивный, поэтому ты постоянно делаешь прогресс и продолжаешь с того же места в веб-версии и приложении.
Можно ли писать и запускать код в этом уроке CI/CD with GitHub Actions & DevOps Pipelines?
Да. Каждый урок CI/CD with GitHub Actions & DevOps Pipelines включает встроенный редактор кода, поэтому ты пишешь и запускаешь реальный код прямо в браузере и получаешь моментальную обратную связь от AI — локальная установка не требуется.
Все уроки этого курса
- CI/CD для монорепозиториев
- Рабочие процессы между репозиториями
- Централизованное управление рабочими процессами
- Фильтрация по путям и выборочные сборки