Невероятно мощный инструмент, который сэкономит ваше время и избавит от головной боли при настройке!
Узнайте все, что подробно описано в этом сообщении, и многое другое в моем полном курсе «Освоение конвейеров Bitbucket для CI и CD», доступном на Skillshare и Udemy:
Вы всегда входите на свой сервер по SSH и боретесь со своими сборками и развертываниями?
Вы попали в правильный пост. Этот пост будет посвящен Bitbucket Pipelines.
Полное раскрытие информации: мне не платили и не спонсировали иным образом Atlassian, чтобы написать это, я просто давно пользуюсь Bitbucket и также считаю их инструмент CI / CD, Pipelines, невероятно мощным и полезным!
У меня также есть курс по Skillshare и Udemy, который шаг за шагом углубляется во все темы в этом посте и многое другое!
В качестве полностью бесплатной альтернативы (Bitbucket Pipelines предоставляется бесплатно только в течение определенного количества минут сборки в месяц) вы можете воспользоваться GitHub Actions для инструмента CI и CD, ориентированного на проекты с открытым исходным кодом. Хотя в этом посте будут использоваться синтаксис и соглашения для Bitbucket Pipelines, многие концепции могут быть перенесены в мир GitHub Actions.
Bitbucket Pipelines?
Так что же такое Bitbucket Pipelines? Bitbucket Pipelines - это еще один инструмент CI / CD, такой же, как CircleCI или Travis CI: это среда, в которой вы можете настраивать и выполнять определенные операции в своих репозиториях каждый раз, когда вы отправляете код в источник. Мы можем запускать тесты, сборки и даже SSH на наших производственных серверах, перемещать код или перезапускать процессы, при этом мы подключены к перехватчикам обмена сообщениями, чтобы оставаться в курсе, в то время как Pipelines делает всю работу за вас!
Если вы искали более настраиваемый инструмент для сборки и развертывания помимо автоматизированных инструментов, таких как Heroku и Netlify, Bitbucket Pipelines для вас! (Например, при развертывании с этим блогом я использую gzip файлов, чтобы сделать его еще быстрее! 🔥 Хотя здесь я использую GitHub Actions.)
Достаточно домашнего хозяйства; давайте начнем с этого руководства.
Файл конвейеров Bitbucket «Hello World»
Для начала создадим «Hello World» версию файла конфигурации Bitbucket pipelines. Все файлы конфигурации Bitbucket Pipelines должны иметь имя bitbucket-pipelines.yml и располагаться в корне вашего репозитория.
Затем мы запускаем YAML-файл с директивами pipelines: и branches: и называем нашу ветку. Это будет ветвь, которая при нажатии запускает последующие шаги в нашем файле Pipelines.
Обратите внимание, что вы можете указать несколько веток! Это мощная функция конвейеров, как мы увидим, для нескольких сред, например, когда у вас есть как тестовый, так и производственный сайт. На данный момент я буду использовать имя ветки git по умолчанию master для нашего конвейера hello world. Объединяя все упомянутые директивы, наш файл конвейеров Hello World выглядит так:
Итак, после наименования ветки master я создал так называемый step. Эти шаги кажутся разделенными и помечены name в пользовательском интерфейсе конвейеров. Для каждого шага мы также можем видеть результат того, что было сделано на данном шаге, что позволяет легко отслеживать любую сборку или интеграцию позже:
У нас также всегда есть bash, доступный для нас в среде конвейеров, поэтому я мог сразу же запустить эту команду echo без необходимости импортировать какие-либо библиотеки или что-либо в нашем конвейере.
Проверка и проверка файлов конвейера
Bitbucket также предоставляет инструмент для проверки вашего YAML-файла конвейера. Проверьте это, скопируйте и вставьте указанный выше файл YAML, чтобы проверить!
В качестве примера неправильно отформатированного файла YAML попробуйте скопировать и вставить его в:
Ха ... этот файл выглядит практически так же, как и другой, верно ?! Вы видели ошибку, выделенную валидатором? Да, в нашей директиве script: неверный отступ:
В 99% случаев ваши проблемы с файлами YAML будут связаны с форматированием и отступами. Я рекомендую использовать хороший редактор и, возможно, библиотеку YAML, чтобы избежать этих проблем с отступами, и часто вызывать функцию «форматирования» в вашем редакторе для форматирования отступа YAML.
Хватит новичков! Давайте создадим файл конвейеров для настоящей сборки!
Хорошо, запускать команду bash в наших конвейерах - это здорово и все такое, но давайте сделаем настоящую сборку.
Предположим, мы запускаем приложение React с использованием TypeScript, где нам нужно выполнить некоторые «настоящие» команды. Такой конвейер может выглядеть так:
Где наш скрипт узла build будет не чем иным, как вызовом tsc, определенного в package.json следующим образом:
...
"scripts": {
"build": "tsc"
}
...
Сохранение артефактов в папке Dist и модулях NPM
Итак, мы настроили несколько настоящих команд сборки, и теперь нам нужно что-то сделать с тем, что было построено! Это требует использования так называемых артефактов. Артефакты - это файлы или папки, созданные на шаге, и они сообщают Bitbucket, что эти файлы или папки следует использовать на более поздних этапах, например, для отправки этих файлов или папок на ваш сервер!
Обычный шаблон для TypeScript - поместить все артефакты сборки в папку dist/ (через outDir config setting), поэтому предположим, что у нас есть такие настройки. Мы будем использовать директиву artifacts сразу после директивы script в нашей конфигурации конвейеров, чтобы сообщить Bitbucket, что мы хотим сохранить как папки dist/, так и node_modules/.
Предположим также, что мы создали простой статический сервер с помощью Express и поместили его в index.js файл. Этот файл не будет создан во время процесса, это будет обычный файл, зарегистрированный в нашем репозитории - файлы, которые уже существуют в вашем репозитории, также можно объявить как артефакты! 😄
В следующем разделе мы увидим, что эти папки будут доступны нам в следующих этапах конвейера, чтобы мы могли использовать их по своему усмотрению.
SCP для копирования артефактов на выбранный вами сервер
Итак, у нас есть процесс установки и сборки, и у нас есть артефакты от обоих процессов. Чтобы продолжить этот пример, предположим, что мы хотим что-то сделать с этими артефактами - в этом случае мы отправим их на выбранный сервер с помощью SCP:
Обратите внимание, что для этого требуются дополнительные действия за пределами файла pipelines.yml! Вам нужно будет добавить переменные USER и SERVER (указанные выше как $USER и _22 _ ) как переменные конвейера! Здесь вы можете увидеть подробные инструкции по настройке переменных конвейера.
SSH для входа на выбранный вами сервер
Теперь, когда наши артефакты находятся в папке var/www/your-first-pipeline-site на сервере, мы войдем на сервер по SSH и запустим index.js с node index.js.
К счастью, мы можем использовать те же самые переменные $USER и $SERVER из последнего раздела нашей команды SSH:
Обратите внимание, что этот тип конвейера также потребует дополнительных шагов: вам нужно будет настроить свой сервер для приема SSH-подключений из вашего репозитория! «Вы можете увидеть, как подробно настроить SSH-ключи для вашего репозитория. здесь."
Ура! Теперь у нас есть полнофункциональная CI: мы устанавливаем, строим, сохраняем и развертываем наши артефакты на сервере и даже запускаем сам сервер. Потрясающий! 🚀
Здесь все еще есть небольшая проблема с запуском node index.js на сервере в нашем конвейере, но вам нужно пройти полный курс, чтобы узнать об этом!
Бонус: многоотраслевая и многопользовательская система
Давайте посмотрим на файл Pipelines, который поддерживает несколько сред. Как я упоминал ранее, возможно, у вас есть тестовый сайт и рабочий сайт, которые соответствуют ветвям staging и master соответственно. Такой файл конфигурации конвейеров может выглядеть так:
Вы заметите, что здесь я запускаю команду cp, которая копирует соответствующее окружение для данной ветки (впоследствии сборка будет использовать только значения из .env.json во время следующих шагов). Обычно у меня есть следующая папка и файлы для установки среды:
env ├── .env.develop.json ├── .env.json ├── .env.production.json └── .env.staging.json
В качестве альтернативы вы можете создать серию файлов TypeScript, каждый из которых содержит класс с public static readonly переменными в нем - хотя это, очевидно, гораздо больше зависит от того, действительно ли вы находитесь в проекте, использующем TypeScript. 😄
Обратите внимание, что любой из этих файлов env или config должен быть зарегистрирован в git, поэтому они действительны только для общедоступных переменных - возможно, заголовков, стилей и т. Д. Для секретных переменных вам все равно нужно будет использовать другие инструменты, такие как dotenv или переменные среды bash (например, process.env в Node.js).
Бонус: добавьте Slack Bot и веб-перехватчик сообщений
Интересно включить в Bitbucket Pipelines Slack-бот с веб-перехватчиком, с помощью которого вы можете отправлять сообщения на различных этапах процесса сборки или интеграции, а также в моменты, когда что-то идет не так.
Самый простой (хотя, возможно, не самый чистый) способ сделать это - добавить команду curl прямо в ваш файл Pipelines, которая вызывает URL-адрес веб-перехватчика Slack с нужным сообщением:
Plug Time: узнайте все это и многое другое на моем курсе Bitbucket Pipelines Mastery!
Мой курс Освоение конвейеров Bitbucket для CI и CD доступен на Skillshare Premium и за 20 долларов на Udemy:
Если вы хотите пройти предварительный просмотр первых нескольких уроков курса, то это на YouTube:
Мои курсы всегда включают в себя полный репозиторий кода, пошаговые видеоролики, пошаговые инструкции, конфигурации, живое тестирование, примеры и многое другое!
Спасибо!
Как всегда, спасибо за чтение, и я надеюсь, что вы кое-что узнали о Bitbucket Pipelines!
-Ваше здоровье! 🍺
Крис
