Практика GitLab CI/CD в проектах Node.js

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

Некоторые проблемы с существующими процессами

При поддержке нескольких проектов могут возникнуть некоторые проблемы:

Как эффективно использовать тест-кейсы
Как эффективно использоватьESLint
Можно ли ускорить развертывание в сети?
1. использовалTypeScriptдополнительные расходы в будущем

прецедент

Первый — это тестовый пример, изначально мы разработали его вgit hooksвнутри, выполнениеgit commitПеред проверкой запустите тестовый пример локально.
Это принесет проблему времени.Если это ежедневная разработка, с этой операцией проблем нет, но если она онлайнbugИсправлено, время выполнения тестового примера могло занять несколько минут в зависимости от размера проекта.
и ремонтироватьbug, может использоватьcommitпри добавлении-nвозможность пропуститьhooks, в ремонтеbugНет ничего плохого в том, чтобы делать это время от времени, но даже если все используют это в повседневной разработкеcommit -nСпособ пропустить громоздкий процесс тестирования, нет возможности контролировать, ведь эта проверка делается локально, следовать ли этому правилу зависит от самосознания каждого.

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

ESLint

Тогда естьESLint, наша команда основана наairbnbизESLintПравила настраивают набор, который больше соответствует привычкам команды.правило, мы добавим в редактор плагины, которые помогут выделить некоторые ошибки и выполнить некоторые операции автоматического форматирования.
В то же время мы такжеgit hooksСоответствующая обработка добавлена в , также вgit commitПри проверке, если она не соответствует спецификации, ее к представлению не допускают.
Но это та же проблема, что и в тестовом примере:

Установлен ли редакторESLintНевозможно узнать плагин, даже если плагин установлен, невозможно узнать, игнорирует ли человеческая плоть сообщение об ошибке.
git hooksможно обойти

Как развернуть онлайн

Предыдущее развертывание команды было подключено к сети с использованиемshipitРазвернуты периферийные комплекты.
Среда развертывания сильно зависит от локальной, т.к. временную директорию хранилища нужно устанавливать локально, и после многократногоssh XXX "command"способ завершения развертывания + онлайн-операция.
shipitПредоставляется эффективное решение для отката, которое заключается в добавлении записей о нескольких исторических версиях развертывания в путь после развертывания и указании текущего каталога проекта на предыдущую версию во время отката.Но небольшой подвох в том, что сложно выбрать узел, к которому я собираюсь откатиться, и дополнительное место на диске, необходимое для сохранения истории
Но из-за этого,shipitПри развертывании нескольких серверов есть некоторые неудобные места.

Если есть несколько недавно добавленных серверов, вы можетеshipitНесколько адресов целевого сервера передаются в файле конфигурации для пакетного развертывания.
Но предположим, что какой-то небольшой трафик (например, одна из четырех машин) должен выйти в сеть однажды, потому что вышеупомянутыйshipitСтратегия отката, которая приведет к несогласованным отметкам времени исторических версий одной машины и трех других машин (поскольку эти машины не подключены к сети одновременно).
Когда я упоминаю эту метку времени, я упомяну ее отдельно. Генерация этой метки времени основана на локальном времени машины, выполняющей онлайн-операцию. Я встретил коллегу, который локально протестировал код и скорректировал время по времени несколько дней назад. Когда время не изменилось обратно на правильное время, была выполнена операция развертывания. После того, как в коде возникла проблема, было обнаружено, что откат не удался, поскольку временная метка версии, развернутой коллегой, была слишком маленькой.shipitНе удалось найти предыдущую версию (shipitВы можете установить количество сохраненных исторических версий, и самая ранняя метка времени в то время также была больше, чем метка времени текущей проблемы)

То есть, даже если небольшой объем трафика один раз выйдет в интернет, в дальнейшем функция пакетного онлайна использоваться не будет.(не внимательно изучилshipitОфициальная документация, не знаю, будут ли подобные--forceтакие операции, как игнорирование исторических версий)

