Как настроить deploy в Gitlab? Какая версия необходима?

Question

[Алексей Со]

Добрый день.

Хотел бы настроить следующую схему: есть репозиторий на gitlab (работает несколько человек в него с локальных серверов). Есть тестовый сервер для демонстрации заказчику. Есть продакшен сервер.
Хотел бы после merge request отправлять автоматически все на тестовый или продакшен сервера.

Сейчас приходится сливать себе - и заливать на продакшен git pull.
Видел подобное при разработке, но сам не настраивал.

Если я правильно понимаю, то это pipelines?
Есть ли мануал нормальный по настройке?
Буду признателен, если кто-то распишет пошагово, с настройках репозитория на сервере. (какие и как делать external links)? Сейчас работаем с гитом через ssh.

Спасибо.

Answer 1

[Алексей Шарапов]

https://habrahabr.ru/company/softmart/blog/310502/
Может быть это вам поможет.

Answer 2

[Руслан]

Я бы посоветовал завести себе какой-нибудь сервис для Continous Integration, например Jenkins.
Он позволит несколько усложнить задачу (кто бы мог подумать, что усложнить - это что-то хорошее!), например:
* Мониторит git / svn / hg / что угодно на предмет новой версии
* Забирает новую версию
* Прогоняет тесты
* В случае невыполнения тестов отправляет провинившемуся разработчику push / email
* В случае выполнения тестов выполняет деплой, и/или например отправляет артефакт в репозитарий, или образ докера в репозитарий.

Для маленького проекта на 5 файлов, конечно, Jenkins это из пушки по воробьям, и тут наверняка лучше будет rsync (если применимо). Но чем больше проект и чем больше тестов и вариантов сборки, тем полезнее может быть Jenkins.

У нас как только не используется: и собирает докер образы (в случае успешной сборки и тестов - в репозитарий), и собирает java-артефакты (аналогично, собрался - пошёл в maven). Собирает приложения на spring-boot, копирует их на целевой сервер, делает из них сервис и сам его перезапускает.

Да, многое можно возложить на хуки, но:
* хуки выполняются на компьютере разработчика (и зачем мне у себя выполнять 300 тестов при каждом коммите, если рядом специально обученный сервер стоит?). К тому же, бывали ситуации, когда что-то собирается на компьютере разработчика только потому, что у него есть какие-то локальные хаки. И потом приходит новый человек (или он меняет компьютер) и два дня только и делает, что настраивает себе всякое :). С отдельным сборщиком такого не бывает.
* деплой и редеплой может запускать специально обученный PM, а не разработчик. Или вообще кто угодно.
* Есть всякие красивые графики, что успешных тестов выполняется всё больше и больше, например. В любой момент PM может посмотреть, какие изменения были в каждой конкретной сборке.

Видел всякие разные конфигурации, даже такую, когда для сборки проекта покупалась виртуалка на amazon, делала сборку и уничтожалась :) Вопрос лишь в извращённости сознания администратора Jenkins. Ну и, конечно, максимально хорошо он интегрирован с Java. JetBrains TeamCity, Atlassian Bamboo - в общем-то тоже.

Comments

[DevMan]

> хуки выполняются на компьютере разработчика
не обязательно, могут выполняться и на сервере с гитом.
не спора ради (в целом все верно написано), а just fyi.

[Руслан]

DevMan: спасибо :) у меня, наверное, предвзятое к ним отношение - в далёком детстве работал с проектом, в котором на сервере выполнялись хуки и это было странно. То есть я делаю коммит и даже не знаю, пройдёт он или вернётся с ошибкой. Так что теперь я вообще про их существование забыл :D

Сейчас это решается сильно проще, например, у нас так: разработчик коммитит сколько угодно в фичабранч, хоть локально, хоть пушит на сервер, это его дело. Надо это дело проверить - он запускает задачу в Jenkins, которая прогоняет автоматические тесты, собирает docker image, и выкатывает для ручного тестирования на тестовый. Не надо - не запускает.

Система сильно не идеальна, есть куда расти, как вширь (сжирает тонны места, а чистка ненужных образов только вручную, надо бы наверное написать плагин для Jenkins), так и вглубь (Canary deployment например), но по сравнению с моей детской психологической травмой с серверными хуками - небо и земля :)

[DevMan]

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

Answer 3

[Артур]

Как указали выше можно использовать Jenkins. В свое время немного использовали его, но в итоге пришли к встроенному Gitlab CI.

Устанавливать Gitlab CI отдельно не нужно, он идет в комплекте с самим Gitlab. Дополнительно нужно будет установить runner - один или несколько, в зависимости от поставленных целей (например, для простого деплоя может вполне хватить одного SSH-раннера).

В блоге у них есть статьи на эту тему, которые в общих чертах показывают суть процесса:
https://about.gitlab.com/2016/08/26/ci-deployment-...
https://about.gitlab.com/2016/08/05/continuous-int...