Управление версиями целевой платформы с помощью Git в закрытой корпоративной среде

Контекст

Мы разрабатываем ряд плагинов, которые собираются в приложения Eclipse RCP 3.X. Мы используем единую целевую платформу, основанную на репозиториях P2, потому что это единственная разновидность, поддерживаемая Tycho.

Целевая платформа VS SCM

Наш доступ в Интернет весьма ограничен. Мы не можем получить доступ к общедоступным репозиториям P2, даже если настроим прокси. Поэтому мы загружаем zip-файлы репозиториев P2 и помещаем их в систему управления версиями, чтобы команда могла ими поделиться и управлять версиями. Однако мы считаем, что наличие бинарного контента в SCM часто является плохой практикой.

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

Сценарий 1. Использование отдельного репозитория Git для целевой платформы

  • Pros:
    • Plugins are shared
    • Позже мы можем вернуться к «физической» предыдущей версии целевой платформы.
    • Сменить целевую платформу так же просто, как манипулировать файлами
  • Cons:
    • Binaries in SCM
    • Каждый экземпляр репозитория использует много места на диске для хранения всей истории целевой платформы.

Сценарий 2. Использование Nexus с подключаемыми модулями для управления репозиториями P2

  • Pros:
    • Plugins are shared
    • Облегченный репозиторий: требуется версия только файла foo.target.
  • Cons:
    • We never used Nexus previously
    • Изменение содержимого целевой платформы является более сложным
    • Нам нужно вручную хранить архивную копию каждой версии содержимого целевой платформы.

Вопросы

Как вы управляете версиями целевой платформы с помощью Git в закрытой корпоративной сети? Что вы думаете о приведенных выше сценариях и их соответствующих плюсах и минусах? Не могли бы вы предложить другие решения?


git eclipse-rcp tycho p2 target-platform
person S. Cambon    schedule 10.07.2014    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Используя Nexus и плагин Nexus Unzip, можно найти очень хорошее решение, которое удовлетворит ваши потребности в воспроизводимая целевая платформа и построение независимо от доступа в Интернет:

  • Настройте Nexus и убедитесь, что у вас есть репозиторий m2, который вы можете развернуть, например. с помощью deploy-file.
  • Загрузите нужные вам репозитории p2 в виде zip-архивов (или создайте эти zip-архивы самостоятельно, если они не предлагаются для скачивания).
  • Разверните заархивированные репозитории p2 в репозиторий Nexus m2, используя версию без SNAPSHOT. Артефакты, отличные от SNAPSHOT, в Nexus являются неизменяемыми, поэтому, когда вы ссылаетесь на репозитории p2 через их URL-адреса в Nexus, вы всегда будете получать одно и то же содержимое.
  • Установите плагин Nexus Unzip и настройте его на "теневое"/обслуживание контента из имеющегося репозитория. развернут в. Таким образом, заархивированные репозитории p2 получают URL-адрес «unzip», который делает их похожими на обычные репозитории p2 для Eclipse и/или Tycho.
  • Наконец, создайте целевой файл определения, ссылающийся только на репозитории p2 в вашем Nexus, и поместите этот файл в свой репозиторий git.

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

Это похоже на ваше решение 2, но с использованием другого плагина Nexus. Вам не нужны какие-либо плагины для явной «поддержки репозитория p2» для описанного решения. Кроме того, вам не нужно дополнительно архивировать содержимое вашей целевой платформы.

Отказ от ответственности: плагин Nexus Unzip предлагается проектом Tycho, коммиттером которого я являюсь.

person oberlies    schedule 14.07.2014