Исходя из описанной выше ситуации, время, необходимое для перехода нашего развертывания в режим онлайн, становится следующим: (количество машин) ИКС (Сумма затрат времени на клонирование склада, основанная на скорости локальной сети и нескольких операциях ssh.).P.S. В целях обеспечения валидности склада каждое исполнениеshipitРазверните, он удалит предыдущую копию, повторно клонирует

Специально для серверных проектов, иногда срочныхbugРемонт может быть в нерабочее время, а это означает, что сетевая среда, в которой вы находитесь, может быть не очень стабильной в это время.
Однажды ночью я получил сообщение в WeChat от коллеги, в котором он просил меня помочь ему запустить проект, принадлежащий его семье.Wi-FiОн принадлежит определенному доктору.Что-то пошло не так при загрузке зависимостей проекта.
Так же есть онлайн работа с использованием мобильного устройства для открытия точки доступа.Однажды был запущен проект, который не был разделен до и после, я получил смс от China Unicom: "Ваш трафик превысил ХХХ в этом месяце" (контракт пакет в то время еще использовался, 800М трафика в месяц).

TypeScript

Со второй половины прошлого года наша команда занимается продвижениемTypeScript, потому что в больших проектах явно набраныTypeScriptОчевидно, ремонтопригодность будет выше.
Но, как всем известно,TypeScriptкоторый в конечном итоге должен быть скомпилирован вJavaScript(такжеtscкоторый не генерируетJSфайл, запускать напрямую, но это больше используется в локальной разработке, мы все же надеемся, что чем меньше переменных, тем лучше при запуске онлайн-кода).

Поэтому предыдущий онлайн-процесс требует дополнительного шага, компиляцииTS.
и потому чтоshipitявляется локально клонированным и развернутым репозиторием, так что это означает, что мы должны поместить сгенерированныйJSФайл так же ставится на склад, самый интуитивно понятный, из обзора склада выглядит некрасиво (50%TS, 50%JS), что еще больше увеличивает стоимость запуска.

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

как решить эти проблемы

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

Эффективное качество кода ограничения
Быстрое развертывание запущено

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

нужно использоватьGitLab CI/CDочень просто, требуется только дополнительная установка с помощью сервераgitlab-runnerи будем использоватьCI/CDПроект можно зарегистрировать на сервисе.
GitLabВ официальной документации очень подробно описан процесс регистрации установки:

install | runner register | runner group register | repoрегистрGroupНекоторые операции во время проекта

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

На что обратить внимание при установке

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

sudo gitlab-runner install --user=gitlab-runner --working-directory=/home/gitlab-runner

ЭтоLinuxверсию команды установки, для установки требуетсяroot(Администратор), за которыми следуют два параметра:

--userдаCI/CDИмя пользователя для использования при выполнении задания (все последующие процессы основаны на задании)
--working-directoryдаCI/CDПуть к корневому каталогу во время выполненияЛичный опыт наступления на яму - установить каталог на диск с большим пространством, т.к.CI/CDбудет генерировать много файлов, особенно при использованииCI/CDСкомпилируйте файл TS и кэшируйте получившийся файл JS; это приведет кinnodeНедостаточное вызывает некоторые проблемы

--userозначаетCI/CDВыполнение использует этого пользователя для выполнения, поэтому, если вы хотите писать скрипты или тому подобное, рекомендуется писать в состоянии, в котором пользователь вошел в систему, чтобы избежать несанкционированного выполнения.sudo su gitlab-runner

На что обратить внимание при регистрации

Следуя процедурам официального сайта, нашtagОн оставлен пустым и пока не нашел никакого применения. .
а такжеexecutorЭто более важно, потому что мы переходим от ручного развертывания к онлайн или приближаемся, поэтому безопасный способ — делать это шаг за шагом, то есть то, что мы выбираем,shell, самый обычный способ исполнения, а влияние на проект относительно небольшое (пример на официальном сайте естьdocker)

