Соглашение о релизе


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

папка должна иметь название вида <project_name>-<short_version>
папка должна быть расположена на общедоступном ресурсе, логичным ресурсом в данном случае является share:\IT\Distr<Project_name>\

Имя проекта
Имя проекта (project_name) - это название проекта, причем короткое

Версии

начальный формат X.Y

в самом начале проекта, правила именования версий простое

  1. проект имеет версию 0.0-<arch>, где дата - это дата начала первых работ по проекту
  2. каждый завершенный спринт добавляет +0.1 к версии, таким образом после первого спринта версия имеет формат 0.1-<arch>, где дата - это дата сборки папки релиза (см. ниже)

соответственно после первых 8 спринтов - версия будет иметь формат 0.8-win32
в год - максимально возможны 26 спринтов - таким образом версия проекта после года работы в рамках выпуска релизов будет иметь вид 2.6-win32

регламентированный формат X.Y.Z.W

менеджер продукта может перейти на расширенное версионирование своего продукта

X (major) - счетчик изменения архитектуры продукта, начальное значение 0, увеличивается после каждого согласования изменения архитектуры всего продукта. первоначальное изменение до +1 происходит после запуска первой версии продукта в production.
Y (minor) - счет новых компонентов внутри архитектуры, начальное значение 0. увеличивается за счет расширения компонентов продукта (features and archcomponents)
Z (version) - номер спринта команды, увеличивается инкрементально с момента старта продукта.
W (build) - номер изменения в исходных кодах (changesets) с момента жизни репозитария продукта

Шаблон каталога релиза

./docs - текущая документация для пользователей и администраторов
./lib - текущие дополнительные файлы и библиотеки исполняемого кода
./plugins - расширения, если используются
./utils - утилиты для настройки и развертывания
release-notes.md - описание релиза
<project_name>.<project_type_ext> - главный файл
readme.md - краткое описание продукта
install.md - краткий способ развертывания продукта

Типы проектов

project_type_ext - расширение зависящие от типа продукта

  • для 1С продуктов это файл cf или cfu
  • для С# продуктов это файлы exe, dll и т.д.
  • для Java продуктов это файлы типа jar или war и т.д.

Подробное описание назначения каталогов

./docs - это каталог где лежат (если они не встроены в продукт) документы-инструкции для пользователей и администраторов.
./lib - это каталог где лежат все дополнительные библиотеки проекта (для 1С это является каталогом внешних обработок и внешних отчетов), фактически это все дополнительное необходимое для работоспособности главного файла проекта
./plugins - это каталог, где лежат дополнительные файлы разработанные как дополнение к проекту, но совершенно не обязательно. Для 1С это включает те бинарные файлы, которые необходимо включить в конфигурацию в режиме предприятия.
./utils - это те утилиты которые необходимы для автоматизации развертывания и ее проверки


главный пост расширяемый и дополняемый

И все это должно лежать под какой-нибудь VCS? Или это обыкновенные папки на дисках?
Частенько документация к релизу немного запаздывает (именно подробная документация, а не описание релиза) и может выйти после релиза самого продукта. Как в этом случае надо поступать?

Так сказать наследие прошлого. Я исходил из посыла, что если артефакты публиковать в единый каталог откуда его будут забирать НЕ разработчики, то им будет наглядней. А оказалось, что в принципе - есть дата файла, и подобное не нужно. Но исправить я забыл.

Конечно в VCS, но для обычных 1С-ников оказалось удобней вначале разобраться со структурой каталогов, а уже потом учиться делать git commit -m

А каталог с тестами, которые прогоняет CI-сервер, не должен находится в этой папке? Если нет, то где?

1 Симпатия

Тут есть два подхода

Есть 2 подхода:

  1. внутри репозитория с конфигурацией
  2. отдельный git репозиторий

Я склоняюсь ко первому подходу.

