В настоящее время моя команда использует довольно простой процесс ветвления / развертывания, который выглядит следующим образом:
┌────────┐ ┌────┐ ┌──────┐
Environments: │ DEV │ │ QA │ │ PROD │
└────────┘ └────┘ └──────┘
▲ ▲ ▲
│ │ │
┌────────┐ ┌────┐ ┌──────┐
Builds: │ DEV │ │ QA │ │ PROD │
└────────┘ └────┘ └──────┘
▲ ▲ ▲
│ │ │
┌────────┐ ┌────┐ ┌──────┐
Branches: │ master │ │ qa │ │ prod │
└────────┘ └────┘ └──────┘
Каждая среда имеет свою собственную ветку (мы используем git ) и свою собственную сборку, которая использует эту ветку. Когда мы хотим перейти из одной среды в другую, например, из DEV в QA, мы объединяем masterветку qaи запускаем новую сборку QA (которая затем автоматически развертывается в среде QA).
Мы рассматриваем возможность перехода к новому процессу, который избавит от необходимости иметь выделенную ветку и сборку для каждой среды. Вместо этого, единственная сборка выпуска создаст «пакет развертывания», который затем можно будет развернуть в любой среде. Мы представляем, что типичный рабочий процесс будет выглядеть примерно так:
┌────────┐ ┌────┐ ┌──────┐
Environments: │ DEV │ ──► │ QA │ ──► │ PROD │
└────────┘ └────┘ └──────┘
▲
\
┌───────────────┐
Builds: │ release build │
└───────────────┘
▲
│
┌────────┐ ┌─────────┐
Branches: │ master │ │ release │
└────────┘ └─────────┘
Продвижение из одной среды в другую больше не будет обрабатываться в системе контроля версий; скорее мы просто возьмем уже собранные двоичные файлы («пакет развертывания») и добавим их в новую среду.
Эта новая система позволит нам развернуть любую сборку в любой среде, что имеет ряд преимуществ. Например, тривиально проверить исправления ошибок PROD в DEV и QA. Наша нынешняя система не предоставляет простого способа сделать это без отката ветки, чего мы, очевидно, хотели бы избежать.
Самым большим недостатком этой новой системы является то, что у нас больше нет автоматического способа отслеживать, какой код находится в какой среде. Если нам нужно исправить в PROD, у нас больше не будет выделенной ветви, синхронизированной с текущей производственной базой кода. То же самое касается QA - если мы хотим внести быстрое изменение в QA без углубления в masterтекущую работу , у нас больше нет ветки, которая отражает текущее состояние среды QA.
Как мы можем отслеживать, какой код находится в каждой среде?
Некоторые варианты, которые мы рассматриваем:
- использование тегов git для отслеживания того, какой коммит находится в какой среде
- встраивание коммита git, используемого сборкой, в каждый пакет развертывания
Ответы:
Git-теги - это то, что вы действительно хотите использовать для обозначения выпусков. Причина в том, что они имеют для вас значение и могут быть использованы для быстрого распознавания связи между развернутым кодом состояния и любой информацией, которую может иметь сервер сборки (например, номер сборки).
Хотя это ответ, который вы ищете, он решает только половину проблемы. Другой - "эй, вот развернутый
.[wje]arна сервере, с какой сборки он взялся?" Мы знаем, что у вас никогда не будет разных версий приложения, развернутого на dev и qa или prod. Правильно?Решение этой части вопроса состоит в том, чтобы сервер сборки поместил информацию в манифест. Исходя из примера maven и svn, который я имею перед собой:
Это в конфигурации архива maven-war-plugin. Но вы можете найти это и в других плагинах. Затем в Гудзоне часть вызова сборки maven:
который устанавливает те, которые затем определяет Maven. И тогда нужно просто посмотреть в файле MANIFEST.MF, который был развернут на сервере, чтобы узнать, какая это версия.
Есть плагин git , который предлагает подобный набор переменных окружения, включая:
GIT_COMMIT- ША текущегоGIT_BRANCH- Имя удаленного репозитория (по умолчанию - источник), за которым следует имя используемой в данный момент ветви, например, «origin / master» или «origin / foo».Комбинация этих двух методов позволяет вам легко идентифицировать сборку (потому что номера сборок идут вперед и имеют значение, в отличие от контрольных сумм ша) и конкретный коммит git, из которого она построена.
источник
Совершенно другой подход будет отклонить идею
versionsполностью. У вас есть только «одна версия», которая имеет другое настраиваемое поведение. Единственное отличие состоит в том, что у вас есть общая кодовая база - даже в производственной среде вы будете развертывать незавершенную работу, но не активировать.Разница сводится только к тому, что в вашем продукте включены различные наборы функций.
Деактивация / активация осуществляется с помощью переключателей функций .
Вверх: весь процесс выпуска упрощен: вы всегда поставляете интегрированную версию своего программного обеспечения. Каждая функция всегда доступна в
master. Никаких дополнительных веток не требуется.Нет ничего сложного в объединении функций, потому что: нет ответвлений, нет необходимости в объединении. Нет никакой путаницы, какая функция находится на какой ветви и может зависеть, или конфликтует с функциями других ветвей. Каждая часть может быть активирована по желанию. Даже откат больше не нужен: это всего лишь щелчок переключателя .
Я не знаю, работает ли это для вашей кодовой базы: предварительные условия с точки зрения качества кода и дисциплины разработчика довольно высоки - вам придется иметь дело с «очисткой» после того, как функция станет основной функциональностью, и вам придется управлять кучей переключателей предотвращение большего беспорядка .
Возможно, это работает для вас.
источник
Мы используем maven, чтобы поместить версию в файл манифеста. Затем попросите приложение отобразить версию веб-приложения или конечную точку / version для веб-служб.
источник