Файл конфигурации .gitlab-ci.yml

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

quick start
configuration

Информация в двух приведенных выше ссылках очень полная и содержит различные настраиваемые параметры.

В общем случае структура конфигурационного файла выглядит следующим образом:

stages:
  - stage1
  - stage2
  - stage3

job 1:
  stage: stage1
  script: echo job1

job 2:
  stage: stage2
  script: echo job2

job 3:
  stage: stage2
  script:
    - echo job3-1
    - echo job3-2

job 4:
  stage: stage3
  script: echo job4

stagesИспользуется для объявления действительного исполняемого файлаstage, выполняемые в том порядке, в котором они объявлены.
те, что нижеjob XXXИмя не имеет значения, имя вGitLab CI/CD PipelineИспользуется при отображении на интерфейсе, важно то, чтоstageатрибут, который используется для указания текущего блокаjobкоторомуstage.
scriptЭто содержимое скрипта, который нужно выполнить.Если вы хотите выполнить многострочную команду, напримерjob 3Такая манера письма хороша.

Если положить вышеуказанноеstage,jobНапример, некоторые операции в нашем проектеinstall_dependencies,test,eslintд., а затемscriptЗамените значение в поле чем-то вродеnpx eslintИ так далее, когда вы отправляете этот файл на удаленный сервер, ваш проект уже начал автоматически запускать эти скрипты.
и можно найти вPipelinesИнтерфейс видит статус каждого выполненного шага.

P.S. По умолчанию предыдущаяstageНе будет выполнять следующий, если он не завершенstage, но его также можно изменить дополнительной настройкой:
allow failure
when

Настройте запуск CI/CD только в определенных ситуациях.

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

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

использоватьonlyМожет использоваться для установки условий, которые будут срабатывать.CI/CD, как правило, здесь мы используем указание ветки, это должно быть записано в конкретномjobвыше, что является примерно такой же операцией:

документация по конкретной конфигурации

job 1:
  stage: stage1
  script: echo job1
  only:
    - master
    - dev

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

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

.access_branch_template: &access_branch
  only:
    - master
    - dev

job 1:
  <<: *access_branch
  stage: stage1
  script: echo job1

job 2:
  <<: *access_branch
  stage: stage2
  script: echo job2

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

Кэшировать необходимые файлы

Потому что по умолчаниюCI/CDНа каждом этапе (job) очистит текущий рабочий каталог, чтобы убедиться, что рабочий каталог чист и не содержит данных и файлов, оставленных предыдущими задачами.
Но это в нашемNode.jsВозникла проблема в проекте.
потому что нашESLint, модульные тесты основаны наnode_modulesВыполняются различные зависимости ниже.
И текущая ситуация эквивалентна тому, что нам нужно выполнить каждый шагnpm install, что, очевидно, является ненужной тратой.

Поэтому я упомянул параметры в другом файле конфигурации:cache

Используется для указания того, что определенные файлы и папки должны быть кэшированы и не могут быть очищены:

cache:
  key: ${CI_BUILD_REF_NAME}
  paths:
    - node_modules/

Примерно такая операция,CI_BUILD_REF_NAMEЯвляетсяCI/CDПредоставленная переменная среды, содержимое которой является выполнениемCI/CDТаким образом, кэши между двумя ветвями не влияют друг на друга.

Развернуть проект

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

Для развертывания мы в настоящее время выбираем пройтиrsyncДля синхронизации данных на нескольких серверах достаточно простой и эффективный метод развертывания.

