CI/CDЭто аббревиатура Continuous Integration/Continuous Deploy, что переводится какНепрерывная интеграция/непрерывное развертывание. CD также интерпретируется какнепрерывная поставка(непрерывная поставка), но для разработчиков программного обеспечения самым непосредственным контактом должно быть непрерывное развертывание.

Когда я только начал работать, я познакомился с концепцией CI, которая в то время в основном использовалась командой QA (Quality Assurance).hudsonВыполните качественное сканирование проекта и запустите несколько основных автоматических тестов. Самая впечатляющая сцена в то время была, когда QA сказал мне: «Ваш код находится в состоянии статического оповещения, пожалуйста, быстро измените его...».

Когда я думаю об этом сейчас, я не могу не удивиться: "А? Мы не использовали ESLint в то время? Я не могу вспомнить..." Итак, я пролистал запись обновления ESLint и обнаружил, что номер основной версии ESLint только что достиг 3 в то время, VSCode Плагин ESLint все еще является относительно ранней версией и, возможно, еще не популярен.

Позже я также постепенно услышал некоторые термины, такие как Jenkins и Travis CI, но, поскольку они слишком ленивы, я не могу использовать ни один из них.

И я обнаружил, что меня не интересует CI/CD, почему? Потому что у меня пока нет мотивации его использовать.

создавать / развертывать эти вещи

