Непрерывная поставка для многокомпонентного проекта

В нашем проекте у нас есть несколько компонентов, разработанных отдельными командами, имеющими отдельные репозитории git. Все компоненты имеют задание фиксации и задание упаковки и публикуют артефакты в артефакте.

Проблема возникает, когда мы хотим развернуть все компоненты как систему.

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

Например У меня есть компоненты A, B, C, и я хочу переместить следующие версии A1, B1, C1 в конвейер развертывания и тестирования. Как я могу гарантировать, что ни одна новая версия компонента не будет развернута в среде QA (на серверах). Я использую Jenkins в качестве инструмента CI/CD. Кажется, мне нужен какой-то инструмент интеграции или упрощенный инструмент управления конфигурацией для управления версиями моей системы в целом, включая все компоненты, которые я могу продвигать в конвейере развертывания.

Надеюсь, я смог описать свой вопрос. Предложения по решению этой ситуации будут действительно полезными.

Спасибо,


continuous-deployment continuous-delivery
person Gopal Singhal    schedule 02.07.2014    source источник

Ответы (1)


arrow_upward
3
arrow_downward

Мы используем этот шаблон:

  • для каждого клиента, который использует наши продукты, есть один «проект»: он почти не содержит кода, только конфигурацию. Мы используем эту схему имен: coreapp_customerslug.
  • проект зависит от N приложений. Проект закрепляет все точные версии зависимостей.

Во время CI мы делаем это:

  1. установить проект P и все закрепленные зависимости
  2. Затем обновите все зависимости до последней версии.
  3. Запустить все тесты
  4. Если все тесты выполнены успешно, обновите версии зависимостей и увеличьте версию проекта.
  5. Сейчас у проекта новый и стабильный релиз.
  6. развернуть новый релиз (на данный момент мы делаем это не автоматически, но в ближайшее время).

С помощью этого шаблона («проект» — это контейнер приложений) вы можете справиться с проблемой версии. Если у вас несколько серверов, процесс обновления должен быть быстрым, чтобы избежать одновременного использования разных версий.

Обновить

CI поддерживает закрепленные версии. Мы используем python и pip, а файл requirements.txt обновляется скриптом. Мы используем схему версии YYYY.N. N увеличивается, если все тесты в порядке.

Внимание: Если app1 имеет последнюю версию N, это не значит, что оно работает во всех проектах. Если у вас есть два проекта: P1 и P2, может случиться так: app1 с последней версией N хорошо работает в проекте P1, но не работает в P2. Это означает, что вы не можете создать новую стабильную версию проекта P2. Иногда это раздражает, но это поддерживает постоянное обновление. Мы всегда используем последнюю версию наших приложений в наших проектах.

person guettli    schedule 02.07.2014
comment
Спасибо, guettli, у меня есть один запрос в этом решении. т. е. кто поддерживает закрепленные версии зависимостей в проекте P. Как вы обновляете версию зависимостей в конфигурациях проекта P, существует ли автоматизированный способ захвата последних версий зависимостей и обновления конфигурации в проекте P? - person Gopal Singhal; 02.07.2014