P.S. Для развертывания требуется еще одна вещь: сборка изgitlab runnerмашинаgitlab-runnerДоверительные отношения компьютера между пользователем и целевым сервером развертывания соответствуют пользователю.
Есть N много способов добиться этого, самый простой —runnerвыполнить на машинеssh-copy-idЗапишите открытый ключ на целевую машину.
Или, как я, заранееrunnerОткрытый ключ машины извлекается, и эта строка записывается в файл конфигурации целевой машины, когда необходимо установить доверительные отношения с машиной.
Что-то вроде этого:ssh 10.0.0.1 "echo \"XXX\" >> ~/.ssh/authorized_keys"

Общая конфигурация выглядит следующим образом:

variables:
  DEPLOY_TO: /home/XXX/repo # 要部署的目标服务器项目路径
deploy:
  stage: deploy
  script:
    - rsync -e "ssh -o StrictHostKeyChecking=no" -arc --exclude-from="./exclude.list" --delete . 10.0.0.1:$DEPLOY_TO
    - ssh 10.0.0.1 "cd $DEPLOY_TO; npm i --only=production"
    - ssh 10.0.0.1 "pm2 start $DEPLOY_TO/pm2/$CI_ENVIRONMENT_NAME.json;"

Также используетсяvariables, используемый для предложения некоторых переменных, используемых ниже.

ssh 10.0.0.1 "pm2 start $DEPLOY_TO/pm2/$CI_ENVIRONMENT_NAME.json;", целью этой строки скрипта является перезапуск службы, мы используемpm2Чтобы управлять процессом, в пути к проекту соглашения по умолчаниюpm2В папке хранятся параметры, необходимые для запуска каждой среды.

Конечно, то, что мы сейчас используем, не так просто, и об этом будет сказано ниже.

И на этом этапе развертывания у нас будет дополнительная обработка

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

deploy:
  stage: deploy
  script: XXX
  when: manual  # 设置该任务只能通过手动触发的方式运行

Конечно, если вам это не нужно, это удаление подойдет.Например, мы не настраивали эту опцию в тестовой среде, а использовали эту операцию только в онлайн-среде.

Более простое управление процессами CI/CD

Если вы пишете в соответствии с приведенным выше файлом конфигурации, на самом деле уже есть пригодный для использования файл, содержащий полный процесс.CI/CDВыполнено.

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

Поэтому мы выбрали более гибкий подход, и в конечном итоге нашаCI/CDФайл конфигурации примерно такой (некоторые нерелевантные конфигурации опущены):

variables:
  SCRIPTS_STORAGE: /home/gitlab-runner/runner-scripts
  DEPLOY_TO: /home/XXX/repo # 要部署的目标服务器项目路径

stages:
  - install
  - test
  - build
  - deploy_development
  - deploy_production

install_dependencies:
  stage: install
  script: bash $SCRIPTS_STORAGE/install.sh

unit_test:
  stage: test
  script: bash $SCRIPTS_STORAGE/test.sh

eslint:
  stage: test
  script: bash $SCRIPTS_STORAGE/eslint.sh

# 编译 TS 文件
build:
  stage: build
  script: bash $SCRIPTS_STORAGE/build.sh

deploy_development:
  stage: deploy_development
  script: bash $SCRIPTS_STORAGE/deploy.sh 10.0.0.1
  only: dev     # 单独指定生效分支

deploy_production:
  stage: deploy_production
  script: bash $SCRIPTS_STORAGE/deploy.sh 10.0.0.2
  only: master  # 单独指定生效分支

Мы сделаем каждый шагCI/CDСкрипты, которые необходимо выполнить, помещаются вrunnerНа этом сервере в файле конфигурации выполнялся только этот файл сценария.
Таким образом, когда у нас есть какие-либо корректировки политики, такие как изменения правил ESLint, методов развертывания и т. д.
Они полностью отделены от проектов, и последующие операции в основном не позволят повторно модифицировать проекты, использующие CI/CD, до того, как их можно будет поддерживать (некоторые проекты, требующие импорта новых переменных среды, действительно требуют поддержки проекта).

Доступ к уведомлениям DingTalk

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

