Как мы можем отслеживать, какая версия нашего кода находится в каждой среде?

14

В настоящее время моя команда использует довольно простой процесс ветвления / развертывания, который выглядит следующим образом:

                ┌────────┐ ┌────┐ ┌──────┐
 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, используемого сборкой, в каждый пакет развертывания

— Натан Френд
источник

У вас есть система КИ, такая как Хадсон или Дженкинс? Это способно выдвинуть признаки того, что это построило назад к мерзавцу? (Я знаю, что есть плагины для Хадсона и Дженкинса, которые могут ... - не так уверены в других).

@MichaelT Мы используем MSBuild для наших сборок и Octopus Deploy для наших развертываний. Я уверен, что мы могли бы заставить Octopus манипулировать нашим git-репозиторием с помощью специального сценария развертывания Powershell.

— Натан Френд

14

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

Хотя это ответ, который вы ищете, он решает только половину проблемы. Другой - "эй, вот развернутый .[wje]arна сервере, с какой сборки он взялся?" Мы знаем, что у вас никогда не будет разных версий приложения, развернутого на dev и qa или prod. Правильно?

Решение этой части вопроса состоит в том, чтобы сервер сборки поместил информацию в манифест. Исходя из примера maven и svn, который я имею перед собой:

<manifestEntries>
    <Specification-Title>${project.name}</Specification-Title>
    <Specification-Version>${project.version}</Specification-Version>
    <Build-Number>${build.number}</Build-Number>
    <Build-Id>${build.id}</Build-Id>
    <Svn-Revison>${svn.revision}</Svn-Revison>
</manifestEntries>

Это в конфигурации архива maven-war-plugin. Но вы можете найти это и в других плагинах. Затем в Гудзоне часть вызова сборки maven:

-Dbuild.number=${BUILD_NUMBER}
-Dsvn.revision=${SVN_REVISION}
-Dbuild.id=${BUILD_ID}

который устанавливает те, которые затем определяет Maven. И тогда нужно просто посмотреть в файле MANIFEST.MF, который был развернут на сервере, чтобы узнать, какая это версия.

Есть плагин git , который предлагает подобный набор переменных окружения, включая:

GIT_COMMIT - ША текущего
GIT_BRANCH - Имя удаленного репозитория (по умолчанию - источник), за которым следует имя используемой в данный момент ветви, например, «origin / master» или «origin / foo».

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

3

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

Разница сводится только к тому, что в вашем продукте включены различные наборы функций.

Деактивация / активация осуществляется с помощью переключателей функций .

Вверх: весь процесс выпуска упрощен: вы всегда поставляете интегрированную версию своего программного обеспечения. Каждая функция всегда доступна в master. Никаких дополнительных веток не требуется.

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

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

Возможно, это работает для вас.

— Томас Джанк
источник

Но как насчет того, чтобы разные состояния хранилища были развернуты на разных серверах? Является ли код, работающий на боксе QA, таким же, как и код, запущенный на производстве, чтобы можно было воспроизвести ошибку? Является ли код, который разработчики поместили в свою коробку разработчика, таким же, как код, с которым работает QA?

1

Вопрос должен быть задан по-другому: это ошибка со специальной конфигурацией, воспроизводимая «сейчас», если да, вы можете это исправить. Если нет - имеет ли значение ошибка? Вы всегда работаете (и встроенный код).

— Томас Джанк

-1

Мы используем maven, чтобы поместить версию в файл манифеста. Затем попросите приложение отобразить версию веб-приложения или конечную точку / version для веб-служб.

— Джош Шаппель
источник