Комментарии 25
Разработчики выкладывают код приложения в ветки с префиксом feature_
А что происходит до этого? Почитать как собрать приложение через CI и потестировать его можно и в других статьях, а тут получается прям по канонам документации гитлаб, где всё начинается с «вот вы запушили код в репозиторий...»
Нельзя ли описать процесс до того как код попадает в репозиторий? Как разработчики разрабатывают софт, я имею ввиду как разворачиается для них среда разработки? То есть как разработчики запускают только что написанный код. Судя по рекомендациям гитлаба — каждое изменение пушится в репозиторий, а уже потом происходит какая-то магия, но это же дико неудобно — каждый раз пушить на удалённый репо, создавать 100500 разных коммитов только для того чтобы потестировать только что написанный код. Я видимо что-то не так делаю, не так понимаю?
В общем запрашиваю часть #0 этого цикла :)
Локальные тесты у себя прогоняете и получаете проверку только что написанного кода, что вы, право.
Юнит-тесты обычно можно запустить на машине разработчика, различные функциональные, интеграционные и дальше — тоже можно, если хватит мощности и есть возможность (помогает всяческая виртуализация).
Деплой в тестовое (да и в боевое) окружение по кнопке хорош тем, что его может выполнять кто угодно, не обязательно компетентный в девопсе в общем и деплое конкретного приложения в частности. Например, дизайнер, менеджер продукта, переводчик.
Разумеется, возможность нажать кнопку для деплоя на бой должно быть не у каждого. Эта возможность регулируется правами доступа к репозиторию. То есть кнопки просто нет у тех, кто ее жать не должен.
А вот чтобы запустить тесты на машине разработчика для начала на этой самой машине нужно запустить то что мы, собственно говоря, собираемся тестировать. Если это, например, сайт — нужно поднять вебсервер (например nginx), поднять интерпретаторы (например php или ruby), собрать бэкенд (например golang) и фронтенд (js/css), потом это всё каким-то образом запустить так чтоб и разработчик мог это потрогать и скрипты тестов могли достучаться. Но это даже не основная проблема — методики отработаны годами, а сейчас с докером так вообще проблем поубавилось, но надо же развернуть максимально похоже на окружение на тесте/препроде/проде, а не просто так «как нибудь».
С докером тоже всё понятно, только вот запуск докера в проде и запуск докера локально могут отличаться значительно, именно за счёт окружения. Например локально вы поднимаете через docker-compose, а на проде через kubernetes и получаете разное сетевое взаимодействие между контейнерами, при этом без возможности протестировать как оно будет на проде. Или по разному передавать креды — на деве через конфиги, а на проде через gitlab втыкать.
Хотелось бы какого-то решения, подсказки, как сделать так чтоб у меня разработчики работали в той же (максимально похожей) среде что будет и у теста/прода, но при этом им не приходилось бы каждое изменение коммитить (это я про вариант с локальным гитлаб-ранером).
Про цикл разработки уже были комментарии от коллег вот в этом треде: 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 — локально работающее приложение как-будто работает в удалённом кластере, но ещё не пробовали.
Спасибо за отличную статью про 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 работает только для автоматических задач и то, только в момент, когда создаётся пайплайн. Если автоматическая задача упадёт, то следующие не запустятся, но даже, если поправить проблему и перезапустить упавшую задачу, то следующие за ней не пойдут в работу. Нам это не слишком мешает, больше мешает, что ручные задачи можно запустить когда угодно. Подробнее про все эти ограничения опять же в следующей части.
Про опциональное выполнение задач скажу так:
- У нас такой потребности не возникает, потому что фронт и бэк в разных репозиториях и вообще можно сказать микросервисность, когда один фронт использует API нескольких бэков.
- В статье упомянуто, что для сборки используем dapp. В вашем сценарии, когда фронт и бэк в одном репозитории, при правильно написанном Dappfile, образ фронта не будет собираться автоматически, если изменения только в исходниках бекенда.
- Как вариант вместо git log можно попробовать файлы-флаги. Скрипт сборки будет проверять, скажем, что в корне репозитория есть .do-not-build-front и не запускать сборку фронта. На следующей стадии можно будет не запускать тесты для фронта. В следующей части будет с примерами, как использовать похожие файлы-флаги.
- Вообще проблема условного выполнения пайплайна нами тоже ощущается, но пока что хватает названий веток/тэгов. Однако этого всё равно мало, очень хочется иметь возможность перезапустить билд с другими параметрами.
В достаточно большом проекте эти трёхэтажные Yaml-ы делегированы как раз devops-инженерам. А в небольшой команде обязательно кто-то будет заниматься непрофильной, но тем не менее важной деятельностью. Если разработчики начали заниматься деплоем и это отнимает их время, то почему бы не отдать devops на аутсорс, благо сейчас много кто этим занимается.
GitLab CI для непрерывной интеграции и доставки в production. Часть 1: наш пайплайн