Интеграция Nx с облачными инструментами совместной работы

Эти инструменты имеют общие функции: запросы на вытягивание, защита филиалов, веб-хуки и REST API. Однако каждый из них имеет уникальные сильные стороны. GitHub превосходит в сообществе и действиях; GitLab сияет в цикле DevOps с одним приложением; Bitbucket глубоко интегрируется с Jira; Azure DevOps предлагает тесную связь с сервисами Azure для развертывания предприятий.

Почему Nx интегрируется с облачными платформами?

Сочетание Nx с облачным инструментом для совместной работы открывает преимущества, которые выходят за рамки базового контроля версий.

• Реальные инкрементные сборки и испытания в CI — Nx может повторно использовать кэшированные выходы через CI-прогоны, поэтому только затронутые проекты перестраиваются или перепроверяются.
• Осознание графика автоматизированной зависимости — Когда разработчик продвигает изменение, Nx знает, какие библиотеки зависят от этого изменения и может соответственно ограничить область CI.
• Последовательные локальные и удаленные выполнения — разработчики запускают те же команды локально, что и в CI, устраняя проблемы «работы на моей машине».
• Усовершенствованный обзор кода — Nx генерирует явные графики зависимостей и наборы изменений, помогая рецензентам понять влияние PR без угадывания.
• Масштабируемое управление монорепо (FLT: 1) — облачные платформы обеспечивают соблюдение политики филиалов и требуемых проверок; Nx гарантирует, что эти проверки являются быстрыми и точными.
• Улучшенная видимость — журналы трубопроводов CI, реестры артефактов и сроки сборки хранятся в облаке, что делает их доступными для аудита и совместного использования в командах.

Как интегрировать Nx с инструментами облачного взаимодействия

Шаг 1: Настройте свой облачный хранилище

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

Шаг 2: Настройте рабочее пространство Nx для подключения к хранилищем

Если у вас уже есть рабочее пространство Nx, вы можете связать его с удаленным хранилищем, используя . Для новых проектов используйте генераторы проектов Nx (. После создания нажмите начальный коммит. Важно включить Nx Cloud (собственная служба удаленного кэширования Nx) для совместного использования артефактов сборки между членами команды и бегунами CI. Бесплатный уровень обычно охватывает небольшие команды, в то время как платные планы расширяются для корпоративного использования.

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

{
 "tasksRunnerOptions": {
 "default": {
 "runner": "nx/tasks-runners/default",
 "options": {
 "cacheableOperations": ["build", "test", "lint", "e2e"],
 "accessToken": "…",
 "canTrackAnalytics": false
 }
 }
 }
}

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

Шаг 3: Создание трубопроводов CI/CD для автоматизированного тестирования и развертывания

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

Ниже приведены примеры типичных платформ.

GitHub Действия

Создайте [[Флт:14]]:

name: CI
on:
 push:
 branches: [main]
 pull_request:
jobs:
 main:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v3
 with:
 fetch-depth: 0
 - uses: actions/setup-node@v3
 with:
 node-version: 18
 cache: 'npm'
 - run: npm ci
 - uses: nrwl/nx-set-shas@v3
 - run: npx nx workspace-lint
 - run: npx nx format:check
 - run: npx nx affected --target=lint --parallel=3
 - run: npx nx affected --target=test --parallel=3 --ci --code-coverage
 - run: npx nx affected --target=build --parallel=3

Действие FLT:16 гарантирует, что Nx сравнивает правильный диапазон обязательств. Без него Nx может подумать, что все проекты затронуты.

GitLab CI

[[[Флт:17]]]:

image: node:18
stages:
 - setup
 - lint
 - test
 - build
before_script:
 - npm ci
 - npx nx sync-deps
setup:
 stage: setup
 script:
 - echo "Environment ready"
lint:
 stage: lint
 script:
 - npx nx affected:lint --parallel=3
test:
 stage: test
 script:
 - npx nx affected:test --parallel=3 --ci --code-coverage
build:
 stage: build
 script:
 - npx nx affected:build --parallel=3
 artifacts:
 paths:
 - dist/

Чтобы использовать удаленное кэширование Nx Cloud в GitLab, выставьте в качестве переменной среды CI.

Трубопроводы Bitbucket

Создать [[ФлТ:20]]:

image: node:18
pipelines:
 pull-requests:
 '**':
 - step:
 name: Lint, Test, and Build
 caches:
 - node
 script:
 - npm ci
 - npx nx affected:lint --parallel=3
 - npx nx affected:test --parallel=3 --ci --code-coverage
 - npx nx affected:build --parallel=3

Azure DevOps

Используйте файл :

trigger:
 - main
pr:
 branches:
 include:
 - '*'
pool:
 vmImage: 'ubuntu-latest'
steps:
 - task: NodeTool@0
 inputs:
 versionSpec: '18.x'
 - script: npm ci
 displayName: 'Install dependencies'
 - script: npx nx affected --target=lint --parallel=3
 displayName: 'Lint'
 - script: npx nx affected --target=test --parallel=3 --ci --code-coverage
 displayName: 'Test'
 - script: npx nx affected --target=build --parallel=3
 displayName: 'Build'

[[ФЛТ:24]] как переменная трубопровода.

Шаг 4: Используйте веб-хуки или API-интеграции для запуска сборок

Большинство инструментов облачной совместной работы уже запускают трубопроводы автоматически на событиях запроса нажатия или вытягивания. Однако вы можете захотеть точно настроить триггеры: например, пропустить CI для изменений только для документации или запустить полную сборку только при слиянии с основной. Nx может помочь, обнаруживая затронутые проекты до полного запуска трубопровода. Некоторые команды реализуют предзадание, которое запускает , чтобы определить, какие приложения должны быть развернуты, а затем условно запускает этапы развертывания.

Шаг 5: Мониторинг и оптимизация рабочего процесса

После интеграции просмотрите статистику трубопроводов: среднее время, скорость попадания кэша и частоту отказов. Nx Cloud предоставляет панель инструментов, которая показывает использование кэша и распределение задач. Настройте правила кэширования, увеличьте параллелизм или добавьте удаленное кэширование, если скорость попадания кэша падает. Кроме того, правила защиты от ответвлений - убедитесь, что требуемые проверки состояния соответствуют шагам трубопровода и что вы не блокируете PR без необходимости для несвязанных проектов.

Лучшие практики для Nx + облачное сотрудничество

• Использовать репозиторий с одним источником правды — Хранить весь код и конфигурацию в монорепо.Избегать разделения файлов конфигурации на несколько репозиториев для предотвращения дрейфа.
• Принять обычные обязательства — Используйте префиксы, такие как , , , чтобы сделать заметки о выпуске и версификацию проще. Инструменты, такие как , могут быть интегрированы с Nx и облачным CI.
• Поддерживайте хорошо структурированные рабочие пространства — используйте генераторы Nx для создания согласованных проектов. в для обеспечения соблюдения ограничений зависимости (например, «приложения не могут импортировать из других приложений»).
• Вентиляторы качества кода принудительного исполнения — Используйте правила подкладки, проверки форматирования (]) и проверки типа в CI. Эти шаги могут выполняться параллельно, но помните о распределении ресурсов.
• Кэш агрессивно — Включите удаленное кэширование (Nx Cloud) не только для сборок, но и для тестов.Убедитесь, что список включает в себя все операции, которые являются детерминированными.
• Установите политику филиала — Требуйте проверки статуса из трубопровода CI, применяйте линейную историю и ограничивайте прямые толчки до основного. Nx может помочь, создав список затронутых проектов для описания PR.
• Рабочие процессы документов — Создайте , который объясняет, как настроить репозиторий, запустить команды Nx и интерпретировать сбои CI.
• Стоимость сборки монитора — Многие облачные инструменты взимают плату за минуты сборки. Nx сокращает минуты, пропуская незатронутые проекты. Кроме того, используйте самоорганизующиеся бегуны, если у вас есть высокочастотные фиксации.