Если тесты внутри репозитория, значит вы разбираете хранилище не v83unpack-ом. Потому что он перед коммитом очищает весь каталог.
Вообще мне тоже ближе первое, но я не пойму как правильно организовать хранение исходников. Хочется, чтобы была папка «ИмяПроекта» под управлением git-а, внутри которой были бы каталоги: src, tests, utils. Т.е. при получении из репо ИмяПроекта я хочу получить всё: и исходники, и тесты, и внешние отчеты. Но для этого на текущий момент надо напильником под себя подточит анпак.
Или все в корне неправильно?

Что-то не так - причем с v83unpuck’ом. Он действительно очищает каталог, но не полностью репозитория, а конечного каталога. Поэтому у нас тесты в отдельном каталоге.

Сегодня посмотрю соответствует ли версия на github нашей версии… вдруг что-то не так.
@EvilBeaver возможно скажет чуть подробней - он сейчас немного с обработкой разбирается с целью портирования и рефакторинга.

По-крайней мере у меня он каталог не очищает. Вернее вот что:
У него много экспортных методов, выполняющих атомарные подоперации. И есть “главная” операция - “синхронизировать хранилище с гит” В эту синхронизацию мы передаем путь к хранилищу и путь к локальной рабочей директории гита. Эту папку v83unpack не очищает. Он делает выгрузку и раскладывает все файлы внутри рабочей директории гита, после чего делает git commit.

Возможно, какая-то под-операция в v83unpack чистит некий каталог, но “синхронизация” - нет.

Ну как нет? По-другому б и не получилось. Ведь не анализируется что в метаданных удалили, что добавили, а что переименовали. Поэтому прежде чем скопировать все исходники в каталог гит, его очищают, оставляя только каталоги, начинающиеся с “.” и пару файлов: VERSION и AUTHORS
Конкретно вот в этой процедуре: "РазложитьМодули1СПоПапкамСогласноИерархииМетаданных"
Цепочка такая:
СинхронизироватьХранилищеКонфигурацийСГит
РазложитьМодули1СпоНомеруВерсииХранилища1С
РазложитьКонфигурацию1СПоПапкамСогласноИерархииМетаданных

А можно подробнее? Если я правильно тебя понял, то можно сделать папку с именем ИМЯПРОЕКТА под управлением гита, а уже в ней сделать подпапки с именами SRC и TESTS?
в83Анпаку указать в качестве приемника каталог SRC. Но тогда он не сможет сделать коммит, т.к. он будет выполнять гит-команды именно из этой папки, а она напрямую не под гит (только через родителя).

Точно так, но как оказалось моего патча на это в основном стволе разработке не оказалось. Сейчас опубликую.

есть форк, как оказалось на инфостарте общались с человеком, который исправил v8unpack не на удаление, а только на копирование файлов - обещал выложить форк на github

Вот этот человек? http://www.avtomat.biz/blog/kak-my-upravlyaem-versiyami-git1c#.VFnAuB9ws-d

Добрый день, и в правду общались. Как и обещал выложу все, что наработал. Но хочу предупредить что писалось сугубо под задачи отдела

Охохо, да пишу полностью с чистого листа (С++). Публичная тестовая версия думаю появится к концу месяца.

А чего это ты такое пишешь ? :wink:

По сути unpack, лишенный проблем с системами с ограниченной памятью, кросс-платформенный (mac - уже кое-что работает, win - компилируется, но не проверял, linux - еще не пробовал собирать), раскладывающий все уже верно и правильно с человеческими именами, что главное не нужно будет 1С:Предприятие для post-разборки.

Я повторюсь как и @artbear - зачем ты пилишь очередное творение.

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

p.s. имхо, все правильно, из открытых сейчас известно только о v8unpack и все. Знаем, что есть у Александра Белова и у Валерия Агеева, так же вроде как у MMF и у Elisy .Net Bridge , но это все на текущий момент закрытое и по факту выбирать то не из чего.

p.s.s: опять таки если это все в дальнейшем превратится в открыто ПО, надеюсь что @pbazeliuk так на это смотрит.