Comments 25
Статью не дочитал, но насколько я вижу — нет одной очень интересной детали:
Разработчики выкладывают код приложения в ветки с префиксом feature_

А что происходит до этого? Почитать как собрать приложение через CI и потестировать его можно и в других статьях, а тут получается прям по канонам документации гитлаб, где всё начинается с «вот вы запушили код в репозиторий...»
Нельзя ли описать процесс до того как код попадает в репозиторий? Как разработчики разрабатывают софт, я имею ввиду как разворачиается для них среда разработки? То есть как разработчики запускают только что написанный код. Судя по рекомендациям гитлаба — каждое изменение пушится в репозиторий, а уже потом происходит какая-то магия, но это же дико неудобно — каждый раз пушить на удалённый репо, создавать 100500 разных коммитов только для того чтобы потестировать только что написанный код. Я видимо что-то не так делаю, не так понимаю?
В общем запрашиваю часть #0 этого цикла :)

Локальные тесты у себя прогоняете и получаете проверку только что написанного кода, что вы, право.

Чтоб локальные тесты сработали — для начала надо запустить приложение. Как вы, например, планируете тестировать веб-приложение без веб-сервера?

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


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


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

Про деплой в тест или прод я вообще ничего не говорил, там всё более менее понятно — GitLab поможет.
А вот чтобы запустить тесты на машине разработчика для начала на этой самой машине нужно запустить то что мы, собственно говоря, собираемся тестировать. Если это, например, сайт — нужно поднять вебсервер (например nginx), поднять интерпретаторы (например php или ruby), собрать бэкенд (например golang) и фронтенд (js/css), потом это всё каким-то образом запустить так чтоб и разработчик мог это потрогать и скрипты тестов могли достучаться. Но это даже не основная проблема — методики отработаны годами, а сейчас с докером так вообще проблем поубавилось, но надо же развернуть максимально похоже на окружение на тесте/препроде/проде, а не просто так «как нибудь».
Поднимите такое же окружение, как на стейджинге в докере на девелоперской машине, просто подключите папку с исходниками из IDE вместо того, что лежит в образе приложения. Для python+uwsgi удобно включить релоад по изменениям файлов, node тоже так умеет. Go ручками собирать. Никакой магии.
Что-то сегодня народ из крайности в крайность прыгает, видимо зря я тут вопросы в понедельник задаю.

