Статьи

Управление релизами на платформе NetBeans: AgroSense

Модульная разработка программного обеспечения вводит новые вопросы в более мягкий цикл разработки. Один из этих вопросов: « Как мне разделить приложение на модули? » Другой вопрос: «Как мне управлять циклом выпуска модульного приложения?» Несколько руководителей проектов платформы NetBeans задали этот вопрос … и вот первый ответ от Тимона Веенстра, который работает над AgroSense ( платформой с открытым исходным кодом в сельскохозяйственном секторе), который делится советами по версионированию, тегированию, ветвлению, Maven и репозитории ниже.
Гертьян Виленга

 

Управление версиями, тегирование и ветвление

Обычно мы используем тройной номер версии (abc):

  • Последнее число (c) увеличивается с помощью нашего выпуска на две недели. Каждый модуль получает новую версию, даже те, которые не изменились. Когда в модуле исправлена ​​ошибка prio 1, он выпускается отдельно с дополнительным номером патча (например, 1.0.20.1 для первого патча в версии 1.0.20). В этом случае тег 1.0.20 повышается до ветви (для всего репо, а не только для модуля). Изменения в ветке возвращаются по умолчанию.
  • Второе число (b) увеличивается на вехи (примерно каждый квартал, т. Е. 4 раза в год).
  • Первое число (а) будет меняться, вероятно, только один раз в год или два года.

специалист

Мы используем плагин релиза Maven, чтобы выполнить наш релиз. На этапе подготовки номера версии модуля обновляются до следующей версии (1.0.19 -> 1.0.20 или -> 1.1 в случае выпуска этапа). На этапе выполнения модули загружаются в репозиторий релизов в Sonatype . Когда мы закрываем репозиторий Sonatype, модули синхронизируются с центральным Maven.

Одна хитрость, которую мы используем с репозиторием релизов Maven, — это использование локального репозитория в качестве developerConnection :

<developerConnection>scm:hg:file://localhost${basedir}</developerConnection>

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

Хранилища

В настоящее время мы поддерживаем два репозитория, «core» и «extra». Модули и комплекты организованы так, как если бы они были одним хранилищем. Разница заключается в том, что дополнительный модуль в основном наборе будет расположен в другом хранилище исходного кода.

Оба репозитория имеют собственный модуль центра обновлений (модуль «uc-core» и модуль «uc-extra»). Центры обновлений указывают на файл catalog.xml, расположенный на нашем сервере, с версией major.milestone в своем пути, которая в настоящее время:

agrosense.nl/updates/core/1.0/catalog.xml

Таким образом, мы можем поддерживать обновления предыдущей версии этапа в переходный период. (И вообще API могут нарушить обратную совместимость только в новом выпуске.)

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

Чтобы создать файл catalog.xml, нам нужно выполнить несколько ручных задач. Мы поддерживаем прикладной модуль modules-core и modules-extra. Они зависят от всех модулей, которые должны быть выпущены для этого хранилища. Мы генерируем catalog.xml, выполняя

$mvn clean package -Pdeployment

Затем нам нужно удалить все модули NetBeans из «catalog.xml» и очистить раздел лицензий. После очистки мы загружаем «catalog.xml» и «catalog.xml.gz» на наш сайт.