Поскольку мы инкапсулировали операции каждого шага выше, эта модификация незаметна для коллег.Нам нужно только изменить соответствующий файл сценария и добавить соответствующие операции DingTalk для его завершения, а также инкапсулировать простую функцию:

function sendDingText() {
  local text="$1"

  curl -X POST "$DINGTALK_HOOKS_URL" \
  -H 'Content-Type: application/json' \
  -d '{
    "msgtype": "text",
    "text": {
        "content": "'"$text"'"
    }
  }'
}

# 具体发送时传入的参数
sendDingText "proj: $CI_PROJECT_NAME[$CI_JOB_NAME]\nenv: $CI_ENVIRONMENT_NAME\ndeploy success\n$CI_PIPELINE_URL\ncreated by: $GITLAB_USER_NAME\nmessage: $CI_COMMIT_MESSAGE"

# 某些 case 失败的情况下 是否需要更多的信息就看自己自定义咯
sendDingText "error: $CI_PROJECT_NAME[$CI_JOB_NAME]\nenv: $CI_ENVIRONMENT_NAME"

Переменные среды, использованные выше, за исключениемDINGTALK_HOOKS_URLнаш собственный адрес уведомления робота, другие переменныеGitLab runenrПри условии.

Здесь можно найти различные переменные:predefined variables

обработка отката

После разговора о нормальном процессе пришло время упомянуть об операции, когда возникает проблема.
Люди не святые и мудрецы ничего не могут сделать.Вполне вероятно, что какие-то вещи, которые не учитываются при выходе в интернет, приведут к нештатным сервисам.На данный момент первоочередная задача-разрешить пользователям доступ в обычном режиме,поэтому мы выберите откат к предыдущей действующей версии.
в проектеPipelineстраница илиEnviromentстраницы (для этого требуется некотороеjobВручную добавьте этот атрибут вdeploy), вы можете выбрать узел, который вы хотите откатить на странице, а затем повторно выполнитьCI/CDзадача завершить откат.

Но этоTypeScriptВ проекте будут какие-то проблемы, потому что откатываемся вообще, чтобы заново выполнить предыдущую версиюCI/CDсерединаdeployзадача, в проекте ТС, мы находимся вrunnerПосле преобразования TS JS кэшируется вdistПапка, и эта папка напрямую передается на сервер во время развертывания (исходный код проекта TS не передается на сервер).

И если мы нажмем напрямуюretryпроблема возникает из-за того, что нашаdistПапки кэшируются, аdeployЕму все равно на такие вещи, он просто отправляет соответствующие файлы для отправки на сервер и перезапускает службу.

и на самом делеdistЭто все же последний (то есть ошибочный) скомпилированный JS файл, поэтому есть два пути решения этой проблемы:

существуетdeployсделай это раньшеbuild
существуетdeployсудить, когда

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

Нам нужно сообщить скрипту, когда он выполняется,distСодержимое папки не то, что вы хотите.
Таким образом, должен бытьлоготип, а самый простой и эффективный способ сделать этот логотип у вас под рукой,git commit id.
Каждыйcommitбудет иметь уникальный идентификатор, и нашCI/CDВыполнение также зависит от отправки нового кода (это означает, что должно бытьcommit).
по этому мыbuildссылка будет актуальнойcommit idТакже кешируется:

git rev-parse --short HEAD > git_version

в то же времяdeployДобавьте в сценарий дополнительную логику оценки:

currentVersion=`git rev-parse --short HEAD`
tagVersion=`touch git_version; cat git_version`

if [ "$currentVersion" = "$tagVersion" ]
then
    echo "git version match"
else
    echo "git version not match, rebuild dist"
    bash ~/runner-scripts/build.sh  # 额外的执行 build 脚本
fi

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

