Перейти к основному содержимому

Ветка

Ветка (branch) — это изолированная копия архитектурного состояния системы, предназначенная для описания возможных изменений в текущей архитектуре.

Изоляция изменений в отдельной ветке позволяет вносить правки без влияния на описание текущей архитектуры. Система поддерживает анализ различий между ветками, согласование изменений и их перенос в основную архитектуру — как полностью, так и частично. Эти возможности делают работу с архитектурными изменениями более безопасной и управляемой, что особенно важно в процессе разработки информационных систем.

Типы веток​

  • основная ветка (master) The fallback content to display on prerendering
  • рабочие ветки The fallback content to display on prerendering
  • ветки конфликтов The fallback content to display on prerendering
  • тестовые ветки The fallback content to display on prerendering

Основная ветка​

Эта ветка отражает состояние текущей архитектуры и имеет название "master". The fallback content to display on prerendering могут создавать от основной ветки рабочие ветки (копии).

Рабочие ветки​

Эти ветки могут создаваться The fallback content to display on prerendering или The fallback content to display on prerendering от основной ветки при необходимости описать потенциальные изменения с целью их последующего переноса в текущую архитектуру (основную ветку) путем The fallback content to display on prerendering.

Вариант использования: разработчики получают задание на реализацию нового функционала, в системе task tracker создается задача и начинается анализ. Для отражения потенциальных изменений в архитектуре создается рабочая ветка. Вносимые в эту ветку изменения могут быть переданы на анализ The fallback content to display on prerendering или The fallback content to display on prerendering для выполнения переноса в основную ветку.

Ветки конфликтов​

Эти ветки схожи с рабочими ветками, однако их не могут создать пользователи. Эти ветки появляются при выявлении расхождений между текущей архитектурой, описанной в основной ветке, и загруженной через Integration API в систему информацией с целью выявления расхождений между фактическим состоянием системы и её описанием.

Вариант использования: Integration API позволяет автоматизировать процесс сбора информации о системе через функции импорта данных. При выполнении операции импорта происходит сверка загруженных данных с данными системы и, в случае выявления несоответствий, система создает ветку конфликта и уведомляет The fallback content to display on prerendering, ожидая от него принятия решения о том как поступить с этими расхождениями.

Тестовые ветки​

Эти ветки предназначены для описания текущей архитектуры тестовых сред. Они могут создаваться вручную The fallback content to display on prerendering, контролироваться при помощи Integration API, но не могут быть The fallback content to display on prerendering с основной веткой напрямую. По инициативе The fallback content to display on prerendering в них могут The fallback content to display on prerendering изменения из текущей архитектуры (основной ветки), а из тестовых веток могут создаваться рабочие ветки для последующего The fallback content to display on prerendering в основную ветку, описывающую текущую архитектуру.

Возможности при работе с ветками​

Создание веток​

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

Согласование изменений​

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

История изменений​

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

Параллельная работа над изменениями​

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

Контроль внедрения изменений​

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

Откат изменений​

Если изменения оказываются неудачными, ветку можно откатить или удалить, не затронув основную архитектуру.

Варианты использования веток​

Пример 1​

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

Пример 2​

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