Skip to content

Latest commit

 

History

History
137 lines (86 loc) · 7.79 KB

common.ru.md

File metadata and controls

137 lines (86 loc) · 7.79 KB

Общее описание

Инструмент repo-build предназначен для поддержки процессов компонентной разработки

Компонентная разработка

Проект

Проект состоит из нескольких компонентов. При сборке проекта получается дистрибутив. Дистрибутив включает заданные зарелизеные версиии компонентов проекта.

Компонент

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

Каждый модуль модет зависеть от модулей других компонентов Если модуль компонента А зависит от модуля компонента Б, то считается что компонент А зависит от компонента Б Циклические зависимости между компонентами запрещены, потому что такие зависимости не позволят релизить компоненты.

Поддерживаемые скрипты сборки модулей

Maven

см maven-feature.ru.md

Поддерживаемые системы контроля версий

Git

см git-feature.ru.md

Манифест проекта

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

Манифест ведется в формате android repo

Это xml файл с имененм default.xml

<?xml version="1.0" encoding="UTF-8"?>
<manifest>
  <remote name="origin" fetch="https://github.com/org1" />

  <default revision="refs/heads/develop" remote="origin" sync-j="1" />

  <project name="component1.git" remote="origin" path="component1" revision="refs/heads/develop" />
  <project name="component2.git" remote="origin" path="component2" revision="refs/heads/develop" />
</manifest>

Для манифеста заводится специальный репозиторий с именем manifest в котором ветки соответствуют релизам проекта

Базовое использование

Установка

Распаковать сборку repo-build-X.Y.Z.zip, например в ~/opt
прописать путь в PATH

Получение проекта

Получаем проект, переключаемся на релиз, генерируем центральный pom.xml файл, собираем

mk myproject
cd myproject
repo-build -M https://gitlab/myproject -b release1 init sync build-pom
mvn clean install

Переключаемся на фичу, генерируем build файл, собираем

repo-build -f feature1 switch build-pom
mvn clean install

В одном вызове можно комбинировать набор команд, если задать несколько команд, то они будут исполнятся в том порядке в ктором были перечислены

Подключение repo-build к существующему проекту

Создаем репозиторий manifest Создаем default.xml и перечисляем репозитории проекта Создаем бранч с именем соответствущем текущему релизу

Затем, см пункт Получение проекта

Обновление проекта

repo-build sync

после исполнения, мы получаем обновленные локальные ветки кторые соответствуют текущему манифесту

Обновление фичи, если находимся на фиче

repo-build -f featureBranch sync switch

после исполнения, мы получим обновленные локальные ветки кторые соответствуют текущему манифесту и обновленные фича ветки в тех компонентах в кторых они есть

Обновление фичи, если находимся на фиче и имеем несохраненные локальные изменения в нескольких компонентах

repo-build -f featureBranch stash sync switch stash-pop

после исполнения, мы получим обновленные локальные ветки кторые соответствуют текущему манифесту и обновленные фича ветки в тех компонентах в кторых они есть если в какихто репозиториях были незакоммиченные измения они буду сохранены и после обновления восстановлены

если при исполнении этой команды мы получаем коллизию, процесс останавливается мы исправляем проблему вручную и продолжаем процесс

repo-build stash-pop

Вливание релиза в фичу

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

repo-build можно использовать для автоматизации этого процесса

Процесс вливания релиза в фичу состоит из нескольких шагов

  • Мерж релизных веток указанных в манифесте в фича ветки

    repo-build -f featureBranch feature-merge-release

если при этом произошла ошибка требующая вмешательства пользователя то исправляем коллизию и заново запускаем команду

  • Обновлениее версии parent артифакта, потому что в релизе он мог изменится

    repo-build -f featureBranch -P parent feature-update-parent

если при этом произошла ошибка требующая вмешательства пользователя то исправляем коллизию и заново запускаем команду

  • Обновление версий зависимостей между mygroup компонентами, потому что в релизе зависимости могли уйти вперед

    repo-build -f featureBranch -i mygroup:* feature-update-versions

если при этом произшла какая либо ошибка требующая вмешательства пользователя то можно продолжить с нужного компонента

repo-build -f featureBranch -i org.mygroup:* -С component2 feature-update-versions