centos7, ci/cd, devops

Введение в GitLab CI / CD

Thank you for reading this post, don't forget to subscribe!
CI / CD — это сокра­ще­ние Continuous Integration/ Continuous Delivery / Continuous Deployment (т.е. непре­рыв­ной инте­гра­ции / непре­рыв­ной достав­ки / непре­рыв­но­го развертывания).
Про­цесс поз­во­ля­ет коман­дам созда­вать, тести­ро­вать и выпус­кать про­грамм­ное обес­пе­че­ние с боль­шей скоростью.
CI / CD устра­ня­ет руч­ное вза­и­мо­дей­ствие с чело­ве­ком, где это воз­мож­но, авто­ма­ти­зи­руя все, кро­ме окон­ча­тель­но­го руч­но­го раз­вер­ты­ва­ния кода в производство.
Одной из про­блем реа­ли­за­ции этой прак­ти­ки явля­ет­ся инте­гра­ция раз­лич­ных инстру­мен­тов и систем, необ­хо­ди­мых для постро­е­ния пай­плай­на CI / CD.
Напри­мер, вы може­те хра­нить свой код в Bitbucket, тести­ро­вать его в набо­рах авто­ма­ти­че­ских тестов в част­ной инфра­струк­ту­ре и раз­вер­ты­вать при­ло­же­ние в AWS или Microsoft Azure.
Слож­ные при­ло­же­ния, рас­по­ло­жен­ные в несколь­ких систе­мах, спо­соб­ство­ва­ли тому, что не все орга­ни­за­ции внед­ри­ли цель­ный пай­плайн CI / CD.

Сценарий

Допу­стим, у нас есть API-интер­фейс Node.js, кото­рый извле­ка­ет спи­сок книг в базе данных.

Мы можем создать пай­плайн, кото­рый про­тал­ки­ва­ет наш код на три эта­па: сбор­ка, тести­ро­ва­ние и развертывание.

Пай­плайн — это груп­па шагов, кото­рые сгруп­пи­ро­ва­ны по сход­ным характеристикам.

Пай­плайн про­ек­та уста­нав­ли­ва­ет зави­си­мо­сти, запус­ка­ет лин­те­ры и любые скрип­ты, кото­рые рабо­та­ют с кодом.

Пай­плайн непре­рыв­ной инте­гра­ции запус­ка­ет авто­ма­ти­зи­ро­ван­ные тесты и созда­ет рас­пре­де­лен­ную вер­сию кода.

Нако­нец, Deploy Pipeline раз­вер­ты­ва­ет код для назна­чен­но­го облач­но­го про­вай­де­ра и среды.

Шаги, выпол­ня­е­мые тре­мя кон­вей­е­ра­ми, назы­ва­ют­ся заданиями.

Когда вы груп­пи­ру­е­те серию зада­ний по этим харак­те­ри­сти­кам, это назы­ва­ет­ся этапами.

Рабо­чие места явля­ют­ся основ­ным стро­и­тель­ным бло­ком для трубопроводов.

Они могут быть сгруп­пи­ро­ва­ны по эта­пам, а эта­пы могут быть сгруп­пи­ро­ва­ны в конвейеры.

Вот при­мер иерар­хии зада­ний, эта­пов и конвейеров:

В этой иерар­хии все три ком­по­нен­та рас­смат­ри­ва­ют­ся как три раз­ных пайплайна.
Основ­ные мар­ке­ры — сбор­ка, тести­ро­ва­ние и раз­вер­ты­ва­ние — эта­пы, а каж­дый раз­дел в этих раз­де­лах — задания.
Давай­те раз­бе­рем это в фай­ле yaml GitLab CI / CD.

Использование GitLab CI / CD

Что­бы исполь­зо­вать GitLab CI / CD, создай­те файл с име­нем .gitlab-ci.yml в корне про­ек­та в сво­ем репо­зи­то­рии GitLab и добавь­те сле­ду­ю­щий yaml:

[codesyntax lang="php"]

[/codesyntax]

Как я упо­ми­нал ранее, GitLab CI / CD исполь­зу­ет ран­не­ры для выпол­не­ния пайплайнов.