Простая точка сборки/развертывания состоит в том, чтобы использовать такие инструменты, как webpack или gulp, для упаковки проекта, а затем помещать упакованные файлы в веб-контейнер, в котором размещаются статические ресурсы на сервере.Например, Java можно поместить в Tomcat.Однако , сейчас популярно использовать Nginx для размещения статических ресурсов. С веб-контейнером можно получить доступ к файлам, упакованным внешним интерфейсом (таким как index.html, main.js и т. д. Я думаю, все это понимают.

С 2016 по 2018 я не отвечал за упаковку и развертывание (с другой стороны, потому что у фронтенда вообще не было разрешения трогать сервер, эммм...), поэтому я не обращал внимания на упаковку и развертывание вообще.

В 2018 и 2019 годах я начал отвечать за упаковку и развертывание. На тот момент опыта в этой области вообще не было, и команды Linux все стучали на сторону Baidu. Но я точно помню, что видел их в кабинете тестовой группы.xshellа такжеxftp, После использования этих двух инструментов, я думаю, что развертывание действительно простое, мне просто нужно запустить скрипт, спокойно дождаться окончания рабочего процесса webpack и gulp, а затем передать файл на сервер через xftp,Только будь осторожен, чтобы не ошибиться(Очевидно, что человеческая деятельность подвержена ошибкам, что также представляет собой скрытую опасность). Поскольку частота строительства и развертывания невелика, а количество проектов не очень велико, в этом году я в принципе справлюсь.

До прошлого года у меня было около 5 проектов под рукой и почти 10 фронтенд-проектов. При таком ежедневном ритме развертывания я не думаю, что xshell+xftp может меня спасти.Хотя эти проекты не выпускаются каждый день, тестовая среда все же выпускается часто.Я достаточно раздражителен, чтобы развертывать каждый день.Прервано, а также огромное пустая трата времени.

Я думаю о поиске некоторых изменений, но я все еще не думаю о CI/CD, потому что чувствую, что все еще мало знаю о CI/CD. Поэтому я подумал об использованиисценарий оболочкиЧтобы выполнить сборку/развертывание, есть две ознакомительные статьи:

• Небольшой шаг в автоматизированном развертывании, большой шаг в перемещении кирпичиков переднего плана
• Углубленная практика автоматизированного развертывания переднего плана

Опираясь на эту волну исследования сценариев, я в основном перешел кполуавтоматический的阶段了，这种焦虑的状况基本上得到了一些缓解。但是，我发现我的电脑还是扛不住，风扇急速旋转的声音能让我自闭。 . .毕竟一边跑本地开发环境，一边还可能同时跑1~2个工程的构建/部署脚本，再加上电脑运行的其他软件，这发热量你懂的！

Таким образом, работа по сборке/развертыванию не должна выполняться на моем компьютере, это утомительно.

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

Поскольку наш код размещается на самодельном сервере gitlab, я напрямую решил использовать возможности CI/CD, которые поставляются с gitlab для CI/CD. Вне работы мне потребовалось почти два дня, чтобы познакомиться сДокументация для gitlab CI/CD.

Затем я настроил окружение согласно документации, а затем раз за разом отлаживал его..gitlab-ci.ymlФайл конфигурации, я помню, что я потерпел неудачу около 11 раз, прежде чем успешно запустить Pipeline в первый раз.

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

Что именно делает CI/CD?

На самом деле, как я упоминал ранее, процесс выпуска версии в основном делится на следующие этапы:

• слияние кода: тестовая среда или производственная среда имеют независимые ветки.После того, как весь код, который должен быть выпущен, будет объединен в соответствующую ветку, можно будет рассматривать выпуск.
• Пакет: или построить. Возьмем в качестве примера развертывание рабочей среды. После того, как мы переключимся на ветку рабочей среды и получим последний код, мы можем начать этап упаковки. Этот шаг в основном выполняется каким-нибудь упаковщиком, например webpack. И команда упаковки обычно определяется вpackage.jsonизscriptsВ команде, которую я определил здесь, естьbuild:prod, так что просто бегиnpm run build:prodВот и все.
• развертывать: Поместите упакованные файлы в веб-контейнер, а веб-контейнер обычно находится на сервере Linux, что предполагает удаленную передачу файлов.В настоящее время мы обычно используем сценарии оболочки или xftp.

Что делает CI/CD:Возьмите на себя управление процессом с помощью автоматизации.

Мониторная мутация

Мой запрос:Когда код объединяется в ветку, gitlab может автоматически выполнить за меня два этапа упаковки и развертывания.

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

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

Это означает, что разработчики могут реализовать свои собственные механизмы CI/CD, не используя возможности CI/CD, предоставляемые платформой размещения кода.

PS: Конечно, в дополнение к CI / CD, также можно отправлять уведомления по SMS / электронной почте.Если вы осмелитесь попробовать, в зависимости от способности платформы открываться, мы можем сделать многое. Мы не будем заниматься саморазвитием CI/CD.Колеса, сделанные другими, были перевернуты и использованы напрямую.

Возвращаясь к теме, пока я отслеживаю изменения кода, серверная сторона автоматически выполняет скрипт сборки/развертывания.

Как работает Gitlab CI/CD

Программное обеспечение служит жизни и возникает из нее. Gitlab CI/CD разработал множество концепций, из которых я нахожу наиболее интересными:Трубопроводы и бегуны.

Pipeline

Pipeline — это компонент верхнего уровня CI/CD., что переводится как конвейер, на самом деле вы можете понять это каксборочная линия, каждый с.gitlab-ci.ymlЗадача CI/CD, запускающая правило, создаст конвейер. Эта концепция немного похожа на сборочную линию цеха на заводе.Мы знаем, что в цеху много сборочных линий, и разные сборочные линии могут обрабатывать одни и те же производственные задачи или разные типы производственных задач. Когда конвейер простаивает, его можно использовать для планирования других производственных задач. Хотя в конвейере Gitlab нет концепции бездействия, конвейер не будет повторно использоваться после выполнения, но высвобождает ресурсы для других конвейеров, поэтому он похож на конвейер мастерской.

Runner

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

Тип бегуна

В Gitlab есть много видов бегунов, которые делятся наShared Runner, Group Runner, Specific Runner.

• Shared Runner можно понимать как мобильного человека, который может работать на различных сборочных линиях завода и оказывать поддержку в любое время! Во всем приложении Gitlab Shared Runner может обслуживать каждый проект.

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

• Конкретный Runner еще мощнее, он обслуживает только указанный проект, то есть уровень Project, и мы не будем переходить к другим проектам.

Зарегистрировать бегуна

Рабочие обязаны работать с сертификатами Аналогично, у бегунов есть процесс регистрации, который эквивалентен регистрации на фабрике. Подробнее см.Registering runners. Только официально зарегистрированные участники имеют право запускать Pipeline. Однако Gitlab, похоже, не платит Бегуну зарплату!

.gitlab-ci.yml конфигурация

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

Вот так,.gitlab-ci.ymlДокументы здесь, чтобы установить правила! На самом деле, процесс CI/CD, о котором я просил, не сложен, просто помогите мне выполнить два этапа построения и развертывания. Ниже приведен пример упрощенного процесса построения и развертывания производственной среды:

workflow:
  rules:
    - if: '$CI_COMMIT_REF_NAME == "master"'

stages:
  - build
  - deploy

build_prod:
  stage: build
  cache:
    key: build_prod
    paths:
      - node_modules/
  script:
    - yarn install
    - yarn build:prod
  artifacts:
    paths:
      - dist
      
deploy_prod:
  stage: deploy
  script:
    - scp -r $CI_PROJECT_DIR username@host:/usr/share/nginx/html

Во-первых, я хочу выполнять задания сборки/развертывания только в основной ветке, что можно сделать с помощьюworkflow.rulesвнизifУсловные ограничения завершены.

Затем я хочу разделить весь процесс на два этапа, первый этапbuild, который используется для выполнения задачи сборки; второй этапdeploy, который используется для выполнения задач развертывания. Это можно сделать с помощьюstagesчтобы завершить определение.

Далее я определяю дваjob,Первыйjobдаbuild_prod,принадлежатьbuildэтап; второйjobдаdeploy_prod,принадлежатьdeployсцена.

существуетbuiild_prodэтоjob, в основном бегyarn installа такжеyarn build:prodДва сценария, файловые активы, созданные при упаковке, будут основаны наartifactsКонфигурация сохраняется на потомjobиспользовать.

существуетdeploy_buildэтоjob, в основном черезscpКоманда для передачи файлов в каталог NGINX на сервере Linux.

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

Gitlab CI/CD Variables

Gitlab черезVariablesОн предоставляет больше возможностей для конфигурации CI/CD, так что мы можем быстро получить некоторую ключевую информацию и использовать ее для принятия технологических решений. в приведенном выше примере$CI_COMMIT_REF_NAMEа также$CI_PROJECT_DIRЭто предопределенная переменная Gitlab.

В дополнение к предопределенным переменным мы также можем сами определить некоторые переменные среды, такие как ip сервера, имя пользователя и т. д., что позволяет избежать риска перечисления личной информации в открытом виде в файле конфигурации; Также удобно быстро настроить конфигурацию позже.Избегайте прямого изменения.gitlab-ci.yml.

кредитная проблема

проходить между разными хостамиscpДля передачи файлов необходимо установить доверительные отношения.В CI/CD лучше всего выбрать метод без шифрования.Основной принцип заключается в том, чтобыssh открытый ключк другой стороне. И это яНебольшой шаг в автоматизированном развертывании, большой шаг в перемещении кирпичиков переднего планаОн также упоминается в этой статье и не будет здесь повторяться.

Runner развертывается независимо

Поскольку я развернул Runner непосредственно на кодовом сервере Gitlab, а конфигурация кодового сервера, предоставленного нашей компанией, невелика, по-прежнему немного сложно запустить построение и развертывание конвейера с высокой загрузкой ЦП. работает даже при прямом сбое веб-службы Gitlab.

Товарищ по команде спросил меня: «Почему Gitlab не может открыть белый экран?»

Руководителю не потребовалось много времени, чтобы прислать мне Linux-сервер, который специально использовался для повседневной работы внешнего интерфейса. Бинго, я только что самостоятельно развернул Runner на новой машине, чтобы мои товарищи по команде не пострадали, и время для каждого выпуска напрямую сократилось с 8 минут до менее 2 минут, что действительно приятно!

Преимущества CI/CD

Интуитивно понятно, что большая часть моей повторяющейся работы была удалена, а дополнительное время я могу использовать для более важных дел, или рыбачить невкусно? Тем более, что вручную версию каждый день публиковать не приходится, да и настроение очень хорошее!

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

резюме

Эта статья, основанная на личном опыте автора, напоминает о болевых точках, с которыми столкнулся автор в процессе построения/развертывания, и фокусируется на самом простом случае Gitlab CI/CD, а также описывает авторский процесс использования CI/CD для решения эти болевые точки. Хотя главным героем этой статьи является Gitlab CI/CD, с точки зрения идей он похож на CI/CD других платформ для размещения кода. А с такими инструментами, как Pipeline, мы можем делать больше таких вещей, какНепрерывная интеграция + автоматическое тестирование. Это проверит воображение каждого, а остальное предоставьте умным читателям!

Если вы считаете, что эта статья неплохая, пожалуйста, поставьте лайк и подпишитесь (Фронтенд Саймон), искренне благодарим вас за поддержку. Вы также можете общаться со мной напрямую, яTusi, и с нетерпением ждем прогресса вместе с вами!