Как стать автором
Обновить

Комментарии 11

НЛО прилетело и опубликовало эту надпись здесь
> CD-компонент
CI в GitLab, в принципе, неплох, но вот CD… Его там практически нет. Есть интеграция с целым одним (в бесплатной версии) прибитым гвоздями кластером Kubernetes и безграничные возможности Bash-скриптинга. По сравнению с Jenkins это по сути является крайне ограниченным велосипедом без колес и руля.
А что умеет Jenkins, чего не умеет Gitlab CI?

Я разрабатываю сейчас PHP-приложение, собираю небольшую команду,
И вот возникла идея, чтобы деплоить тестовые стэнды на BRANCH.site.com

С докером, правда это никак не связано,
Но мне интересно, как обычно делают тестовые стэнды?
— один для DEV и один для QA?
— фиксированный набор стэндов, чтобы было «достаточно» для всех разработчиков?
— как-то по другому?

И как Jenkins «решает» на какой стэнд накатывать какой BRANCH?

Простите за нубские вопросы, может просто дайте ссылку на то, как это правильно делается
> А что умеет Jenkins, чего не умеет Gitlab CI?
В первую очередь, он умеет логику и скриптинг не только на уровне одного шага. Пайплайны там это не нагромождение изолированных джобов, а фактически один скрипт, в котором могут быть свои переменные, которые будут переданы дальше. Можно написать библиотеку с базовыми шагами на Groovy и подключать ее в разных деплоях, сведя количество копипаста/поддерживаемого кода к минимуму. Можно вызывать другие пайплайны с определенными параметрами, получать результат их выполнения и реагировать не только одним доступным способом (упасть).

Есть ручное подтверждение — деплой стоит на паузе, пока не пройдут какие-то важные ручные тесты. Есть и тонкий контроль доступа (с плагином), можно вообще вынести пайплайны в другой репозиторий, и никто их не сможет поправить.

Да много чего есть, всего и не упомнишь, главное это не бояться плагинов и Groovy, они там сделаны нормально. Скажем так, после Jenkins чтение развесистого .gitlab-ci.yml с элементами CD обычно вызывает саркастический смех.

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

> как обычно делают тестовые стэнды?
Вряд ли скажу какой-то best practice, ибо тут все зависит от принятых в компании процессов. У нас вот dev от qa/staging отделен из соображений безопасности и быстродействия. Но в целом с изоляцией Kubernetes (namespaces, resources) можно делать тестовые стенды в каком угодно количестве в рамках одного и того же кластера, если это вписывается в концепцию безопасности.

> И как Jenkins «решает» на какой стэнд накатывать какой BRANCH?
Multibranch Pipeline (плагин). Скриптинг на Groovy и доступная переменная с названием бранча.

Судя по всему тут разные подходы. С Jenkins сильно глубоко работать не доводилось — довольно простые пайплайны делал.
Для Gitlab, получается, ближе концепция "Fail fast". Что-то не так — человек разбирайся. На Jenkins, похоже, можно ненароком всё переусложнить — скрипт за тебя решит проблему, но правильно ли он её решит? Вдруг это что-то новое, что ненароком уйдёт в прод?
В giltab тоже можно вынести скрипты пайплана в другой репозиторий (я сейчас про платную версию — с бесплатной не работал и не могу полностью ручаться за функционал). И можно использовать якоря для повторяющегося кода и, с недавних пор, наследование.
Ручное подтверждение тоже есть. Джобы могут передавать данные через артифакты и Registry.


Можно прикрутить всякие Helm/jsonnet/… Может он и не предназначен для сложных, ветвистых пайплайнов — я не искал. ИМХО пайплайн должен быть прям и прост: собрать новый код, проверка качества кода, тесты, развертывание на dev environment (если надо), слияние с master, создание контейнера-кандидата-в-релиз, развертывание его, тестирование, развертывание в прод.
Чуть что не так — упасть и требовать новых изменений.

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

Все-таки, Gitlab на текущей стадии развития это CI, хоть и довольно неплохой. Он способен работать в качестве CD в несложной среде, к нему можно прикрутить много чего, если вы готовы мириться с его особым путем развития (большинство нужных нам фич было в состоянии полумертвых тикетов 2+ годичной давности, но так будет не у всех).
Да, он отлично подходит для развертывания в k8s.
По идее и к более сложным вещам можно приспособить. Например, проекты генерируют артефакты и отправляют их в репозиторий.
А отдельно есть проект, который вытягивает готовые артефакты и последовательно развёртывает их, проверяя совместимость.
Но не уверен, что это не будет обходным путём в силу ограниченности gitlab

Я делал бранч-деплой с помощью gitlab и docket (swarm mode). Было три кластера: прод, препрод (приемочное тестирование и воспроизводство продакшен багов) и дев (разработка и бранч-тестирование). Для прода (Master ветка) .site.com для препрода . site-preprod.com, для остальных ..site-dev.com. Плюс возможность для каждого поднять локально, грубо говоря, ..localhost. Отлично всё работало, главное было не забывать гасить ненужные наборы сервисов на дев и локально. Позже планировалось гасить хотя бы в дев по активности, а, главное, сделать "фоновые" сервисы (очень редко когда задача затрагивает больше трёх) расшариваемыми.

%.site.com
%.site-preprod.com
%.< branch>.site-dev.com
%.< branch>.site.localhost


Адаптирован под парсер

Если я правильно понял проблему — тестовые стэнды можно создавать на основе веток, используя предустановленные переменные окружения gitlab'a.
Т.е. у нас есть 2 кластера: прод и непрод, — и на непрод разворачиваются приложения, имена и метки pod, deployment, service у которых содержит название ветки.
Потом это всё сливается в master, из которого развёртывается стабильная непрод версия, а потом и развертывание в прод.
Чтоб не повторять код и скрипты, можно использовать якоря, а с недавних пор и наследовать "ступени" (хотя последнее мне не сильно пока нравится).
Ещё можно использовать helm or jsonnet для более гибкого развёртывания. Плюс можно импортировать gitlab-ci из внешнего проекта.
Но я не уверен, что это доступно в бесплатной версии — с ней работать не пришлось.

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

Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории