Как стать автором
Обновить

Комментарии 7

Добавьте пожалуйста больше технических подробностей

Вы могли бы уточнить, каких подробностей не хватило в статье?

Вы в volumes храните данные или в контейнеры собираете? Если в volumes, то как у вас организовано версифицирование и rollout/rollback?

Мы не храним ничего в контейнерах, все микросервисы у нас stateless.

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

А что именно он выкладывает в релизную ветку? релизная ветка имеет название версии вашего продукта?

Наше приложение работает на базе микросервисной архитектуры и все его компоненты хранятся в одном репозитории.

Сколько у вас компонентов?

Благодаря этому собираются и устанавливаются все микросервисы, даже если изменился один из них.

То есть при каждом релизе вы деплоите (удаляете и снова создаете) все докер образы в кубере?

Единый пайплайн CI/CD, который гарантирует, что приложение как единая система проходит все тесты

Аффектит ли ошибка в компоненте системы на другие системы? Я так понимаю другие разработчики ждут пока все у кого ошибка в тестах их не исправят. Верно? Хотя наверное у вас Feature branch и ошибки исправляются в тестах в Feature branch.

GitLab Runner забирает код из нужного репозитория, командой сборки Java-приложения собрает и отправляет его в Docker registry.

Какая версия Java? Какой вендор Java вы используете? Какой средний размер образа docker?

Версию приложения мы получаем из результатов выполнения команды
git describe --tags --abbrev=7.

Почему 7?
git describe --tags --abbrev=7 — получается какая-то расширенная версия…

2. Синхронизация с Git-репозиторием исходного кода заказчика
4. Автоматическое развертывание всех изменений в тестовой среде (UAT)

Сначала вы синхронизируетесь с Git-репозиторием заказчика, а потом вы развертываете в тесте? Сначала обычно тестируют в тесте, а потом отправляют изменения заказчику.

Если в результате что-то пошло не по плану, то Helm автоматически и самостоятельно откатит все свои изменения. Его работу не нужно контролировать.

Как вы справляетесь с проблемами helm?
habr.com/ru/company/southbridge/blog/429340
habr.com/ru/company/flant/blog/438814

Чтобы развернуть обновление в продуктовое окружение, остаётся лишь нажать одну кнопку в GitLab — и контейнеры сразу доставляются в продуктовую среду.

Эта кнопка в продуктовом GitLab?

Статья интересная. Спасибо за статью.
А что именно он выкладывает в релизную ветку? релизная ветка имеет название версии вашего продукта?

Релиз :)
Изменения собираются в очередную RC ветку, которая проходит все необходимые предрелизные процедуры и потом эта ветка мержится в релизную ветку.


Сколько у вас компонентов?

На данный момент около 20


То есть при каждом релизе вы деплоите (удаляете и снова создаете) все докер образы в кубере?

Docker-образы в кубернетисе мы не удаляем, но да, всё приложение разворачивается из новых версий docker-образов.


Аффектит ли ошибка в компоненте системы на другие системы? Я так понимаю другие разработчики ждут пока все у кого ошибка в тестах их не исправят. Верно? Хотя наверное у вас Feature branch и ошибки исправляются в тестах в Feature branch.

У нас разработка в feature-ветках, и на Merge Request обязательно запускается билд с прогоном всех тестов, так что ошибки изолируются.


Какая версия Java? Какой вендор Java вы используете? Какой средний размер образа docker?

OpenJDK 8


Почему 7?
git describe --tags --abbrev=7 — получается какая-то расширенная версия…

На самом деле, по умолчанию git describe выдает хэш последнего комита именно из семи символов. Но мы решили это проставить явно, чтобы не зависеть от возможного изменения дефолтного поведения команды.


Сначала вы синхронизируетесь с Git-репозиторием заказчика, а потом вы развертываете в тесте? Сначала обычно тестируют в тесте, а потом отправляют изменения заказчику.

Это среда UAT — User Acceptance Testing. То есть та среда, где конечные бизнес-пользователи или владельцы продукта могли проверить главные бизнес-фичи.


Как вы справляетесь с проблемами helm?
habr.com/ru/company/southbridge/blog/429340
habr.com/ru/company/flant/blog/438814

С какими именно? В этих статьях довольно большой обзор разных проблем.


Эта кнопка в продуктовом GitLab?

Да

Зарегистрируйтесь на Хабре , чтобы оставить комментарий