Как управлять непрерывной доставкой с помощью микросервисов?

Question

Сейчас мы работаем с Дженкинсом как наш CI и CD, мы также используем методологию Agile (спринт). Мне было интересно, как я могу управлять выпуском своего программного обеспечения.

Например, мы разрабатываем торговый сайт для бизнеса. Разработка состоит из приложения, которое потребляет 3 микросервиса.

Компоненты:

Применение: это пользовательский интерфейс
Micro обслуживание 1: Sales
Micro сервис 2: Пользователи
Micro обслуживание 3: Продукты

Исходное состояние торговый сайт:

Мы начинаем развивать торговый сайт с нуля. Как я уже говорил, мы работаем с Agile Methodology (Sprints).

Спринт 1:
- Разработка микропроцессорных продуктов.
- Разработка микросервиса пользователей.
Конец Sprint 1

К этому времени я могу применить только микро тестирование услуг, как модульное тестирование, тестирование контракта и т.д. Потому что у меня нет приложение готово, я не могу сделать сквозную проверку или функциональное тестирование на основе всей системы, а также я не могу развернуть среду UAT (показать бета-версию для пользователей), потому что пользователь не сможет провести пробное тестирование. Поэтому на данный момент мне нужно подождать, пока приложение и микропрограмма продаж не будут завершены, поэтому я могу показать бета-версию пользователю и применить любой другой тип тестирования.

Sprint 2:
- Разработка микросервиса.
- Разработка приложения.
Конец Sprint 2

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

Итак, вопрос в миллион долларов, как бы вы это делали с Дженкинсом и GitLab?

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

P.S. Я сожалею о какой-либо путанице в этом посте, но я пополняю новую тему.

Answer 1

«Независимый» аспект микросервисов здесь очень важен.В принципе, вы должны иметь возможность рассматривать каждую услугу как отдельное приложение, и ваш пользовательский интерфейс не должен зависеть от продаж/пользователей/продуктов как «libs» (например, C# DLL, Java Jars и т. Д.), Но вместо этого следует использовать какой-то API (например, REST API) для вызова друг друга.

Чтобы проиллюстрировать разницу, вы не должны иметь это:

Но вместо этого вы должны иметь что-то вроде этого.

Теперь давайте предположим, что вы находитесь в прекрасном microservices мире с REST API между вашим UI и каждым из ваших услуг.

В Дженкинсе это становится довольно простым. Для каждой службы (основное приложение) требуется задание, которое компилирует, тестирует и развертывает вашу службу на целевом сервере.

До тех пор, пока ваши услуги являются независимыми, и если вы справляетесь приложение правильно versionning, вам не нужно какой-либо синхронизации между любым из заданий Дженкинс.

Конечно, процесс сборки/тестирования/развертывания был бы экстернализирован в общем файле конвейера, чтобы вы могли повторно использовать его на разных ваших работах. Просто передайте новую конечную точку API в службе продаж, прежде чем совершать часть пользовательского интерфейса, которая использует новую конечную точку продаж ... но я думаю, что это просто здравый смысл!

Если вы новичок в Jenkins, хороший старт - это pipeline documentation!