Рубрика «gitlab ci» - 2

GitLab Shell Runner. Конкурентный запуск тестируемых сервисов при помощи Docker Compose - 1

Данная статья будет интересна как тестировщикам, так и разработчикам, но рассчитана в большей степени на автоматизаторов, которые столкнулись с проблемой настройки GitLab CI/CD для проведения интеграционного тестирования в условиях недостаточности инфраструктурных ресурсов и/или отсутствия платформы оркестрации контейнеров. Я расскажу, как настроить развертывание тестируемых окружений при помощи docker compose на одном единственном GitLab shell раннере и так, чтобы при развертывании нескольких окружений запускаемые сервисы друг другу не мешали.

Читать полностью »

Данная статья рассчитана на java разработчиков, у которых возникла потребность быстро публиковать свои продукты в репозиториях sonatype и/или maven central с использованием GitLab. В данной статье я расскажу про настройку gitlab-runner, gitlab-ci и maven-plugin для решения данной задачи.

Читать полностью »

Прим. перев.: Оригинальную статью написал Miłosz Smółka — один из основателей небольшой польской компании Three Dots Labs, специализирующейся на «продвинутых backend-решениях». Автор опирается на свой опыт активной эксплуатации GitLab CI и делится накопленными советами для других пользователей этого Open Source-продукта. Прочитав их, мы поняли, насколько нам близки описанные им проблемы, поэтому решили поделиться предлагаемыми решениями с более широкой аудиторией.

Советы по созданию нестандартных рабочих процессов в GitLab CI - 1

На этот раз я затрону более продвинутые темы в GitLab CI. Частой задачей здесь является реализация в пайплайне нестандартных возможностей. Большинство советов специфичны для GitLab, хотя некоторые из них можно применить и к другим системам CI.Читать полностью »

laravel-in-docker

В данной статье я расскажу о своём опыте "заворачивания" Laravel-приложения в Docker-контейнер да так, что бы и локально с ним могли работать frontend и backend разработчики, и запуск его на production был максимально прост. Так же CI будет автоматически запускать статические анализаторы кода, phpunit-тесты, производить сборку образов.

"А в чём, собственно, сложность?" — можешь сказать ты, и будешь отчасти прав. Дело в том, что этой теме посвящено довольно много обсуждений в русскоязычных и англоязычных комьюнити, и почти все изученные треды я бы условно разделил на следующие категории:

  • "Использую докер для локальной разработки. Ставлю laradock и беды не знаю". Круто, но как обстоят дела с автоматизацией и запуском на production?
  • "Собираю один контейнер (монолит) на базе fedora:latest (~230 Mb), ставлю в него все сервисы (nginx, бд, кэш, etc), запускаю всё супервизором внутри". Тоже отлично, прост в запуске, но как на счёт идеологии "один контейнер — один процесс"? Как обстоят дела с балансировкой и управлением процессами? Как же размер образа?
  • "Вот вам куски конфигов, приправляем выдержками из sh-скриптов, добавим магических env-значений, пользуйтесь". Спасибо, но как же на счёт хотя бы одного живого примера, который я бы мог форкнуть и полноценно поиграться?

Всё, что ты прочитаешь ниже — является субъективным опытом, который не претендует быть истиной в последней инстанции. Если у тебя будут дополнения или указания на неточности — welcome to comments.

Для нетерпеливых — ссылка на репозиторий, склонировав который ты сможешь запустить Laravel-приложение одной командой. Так же не составит труда его запустить на том же rancher, правильно "слинковав" контейнеры, или использовать продуктовый вариант docker-compose.yml как отправную точку.

Читать полностью »

Эта статья — продолжение статьи про организацию процессов Continuous Integration / Continuous Delivery, автоматизирующих сборку, тестирование и доставку приложений применимо к решениям на платформе InterSystems.

Рассмотрим такие темы как:

  • Контейнеры 101
  • Контейнеры на разных этапах цикла разработки ПО
  • Continuous Delivery с контейнерамиЧитать полностью »

В данной статье хотелось бы рассказать про организацию процессов Continuous Integration / Continuous Delivery, автоматизирующих сборку, тестирование и доставку приложений применимо к решениям на платформе InterSystems.

Рассмотрим такие темы как:

Лучшие практики CI-CD с Kubernetes и GitLab (обзор и видео доклада) - 1

7 ноября на конференции HighLoad++ 2017, в секции «DevOps и эксплуатация» прозвучал доклад «Лучшие практики CI/CD с Kubernetes и GitLab». В нём мы делимся практическим опытом решения проблем, возникающих при построении эффективного процесса CI/CD на базе указанных Open Source-решений.

По традиции рады представить видео с докладом (около часа, гораздо информативнее статьи) и основную выжимку в текстовом виде.Читать полностью »

Сборка проектов с GitLab CI: один .gitlab-ci.yml для сотни приложений - 1

В статье решается задача управления описанием сборки для большого количества однотипных приложений. Чтобы в проекте заработал GitLab CI, нужно в репозиторий добавить файл .gitlab-ci.yml. Но что, если в сотне репозиториев это файл с одинаковым содержимым? Даже если разложить его по репозиториям один раз, то как его потом изменять? А что, если одного .gitlab-ci.yml мало для сборки — нужны Dockerfile или Dappfile, разные скрипты и структура YAML-файлов для Helm? Как обновлять их?

С чего начать решение задачи по сборке сотни однотипных приложений? Конечно же, посмотреть, можно ли GitLab CI указать использовать .gitlab-ci.yml из другого репозитория или компоновать .gitlab-ci.yml из файлов в других репозиториях…Читать полностью »

GitLab CI для непрерывной интеграции и доставки в production. Часть 2: преодолевая трудности - 1
Эта статья продолжает первую часть, содержащую подробное описание нашего пайплайна:

image
… и рассказывает о проблемах, с которыми мы столкнулись для его реализации, и их решении.

Итак, я остановился на том, что созданный .gitlab-ci.yml не позволяет реализовать пайплайн в полной мере, поскольку GitLab CI не предоставляет директив для разделения задач по пользователям и для описания зависимостей выполнения задач от статуса выполнения других задач, а также не позволяет разрешить модификацию .gitlab-ci.yml только для отдельных пользователей.Читать полностью »

GitLab CI для непрерывной интеграции и доставки в production. Часть 1: наш пайплайн - 1

Итак, GitLab CI: что можно ещё рассказать о нём? На хабре уже есть статьи про установку, про настройку раннеров, про командное использование, про GitLab Flow. Пожалуй, не хватает описаний того, как используется GitLab CI в реальном проекте, где задействовано несколько команд. А в современном мире разработки ПО это действительно так: ведь есть (как минимум) разработчики, тестировщики, DevOps- и релиз-инженеры. С подобным разделением на команды мы работаем уже несколько лет. В этой статье я расскажу о том, как мы, используя и улучшая возможности GitLab CI, реализовали и применяем в production для коллектива из нескольких команд процессы непрерывной интеграции (CI) и отчасти доставки приложений (CD).Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js