Мы можем опре­де­лить, на какую опе­ра­ци­он­ную систе­му и пред­опре­де­лен­ные биб­лио­те­ки мы хотим, что­бы наш ран­нер осно­вы­вал­ся, исполь­зуя дирек­ти­ву image.

В нашем слу­чае мы будем исполь­зо­вать послед­нюю вер­сию Node.js.

Дирек­ти­ва stages поз­во­ля­ет нам зара­нее опре­де­лить этап для всей конфигурации.

Зада­ния будут выпол­нять­ся в поряд­ке, ука­зан­ном в дирек­ти­ве stages.

Дирек­ти­ва before_script исполь­зу­ет­ся для запус­ка коман­ды перед все­ми заданиями.

Теперь давай­те нач­нем с нашей рабо­ты, посвя­щен­ной эта­пу сборки.

Мы соби­ра­ем­ся назвать эту рабо­ту build-min-code.

В этой джо­бе мы хотим уста­но­вить зави­си­мо­сти и мини­ми­зи­ро­вать код.

Мы можем начать с исполь­зо­ва­ния дирек­ти­вы script.

Дирек­ти­ва script — это скрипт обо­лоч­ки, кото­рый выпол­ня­ет­ся внут­ри раннера.

Затем мы соби­ра­ем­ся назна­чить эту рабо­ту на этап «build». Что­бы назна­чить рабо­ту на этап, исполь­зуй­те дирек­ти­ву stage.

[codesyntax lang="php"]

[/codesyntax]

Теперь у нас есть джо­ба, свя­зан­ная с нашей ста­ди­ей сбор­ки, и мы соби­ра­ем­ся сде­лать это для нашей ста­дии тестирования.
Наша тест джо­ба будет назы­вать­ся run-unit-test, и мы соби­ра­ем­ся исполь­зо­вать скрипт npm в нашем API для запус­ка тесто­во­го теста npm.

[codesyntax lang="php"]

[/codesyntax]

Нако­нец, мы соби­ра­ем­ся доба­вить зада­ние для обра­бот­ки эта­па раз­вер­ты­ва­ния: deploy-production, deploy-staging.
В этом слу­чае у нас будет два раз­ных зада­ния для раз­вер­ты­ва­ния (под­го­тов­ка и производство).
Эти джо­бы будут отра­жать ту же схе­му, что и наши преды­ду­щие, но с неболь­ши­ми изменениями.
В насто­я­щее вре­мя все наши зада­ния авто­ма­ти­че­ски запус­ка­ют­ся при любом нажа­тии или пере­хо­де кода.
Мы не хотим, что­бы это было, когда мы внед­ря­ем наш код в ста­дии staging и production..
Что­бы это­го не слу­чи­лось, мы исполь­зу­ем дирек­ти­ву only.
Эта дирек­ти­ва опре­де­ля­ет име­на веток и тегов, для кото­рых будет выпол­нять­ся задание.
Джо­ба будет выгля­деть сле­ду­ю­щим образом:

[codesyntax lang="php"]

[/codesyntax]

В нашем зада­нии deploy-staging ран­нер выпол­нит его толь­ко в том слу­чае, если про­изо­шли изме­не­ния в вет­ке develop и deploy-production — master ветви.
Ниже при­ве­ден при­мер, на кото­ром пока­зан пере­ход кода в master ветку.
Запус­ка­ют­ся все три эта­па и зада­ния, за исклю­че­ни­ем deploy-staging, посколь­ку пере­да­ча кода осу­ществ­ля­лась в master ветку.
GitLab CI / CD постав­ля­ет­ся с инту­и­тив­но понят­ным интер­фей­сом, кото­рый помо­га­ет пока­зать, какие зада­ния и эта­пы выпол­ня­ют­ся, а так­же какие ошиб­ки воз­ни­ка­ют в про­цес­се сборки.
Ниже при­ве­де­на окон­ча­тель­ная вер­сия фай­ла .gitlab-ci.yaml.

[codesyntax lang="php"]

[/codesyntax]