Непрерывная доставка - выпуск / версия микросервисов - PullRequest
Новая
       85

Непрерывная доставка - выпуск / версия микросервисов

0 голосов
/ 27 апреля 2018

Мы разрабатываем микросервисы с использованием Spring Boot, которые затем упаковываются в виде Helm Charts и развертываются в кластере Kubernetes. У каждого сервиса есть Jenkinsfile, и мы выпускаем каждый сервис по отдельности ниже:

  • Сервис A -> Сборка -> Упаковка -> QA -> Подготовка -> Производство
  • Сервис B -> Сборка -> Упаковка -> QA -> Подготовка -> Производство
  • Сервис C -> Сборка -> Упаковка -> QA -> Подготовка -> Производство

Этот подход довольно прост, но на самом деле он не дает вам отправляемого артефакта, и в результате вы получаете несоответствия.

То, что мы хотели бы сделать, это сгруппировать релиз с помощью зонтичной диаграммы Хелма, показанной ниже (родитель A):

  • Parent A -> Build -> Package -> QA -> Staging -> Production
    • Сервис A
    • Сервис B
    • Сервис C

Я изо всех сил пытаюсь найти способ сделать это без необходимости вручную выпускать каждый сервис, а затем обновлять версии в родительской диаграмме. Кто-нибудь делает это в автоматическом режиме?

Ответы [ 2 ]

0 голосов
/ 03 мая 2018

Я могу поделиться упрощенным представлением о том, как мы отправляем код Codefresh :

  • у каждого микросервиса есть свой собственный git-репо и рулевой график.
  • каждая кодовая база сервиса версионирована (независимо от диаграммы), например в package.json.
  • каждая карта руля также имеет версии.
  • Когда разработчики обновляют службы, они должны увеличить версию в коде.
  • У нас также есть одна Uber-диаграмма Helm, в которой перечислены все диаграммы микроуслуг как требования к диаграмме .
  • Конвейер CI для репозитория кода создает образ докера (помеченный версией кода) и контрольную диаграмму (помеченную версией кода). Это еще ничего не развернуло.
  • Если разработчик хочет развернуться, он редактирует файл требований в убер-диаграмме, требуя новую версию.
  • Конвейер CD на Uber-Chart выполняет обновление руля.

Это очень упрощенное описание. На самом деле конвейер также делает что-то вроде:

  • автоматическая обработка выпусков npm и github
  • Гейтс в зависимости от объема обновления
  • автоматическая подготовка специальных сред в PR / филиале (разверните новую среду, чтобы протестировать / поделиться своими изменениями)
  • секретное управление

Если честно, это не простой конвейер, но, эй, мы - компания CI / CD, так что это наш хлеб с маслом.
Клиенты часто просят нас рассказать больше о проделанной нами работе и даже воспроизвести ее для клиента, что мы с радостью выполняем. Не стесняйтесь пинговать меня.

0 голосов
/ 27 апреля 2018

Если я хорошо понимаю вашу проблему, вы можете решить ее, используя плагин Jenkins Multijob. И без обновления вашей текущей существующей работы.

Ваш рабочий процесс будет выглядеть так: 

Parent Job
    Service A --> Build --> Package --> QA --> Staging --> Production
    Service B --> Build --> Package --> QA --> Staging --> Production
    Service C --> Build --> Package --> QA --> Staging --> Production

Где ваша родительская работа вызывает все ваши детские работы.

Я видел подобную проблему, решенную таким образом. Также иногда ваша детская служба должна быть выпущена вместе, или одна из ваших услуг всегда должна быть впереди (сервер). Вы можете добавить несколько сценариев проверки Python / shell в родительское задание, чтобы убедиться, что ваш конечный продукт всегда доступен для выпуска.

https://wiki.jenkins.io/display/JENKINS/Multijob+Plugin

...