С докером тоже всё понятно, только вот запуск докера в проде и запуск докера локально могут отличаться значительно, именно за счёт окружения. Например локально вы поднимаете через docker-compose, а на проде через kubernetes и получаете разное сетевое взаимодействие между контейнерами, при этом без возможности протестировать как оно будет на проде. Или по разному передавать креды — на деве через конфиги, а на проде через gitlab втыкать.
Хотелось бы какого-то решения, подсказки, как сделать так чтоб у меня разработчики работали в той же (максимально похожей) среде что будет и у теста/прода, но при этом им не приходилось бы каждое изменение коммитить (это я про вариант с локальным гитлаб-ранером).
Да я вот как раз переезжаю со связки compose+docker cloud на что-то типа gitlab+kubernetes :(
Так настраивайте одинаково. У нас отличия прод- от дев-окружения в основном только в значениях переменных в .env файлах, да в docker-compose.override.yml, который маунтит каталоги хоста с исходниками на контейнеры и задаёт доменные имена.
Ну запускать на проде через docker-compose — непозволительная раскошь для меня… Потому и требуются всякие kubernetes, а вот с ними уже сложнее на деве. Впрочем я уже похоже придумал свой велосипед…

У нас и на проде, и локально docker swarm mode. От kubernetes в итоге отказались из-за проблем локального запуска как раз.

В общем хороший вопрос-то, за что минусы? Статья же висит в хабе разработки.

Про цикл разработки уже были комментарии от коллег вот в этом треде: https://habrahabr.ru/company/flant/blog/331188/#comment_10274996

С точки зрения devops-инженера всё живёт именно в gitlab — коммит в infra_*, пуш в git, выкат в своё окружение, проверка.

С точки зрения разработчика push в feature_* происходит, когда фича готова к интеграционному тестированию. То, что можно прогнать локально на среднем железе и быстро — то лучше делать локально, ведь не каждую строчку кода надо тестировать селениумом? В каждом проекте нужно приходить к некоему компромиссу — что запускать локально, какие сервисы локально разворачивать, а что проще пушнуть и потом смотреть логи в gitlab-е.

То есть часть #0 ещё более индивидуальна, чем части #1 и #2. Но тема конечно актуальная, тут сложно спорить, рано или поздно тоже статью напишем.

P.S. Есть ещё один вариант, который снимет вопросы про тесты и развёртывание окружения на локальной машине разработчика — применение web IDE.
Сегодня просто не мой день — куда не напишу везде минусы, не обращайте внимания.
По ссылке ходил, там даже мои комментарии есть про монтирование в миникуб.

По вопросам непосредственно локальной разработки я уже всех достал, пристаю ко всем на конференциях, но толку ноль. Все говорят тоже самое — пили свой велосипед, готовых рецептов нет. Вот я и сижу пилю на том самом minikube + helm и пачке баш-скриптов. Двигаюсь уже в сторону второго этапа — разворачивание всё через гитлаб на тестовом кластере kubernetes в гугле. Медленно но верно. Просто думал что есть какой-то вариант попроще…

Быстрое развёртывание окружений предлагали ребята teatro, упомянутые в описании gitlab flow, но похоже они пропали куда-то. И как вариант, telepresence.io — локально работающее приложение как-будто работает в удалённом кластере, но ещё не пробовали.

Мы взяли docker swarm и небольшую обвязку на bash в основном чтобы иметь на одном кластере несколько версий системы одновременно. То есть для каждой интересующей его ветки системы (монолитный репозиторий) разработчик, тестировщик и т. п., может развернуть локальную копию мало чем отличающуюся от продакшена и иметь их несколько одновременно с dns типа service.branch.project.localhost, а прод соответствует service.master.project.localhost. Основная проблема: если хочется сравнить две ветки одного сервиса в соседних вкладках, то разворачивать локально нужно 2*N контов, где N — количество сервисов, сейчас порядка 20. А различается только один. Думаю над упрощенной версией, где локально разворачивается только нужный сервис, а остальные берутся с дев-кластера, но очень не хочется связывать локальный и удаленный кластера из-за неизбежных рассинхронизаций.
Насколько я знаю — большие компании ( со сложными сайтами) именно так и делают. На деве весит только часть над которой человек работает — останое висит на тестовых серверах. Иначе сервисы просто не помещаются в один комп…

Спасибо за отличную статью про GitLab, ставлю два заслуженных плюса.


У самих GitLab есть Community Writers Program. Вы не думали о том, чтобы и туда написать (конечно, на английском)?

хотелось бы разрешить изменять .gitlab-ci.yml только отдельным пользователям

В гитлабе можно залокать файл на конкретного пользователя, либо из костылей приходит на ум вынос .gitlab-ci.yml в отдельную ветку и выдавания прав на неё

для описания зависимостей выполнения задач от статуса выполнения других задач

https://docs.gitlab.com/ee/ci/yaml/#when
вряд ли будет удобно но если разбить на большее количество стадий, то можно использовать when для зависимости выполнения задач от статуса стадии

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

https://gitlab.com/gitlab-org/gitlab-ce/issues/18667
https://gitlab.com/gitlab-org/gitlab-ce/issues/19232
мне больше понравился вариант с push-option но к сожалению это только проедложения.
Сам я придумал использовать для этого сообщения коммитов, специальной переменной в гитлабе под них нету, поэтому можно только git log -1 --pretty=%B и регуляркой искать что надо, но тут тоже проблема, потому что всё выполняется в контейнерах и гита там нету

Лок файлов похоже доступен только EE пользователям. .gitlab-ci.yml в отдельной ветке создаст пайплайн только для этой ветки. В двух словах: про безопасность gitlab ci есть несколько задач и возможно будет даже какое-то стандартное решение, но пока мы сделали свой патч, про это будет в следующей части.


when не подходит тем, что on_failure/on_success работает только для автоматических задач и то, только в момент, когда создаётся пайплайн. Если автоматическая задача упадёт, то следующие не запустятся, но даже, если поправить проблему и перезапустить упавшую задачу, то следующие за ней не пойдут в работу. Нам это не слишком мешает, больше мешает, что ручные задачи можно запустить когда угодно. Подробнее про все эти ограничения опять же в следующей части.


Про опциональное выполнение задач скажу так:


  1. У нас такой потребности не возникает, потому что фронт и бэк в разных репозиториях и вообще можно сказать микросервисность, когда один фронт использует API нескольких бэков.
  2. В статье упомянуто, что для сборки используем dapp. В вашем сценарии, когда фронт и бэк в одном репозитории, при правильно написанном Dappfile, образ фронта не будет собираться автоматически, если изменения только в исходниках бекенда.
  3. Как вариант вместо git log можно попробовать файлы-флаги. Скрипт сборки будет проверять, скажем, что в корне репозитория есть .do-not-build-front и не запускать сборку фронта. На следующей стадии можно будет не запускать тесты для фронта. В следующей части будет с примерами, как использовать похожие файлы-флаги.
  4. Вообще проблема условного выполнения пайплайна нами тоже ощущается, но пока что хватает названий веток/тэгов. Однако этого всё равно мало, очень хочется иметь возможность перезапустить билд с другими параметрами.
Пайплайн в начале статьи — скриншот из gitlab. Диаграмма про раннеры — скорее всего обычный openoffice draw.
Всего-то разработчикам писать еще один трежэтажный yaml? Фигня вопрос — BaaS, модная же тема — мы CI и CD «делегировали командам разработки» (будто им и так нечего делать).

В достаточно большом проекте эти трёхэтажные Yaml-ы делегированы как раз devops-инженерам. А в небольшой команде обязательно кто-то будет заниматься непрофильной, но тем не менее важной деятельностью. Если разработчики начали заниматься деплоем и это отнимает их время, то почему бы не отдать devops на аутсорс, благо сейчас много кто этим занимается.

Only those users with full accounts are able to leave comments. Log in, please.

Information

Founded
Location
Россия
Website
flant.ru
Employees
51–100 employees
Registered