Frontier: Друзья, вы все еще вручную "теряете пакеты"? Было бы неплохо быть механизированным носильщиком? Вы хотите научиться автоматизированному построению конвейера ~ Если вы хотите, это подходит для вас, в сочетании с CICD для автоматизации построения интерфейсных проектов, в этой статье рассказывается, как запустить CI/CD на основе jenkins и Трэвис, освободи руки 👋, попрощайся с 996
1. Древние времена
Мы знаем, что для общих SPA-приложений суть статические ресурсы (бэкенд рендеринга SSR игнорируется), выполнить команду сборки, запаковать и собрать проект, сжать упакованные файлы, подключиться к серверу по ssh и "кинуть" сжатые файлы. Перейдите на сервер, распакуйте загруженные файлы и, наконец, настройте Nginx для доступа к ресурсам проекта. Мы прошли этот процесс в каменном веке. Процесс выглядит следующим образом
Нам, вероятно, нужно сделать следующее
- местное исполнение
npm run buildСоберите проект и сожмите скомпилированные файлы ресурсов. - Перетащите сжатый пакет на удаленный сервер
- ssh на удаленный сервер, извлеките сжатый пакет
- настроить nginx
2. Железный век
Позже у фронтенда появился свой тулчейн.Чтобы проверить надежность и функциональную целостность кода перед релизом, в процесс релиза были добавлены модульное тестирование и сканирование кода.После проверки последний код вручную протягивался через сервер ( git), а затем собрать и скомпилировать проект, и, наконец, настроить Nginx для доступа к ресурсам проекта.Мы следовали процессу в железном веке.Процесс выглядит следующим образом
Чтобы завершить полный релиз клиентского проекта с обратной связью, нам, вероятно, потребуется выполнить следующие операции.
- сканирование кода
npm run lintПроверяем, что код канонический (eslint) - Запускайте модульные тесты локально
npm run unitПроверить результаты юнит-тестов - использовать
gitОтправьте протестированный код в удаленный репозиторий, напримерgitlab - Войдите на удаленный тестовый сервер, извлеките код и выполните
npm run buildПостроить проект - Если это серверный проект рендеринга (SSR), если он основан на pm2 для управления процессами, его необходимо перезапустить.
pm2 restart
Каждый релиз требует ручной "потери пакетов", а механизированная работа повторяется постоянно. Можно представить себе, насколько низкой будет эффективность, и труднее гарантировать, что каждый шаг не будет игнорироваться каждый раз. Вы можете забыть сделать блок тестировать и запускать код, отправлять, вызывать программные ошибки и т.д.
Думал: 👨🎓Ах Ле: Тогда я могу интегрировать эти детали в сценарий оболочки, чтобы это не было автоматизировано?
3. Эпоха CICD
Что такое ЦИКД? Как следует из названия, это непрерывная интеграция и непрерывная доставка, Простое понимание заключается в том, чтобы автоматизировать связи развертывания и построения, которые нам необходимо выполнить вручную, прежде чем за один шаг освободить руки
👨🎓 А Куан: Я до сих пор не понимаю разницы между непрерывной интеграцией и непрерывной доставкой
- Непрерывная интеграция: при изменении кода хранилища кода код будет автоматически тестироваться и создаваться, а текущие результаты будут возвращены.
- Непрерывная доставка. Непрерывная доставка основана на непрерывной интеграции, а интегрированный код может быть развернут в тестовой среде, предварительной версии, рабочей среде и т. д.
🌲 Дополнительное чтение:
Итак, какие инструменты у нас есть, чтобы помочь нам выполнить эту серию операций? Я обычно использую два метода:Jenkins CI/CDа такжеTravis CI
3.1 Travis CI
Travis CI — это один из методов реализации сервисов непрерывной интеграции, но он немного «связан» с GitHub, что неотделимо, поскольку Travis поддерживает только платформы для размещения кода, такие как github и gitlab. Так как же Travis осуществляет непрерывную интеграцию? Пока в репозитории кода есть новые изменения кода, он автоматически захватывает, а затем завершает тестирование и сборку. Следующий 🌲Sauce познакомит вас с правильным использованием «Travis» путем создания github. проект, прикрепите ссылку на официальный сайт🔗Travis-ci
3.1.1 Подготовка
1. Вам необходимо зарегистрировать свою эксклюзивную учетную запись travis-ci на travis-ci.org, затем привязать свой github и выбрать проект, который вы хотите интегрировать, после входа в систему.
2. После выполнения вышеперечисленного создайте файл в корневом каталоге проекта, в котором вы хотите выполнить непрерывную интеграцию..travis.yml, смысл этого файла в том, чтобы предопределить поведение Трэвиса.
Когда в репозитории кода появится новый коммит, Трэвис перейдет в корневой каталог проекта, чтобы найти файл и выполнить команду внутри.Давайте посмотрим, что определил соус дерева..travis.yml
Приведенное выше определение в основном состоит из следующих основных конфигураций 👇
-
language: поле указывает среду выполнения по умолчанию -
node_js: Используется для указания версии Node. -
install: используется для указания сценария установки или зависимостей -
script: запустить скрипт
install阶段а такжеscript阶段, вот деталь, чтобы различать:
- Если одна из задач на этапе установки завершается сбоем, вся задача прерывается, и состояние всей фазы сборки также становится ошибочным.
- Если одна из задач на этапе сценария завершается сбоем, задача выполняется, а состояние этапа сборки такое же, как и при сбое установки.
3. Когда код в репозитории кода изменится, Travis автоматически запустит и выполнит ваш.travis.ymlОпределенные команды для завершения тестов и сборок
3.1.2 Практическое использование
👩🎓Эль одноклассник: Что, если соус из дерева — это ошибка в процессе КИ?
Проект будет более или менее терпеть неудачу во время сборки и тестирования.Ниже приведен реальный пример ошибки модульного теста.При возникновении ошибки поведение CI будет прервано (поскольку соус дерева настраивает команду модульного теста на этапе установки)
Выше приведена простая небольшая демонстрация travis для автоматической интеграции.Travis может делать много вещей, например создавать свою страницу Github и т. д.
🌲 Дополнительное чтение:
- Элегантно опубликуйте собственную книгу, используя страницы travis + gitbook + github.
- Учебное пособие Travis CI по службе непрерывной интеграции
3.2 Jenkins CI/CD
В предыдущем разделе мы представили travis, и мы также знаем, что travis полагается на github для управления хранилищем кода, что, если компания использует svn вместо git для внутренних целей? Хотя git сейчас является мейнстримом, jenkins более масштабируем, и его поддерживают как git, так и svn. В то же время jenkins, как расширяемый сервер автоматизации, может использоваться как простой CI-сервер с такими функциями, как автоматическая сборка, тестирование и развертывание, Короче говоря, jenkins может облегчить нашу ежедневную итерацию обновления версии проекта (разработка, среда тестирования, производства и т. д.), или он может автоматизировать ряд операций, включая компиляцию, упаковку, мета-тестирование, сканирование кода и т. д.
Следующие сборки создаются путем введения двух конфигураций сборки: конфигурации по умолчанию и конфигурации конвейера.
3.2.1 Режим 1: изменение конфигурации по умолчанию
- Управление исходным кодом, первое — это настройка репозитория кода.
- Build Triggers
Выберите режим триггера сборки, по умолчанию — ручной триггер, поддержка сборки, запускаемой кодом, и сборка по времени.
- команда сборки
Выберите команду скрипта для выполнения
- Post-build Actions
В основном используется для многоузлового удаленного развертывания кластера.
Вы можете добавить несколько компьютеров для удаленного доступа, загрузить упакованные ресурсы после сборки на несколько узлов для обновления ресурсов.
3.2.2 Режим 2: конфигурация конвейера Jenkins
Эта статья в основном знакомит с использованием конфигурации конвейера jenkins. Код конвейера определяет весь процесс сборки, который обычно включает этапы сборки, тестирования и доставки приложения. Ниже приведена конфигурация пути и хранилища.
Конфигурация, связанная с изображением, выглядит следующим образом:
- SCM: выберите git или svn в качестве триггера кода
- Путь к сценарию: создайте файл jenkins в корневом каталоге проекта для записи конвейера.
Далее представлена простая версия метода написания задач конвейера jenkinsfile для завершения компиляции и упаковки, статического сканирования, модульного тестирования и других ссылок, связанных со всем развертыванием переднего плана.
После завершения вы можете построить проект и завершить его поэтапно.Первый шаг — извлечь исходный код, построить и скомпилировать код, отсканировать код и т. д. Автоматическое развертывание будет успешным только тогда, когда все ссылки будут успешными, так как показано ниже.
🌲Предыдущие статьи Соуса:
- Построение интерфейсной системы знаний Шуцзяна (часть 1)
- Построение внешней системы знаний Шуцзяна (ниже)
- Расскажите об инструментах ежедневной совместной работы для фронтенд-разработки
- Конфигурацию Babel тупо не могу понять
- Как лучше управлять интерфейсом API
- Что интервьюер спросил вас об узле
- передовой инжиниринг
- Вы изучили BFF и Serverless?
- Развертывание интерфейсной эксплуатации и обслуживания
Пожалуйста, выпейте 🍵 Не забудьте подключиться три раза~
1. После прочтения не забудьте поставить лайк 🌲 соусу, там есть 👍 и мотивация
2. Обратите внимание на интересные вещи в интерфейсе официального аккаунта и пообщайтесь с вами об интересных вещах в интерфейсе.
3. Статья размещена на GithubfrontendThingsСпасибо, Стар✨