Всем привет! Сегодня я расскажу как реализовать автоматическую публикацию npm пакета в cicd gitlab, с помощью каких инструментов мы генерируем CHANGELOG файл и обновляем версию package.json. А так же как публикуем изменения в gitlab репозитории.
Я постараюсь дать вам простую инструкцию, расскажу с какими сложностями мы столкнулись и как их решили.
Это продолжение предыдущего туториала про командную разработку с использованием GitLab. Фокус предыдущей статьи был на организации непрерывной поставки в работе команды. В этой статье мы уделим основное внимание именно практическим действиям необходимым для развёртывания из GitLab в Kubernetes.
А именно мы возьмём максимально простое но достаточно содержательное приложение на React.js, докеризуем его, затем развернём в Kubernetes локально при помощи Docker Desktop. После этого развернём его уже на Google Cloud Platform (GCP), и завершим разработкой CI/CD конвейера в GitLab для публикации нашего приложения в Google Kubernetes Engine.
Желательны но необязательны базовые знания
В дальнейшем мы сделаем следующее.
В этой небольшой статье поговорим о том, что такое лог изменений проекта, зачем он нужен и как можно автоматизировать его генерацию с помощью GitLab.
Лог изменений проекта (changelog) - это документ, в котором обычно содержится упорядоченный список версий проекта с датами их выхода, а также перечень всех изменений для каждой из версий.
Исторически мы использовали GitLab 8, который работал на хосте Mac на VirtualBox. Потом конфигурация перестала устраивать, поэтому в локальной сети завели отдельную полноценную Ubuntu-машину. Заодно и GitLab обновили до версии 11.2.1-ee.
Ставили все по официальному Читать полностью »
Возьмём приложение «Проверка чека» и разберемся что оно делает и зачем ваще кому-то понадобилось проверять чеки с помощью приложения.
Я не помню как это работало раньше, но с 2016-2017 годов, благодаря 54-ФЗ «О применении ККТ» появились некие Читать полностью »
Если в качестве инфраструктуры, где разворачивается приложение, выступает Kubernetes, можно сказать, что существует два способа запуска тестов (и других утилит для анализа кода) в CI/CD:
Первый подход мы достаточно подробно описывали на интересном примере с базами данных в статье «Как мы выносили СУБД (и не только) из review-окружений в статическое». В этой статье рассмотрен более простой путь — запуск вне K8s-кластера. Делать мы это будем на примере SonarQube-тестов в рамках CI/CD, построенного на базе GitLab с использованием werf.Читать полностью »
В этом году мы поставили себе амбициозные цели по улучшению продукта.
Некоторые задачи требуют серьезной подготовки, по ним мы собираем обратную связь от пользователей: приглашаем в офис разработчиков, сисадминов, руководителей команд, специалистов по Kubernetes.
В некоторых — выдаем серверы в ответ за фидбек, как например было со студентами Blurred Education. У нас очень насыщенные чаты с обсуждением UI/UX, беклог обучающих статей в справочник и большие планы по улучшению пользовательского опыта.
Большинство изменений требуют большое количество часов разработчиков, но маркетплейс — совсем другая история. С появлением снапшотов у нас появилась возможность привлекать внешних системных администраторов, которые могут подготовить образ, чтобы мы буквально за день включили его в маркетплейс.
Как внести свой вклад в маркетплейс RUVDS и что за это будет, мы покажем на примере нашего нового образа, подготовленного нашим клиентом takezi — GitLab
В последнее десятилетие достигнуты значительные успехи в сфере разработки инструментов непрерывной интеграции (Continuous Integration, CI) и непрерывного развёртывания (Continuous Delivery, CD). Развитие технологий интеграции разработки и эксплуатации ПО (Development Operations, DevOps) привело к быстрому росту спроса на CI/CD-инструменты. Существующие решения постоянно улучшаются, стремясь идти в ногу со временем, выходят их новые версии, в мире контроля качества ПО (Quality Assurance, QA) постоянно появляется множество новых продуктов. При таком богатстве выбора подбор подходящего инструментария оказывается нелёгкой задачей.
Среди всех существующих CI/CD инструментов существуют два проекта, на которые, определённо, стоит обратить внимание тому, кто ищет что-то из этой сферы. Речь идёт о Jenkins и об инструменте GitLab CI/CD, который является частью платформы GitLab. У Jenkins имеется более 16000 звёзд на GitHub. Репозиторий GitLab на gitlab.com набрал чуть больше 2000 звёзд. Если сравнить популярность репозиториев, то окажется, что Jenkins набрал в 8 раз больше звёзд, чем платформа, в состав которой входит GitLab CI/CD. Но при выборе CI/CD-инструмента это — далеко не единственный показатель, на который стоит обращать внимание. Есть и масса других, и это объясняет то, что во многих сравнениях Jenkins и GitLab CI/CD оказываются очень близко друг к другу.
Читать полностью »
