При этом переменные в настройках групп и проекта можно задать как "файл"или "обычную переменную" и поставить галочки "защищено" и "маскировать".
Начнем с простого наследования и будет постепенно усложняться.
С конечным списком уровней приоритетов можно ознакомиться в конце документа.
Бывает нужно оставить отзыв об исходном коде в репозитории в целом, например при приемке кода на поддержку от других разработчиков или подключаясь к новому проекту.
Процессы ревью в Github и аналогах построены вокруг вносимых изменений, а в нашем случае комментарии нужно дать к состоянию всего кода системы на момент комментирования.
Как это сделать средствами самого git: зафиксировать состояние в ветке для ревью, затем в merge request к этой ветке оставить свои замечания.
В общем суть метода уже изложена, ниже лишь немного подробностей.
Недавно на стендапе коллега внес рацпредложение: автоматизировать сборку релизов, взяв за основу готовые уже наработки по взаимодействию с Jira, написанные на Python.
Процесс деплоя у нас следующий: когда накапливается достаточное количество задач, прошедших тестирование из них собирается Релиз-кандидат (RC) в каждом проекте, затронутом задачами, затем задачи тестируются в составе RC. После этого RC заливается на стейджинг сервер, где в близком к боевому окружении все еще раз тестируется и проводится полный регресс. И затем, после необходимых деплойных действий свежий релиз заливается в мастер.
До недавнего времени весь процесс сборки проводился кем-либо из разработчиков вручную. Что отнимало час, два и больше времени и было, мне кажется, не очень интересным занятием. Теперь же, когда уже почти все готово, релиз из 20 задач, затрагивающий 5 проектов, собирается меньше минуты. Остается, конечно еще разрешение конфликтов, запуск пропущенных тестов и прочее, но даже с учетом этого, времени разработчиков и тестировщиков, вынужденных ждать, пока кто-то и первых освободится и создаст RC, экономится немало.
В общем, приступил я к задаче, и она оказалась очень интересной и увлекательной. А что еще надо для удовольствия от работы, как не увлекательных проектов?
Читать полностью »
Наша команда любит эксперименты. Каждый Слёрм — это не статичное повторение предыдущих, а осмысление опыта и переход от хорошего к лучшему. Но со Слёрмом SRE мы решили применить абсолютно новый формат — дать участникам условия, максимально приближённые к «боевым».
Если кратко обрисовать, чем мы занимались на интенсиве: «Строим, ломаем, чиним,
изучаем». SRE мало чего стоит в голой теории — только практика, реальные решения, реальные проблемы.
Участники были поделены на команды, чтобы бодрый соревновательный дух не дал никому заснуть или запустить «Angry Birds» на iPhone по примеру Дмитрия Анатольевича.
Проблемы, глюки, баги и задачи обеспечивали участникам четыре ментора. Иван Круглов, Principal Developer в Booking.com (Нидерланды). Бен Тайлер, Principal Developer в Booking.com (США). Эдуард Медведев, CTO в Tungsten Labs (Германия). Евгений Варавва, разработчик широкого профиля в Google (Сан-Франциско).
Да ещё и участники поделены на команды — и соревнуются друг с другом. Интересно?
Иван, Бен, Эдуард и Евгений с добрым ленинским прищуром смотрят на бедных участников Слёрм SRE перед началом соревнования.
В продолжение предыдущей статьи про инструменты деплоя в Kubernetes, хочу рассказать вам про то как можно использовать Jsonnet для упрощения описания джоб в вашем .gitlab-ci.yml
Есть монорепа, в которой:
Настроить пайплайн:
GIT_SUBMODULE_STRATEGY=normalКак видите, описать это всё может показаться настоящим адом, но мы не отчаиваемся и вооружившись Jsonnet сделаем это легко и непринуждённо.
Привет! За последнее время вышло много классных инструментов автоматизации как для сборки Docker-образов так и для деплоя в Kubernetes. В связи с этим решил поиграться с гитлабом, как следует изучить его возможности и, конечно же, настроить пайплайн.
Вдохновлением для этой работы стал сайт kubernetes.io, который генерируется из исходных кодов автоматически, а на каждый присланный пул реквест робот автоматически генерирует preview-версию сайта с вашими изменениеми и предоставляет ссылку для просмотра.
Я постарался выстроить подобный процесс с нуля, но целиком построенный на Gitlab CI и свободных инструментах, которые я привык использовать для деплоя приложений в Kubernetes. Сегодня я, наконец, расскажу вам о них подробнее.
В статье будут рассмотрены такие инструменты как:
Hugo, QBEC, Kaniko, Git-crypt и GitLab CI с созданием динамических окружений.
Для начала позвольте представиться. Я — @tristan.read, фронтэнд-инженер в группе Monitor::Health GitLab'а. На прошлой неделе мне выпала честь побыть стажером у одного из наших дежурных SRE-инженеров. Целью было ежедневное наблюдение за тем, как дежурный реагирует на инциденты, и получение реального опыта работы. Нам бы хотелось, чтобы наши инженеры лучше понимали потребности пользователей функций Monitor::Health.
Мне предстояло неделю всюду следовать за SRE-инженер. То есть я присутствовал на передаче дежурства, наблюдал за теми же каналами оповещений и реагировал на инциденты, если и когда таковые имели место.
Эта статья является продолжением цикла публикаций об использовании PVS-Studio в облачных системах. На этот раз мы рассмотрим работу анализатора совместно с GitLab CI — продуктом от GitLab Inc. Интеграция статического анализатора в CI систему позволяет выявить баги сразу после этапа сборки проекта и является очень эффективным способом сократить затраты на обнаружение ошибок.
Читать полностью »
2 недели назад в публичном трекере компании GitLab, стоящей за популярным одноимённым Open Source-решением для разработчиков и DevOps-инженеров, появился issue под названием «WIP: блокировка инженерных должностей по стране проживания». Сегодня о нём стало известно широкой общественности, и это событие вызвало огромный резонанс в англоязычном интернете. Достаточно сказать, что на одной только странице оригинала злополучного issue уже оставлено более 100 комментариев, и их число увеличивается буквально с каждой минутой…
Итак, публикуем перевод виновника бурных обсуждений:Читать полностью »
В GitLab 12.4 появилось несколько улучшений в сфере управления, включая Audit API, утверждение от владельца кода для защищенных веток и контроль доступа для Pages. Зависимости мердж-реквестов помогают управлять работой в командах, а другие замечательные фичи позволяют работать эффективнее и быстрее поставлять ПО лучшего качества.
GitLab улучшает прозрачность, совместную работу и продуктивность. Когда разработчики вместе работают над большим проектом, небольшие изменения часто нужно применять в определенной последовательности. Чтобы упросить эту задачу, функция зависимости мердж-реквестов позволяет определять зависимости в мердж-реквестах, чтобы изменения не поступали в хаотичном порядке и можно было видеть все зависимости во время ревью кода. Эта фича была представлена как зависимости мердж-реквестов между проектами в релизе 12.2, но теперь переименована в зависимости мердж-реквестов и поддерживает больше типов зависимостей. Сюда входят зависимости мердж-реквестов как между проектами, так и в одном проекте.
Мы понимаем, как важно всем управлять. Вот несколько улучшений в релизе 12.4, с которыми управление станет проще.