Потенциальные проблемы и как их преодолеть

Интеграция не лишена препятствий. Вот общие вопросы и решения:

• Длинный начальный CI запускается — Первый запуск после настройки удаленного кэширования будет медленным, потому что кэша не существует. Используйте семенной CI, запустимый на главной ветке, чтобы заполнить кэш, или запустите полную сборку вручную.
• Недействительность кэша — Если сборки не детерминированы (например, временные метки, переменные среды), кэш может быть неправильно использован повторно. Убедитесь, что ваши команды сборки являются чистыми функциями входов (исходный код и конфигурация).
• Глубина ветки в кассе — Nx требует полной истории Git для вычисления затронутых проектов. Убедитесь, что вы проверили с или аналогичным флагом.
• Доступ к безопасности токенов — Храните и другие секреты в качестве зашифрованных переменных в платформе CI/CD, а не в репозитории.
• Сложность трубопровода — По мере роста монорепо трубопровод может стать медленным даже при использовании Nx. Рассмотрите возможность использования распределенного выполнения задач (Nx Agents) для разделения задач на несколько машин CI.

Реальные случаи использования в мире

Крупные организации уже извлекают выгоду из этой интеграции. Например, финтех-компания, использующая Nx с GitLab, сократила время CI с 45 минут до менее 5 минут для большинства запросов на тянет. Они добились этого, включив удаленное кэширование и запуск только пострадавших тестов. Другая команда, использующая GitHub Actions и Nx, снизила частоту отказов в развертывании на 70%, потому что PR теперь включают автоматические аннотации графа зависимости, помогая рецензентам улавливать непреднамеренные побочные эффекты.

Стартапы используют этот стек для поддержания скорости при росте от 5 до 50 инженеров. Стартап SaaS переместился из отдельных репозиториев в монорепо Nx, интегрированное с Bitbucket Pipelines, сократив время входа разработчиков с двух дней до двух часов и вдвое сократив количество конфликтов слияния.

Рассмотрение вопросов безопасности

При интеграции Nx с облачными инструментами необходимо учитывать следующие аспекты безопасности:

• Аудит зависимости — Запустите или в CI, чтобы поймать известные уязвимости. Используйте для охвата аудитов измененные зависимости.
• Управление секретами — Никогда не разглашайте секреты. Используйте секретный магазин облачной платформы (например, GitHub Secrets, GitLab CI Variables). Для локальной разработки используйте файлы , перечисленные в .
• Создание изоляции среды — CI работает в эфемерных контейнерах; однако, если вы используете бегунов с саморазмещением, убедитесь, что они исправлены и изолированы.
• Атаки цепочки поставок — версии зависимостей от Pin в файлах блокировки пакетов и рассмотреть возможность использования хэши целостности npm. Кэш Nx может непреднамеренно распространять скомпрометированный артефакт, поэтому разумно обеспечить соблюдение подписанных обязательств и пересмотреть изменения в файлах конфигурации.