почему бы и нетbuildЭтот шаг аналогиченdeployПричина слияния такова:
Потому что у нас будет много машин одновременноjobНапишу много лайковdeploy_1,deploy_2,deploy_all, если мы будемbuildпоместите этот шаг вdeployсередина
Это означает, что каждый раз, когда мыdeploy, даже если он будет развернут один раз, потому что мы выбираем одну машину для работы в одиночку, она будет регенерироваться много раз, что также потребует дополнительных временных затрат.

Обработка горячих исправлений

существуетCI/CDПоработав некоторое время, мы обнаружили, что время от времениbugЭто все равно будет медленнее, потому что мы должны дождаться полного кода после отправки кода.CI/CDПроцесс окончен.
Поэтому после исследований мы решили, что для некоторых конкретных случаевhot fix, нам нужно пропуститьESLint, юнит-тестируйте эти процессы, быстро исправляйте код и завершайте запуск.

CI/CDпредусмотрено для некоторыхTagВы можете делать разные вещи, но я не хочу этого делать по двум причинам:

Это требует изменения файлов конфигурации (все проекты)
Это требует, чтобы разработчики были знакомы с соответствующими правилами (нажмитеTag)

Поэтому мы использовали еще один хитрый способ добиться этого, потому что наши ветки принимают толькоMerge Requestтаким образом онлайн, поэтому ихcommit titleна самом деле исправлено:Merge branch 'XXX'.
в то же времяCI/CDТам будут переменные среды, сообщающие нам о текущем выполненииCI/CDизcommit message.
Мы решаем, пропускать ли их, сопоставляя эту строку, чтобы проверить, соблюдается ли определенное правило.job:

function checkHotFix() {
  local count=`echo $CI_COMMIT_TITLE | grep -E "^Merge branch '(hot)?fix/\w+" | wc -l`

  if [ $count -eq 0 ]
  then
    return 0
  else
    return 1
  fi
}

# 使用方法

checkHotFix

if [ $? -eq 0 ]
then
  echo "start eslint"
  npx eslint --ext .js,.ts .
else
  # 跳过该步骤
  echo "match hotfix, ignore eslint"
fi

Это гарантирует, что если наша ветвь названаhotfix/XXXилиfix/XXXПри слиянии кодаCI/CDОн пропустит избыточные проверки кода и перейдет непосредственно к развертыванию.Шаг установки зависимостей не пропущен, т.к. компиляция TS по-прежнему требует этих инструментов

резюме

В настоящее время команда имеет более половины доступа к проектуCI/CDпроцесс, чтобы облегчить доступ коллег (в основном редактирование.gitlab-ci.ymlфайлы), мы также предоставляем каркас для быстрой генерации файлов конфигурации (включая автоматическое установление доверительных отношений между машинами).

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

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

В конечном итоге можно сказать, что если нетCI/CD, на самом деле, режим разработки тоже терпим, но при использованииCI/CDВ дальнейшем, если вы воспользуетесь предыдущим методом развертывания, вы явно будете чувствовать себя некомфортно. (Без сравнения, без вреда 😂)

полное описание процесса

Установить зависимости
проверка качества кода
1. ESLintэкзамен
  1. Проверить, еслиhotfixветвь, если да, пропустите этот процесс
2. модульный тест
  1. Проверить, еслиhotfixветвь, если да, пропустите этот процесс
Скомпилируйте файл TS
Развернуть, запустить
1. Определить текущий кешdistЯвляется ли каталог допустимой папкой, если нет, повторите третий шаг, чтобы скомпилировать файл TS.
2. Отправить уведомление DingTalk после выхода в сеть

что делать дальше

доступCI/CDЭто только первый шаг.После объединения развертывания и онлайн-процесса может быть удобнее заниматься некоторыми другими делами.
Например, после выхода программы в сеть можно проверить валидность интерфейса, при обнаружении ошибок версия будет автоматически откатлена и развернута заново.
или доступdocker, эти корректировки в определенной степени прозрачны для сопровождающих проекта.