Публикуете новую версию сервиса в Маркет42, и среди полей на этом шаге встречаются «минимальный релиз» и «максимальный релиз». На первый взгляд, это может показаться очередным техническим полем, которое проще заполнить наугад или вовсе пропустить, лишь бы поскорее отправить версию на аудит. На деле это не формальность, а рабочий механизм, от которого напрямую зависит, увидит ли конкретный клиент вашу новую версию, а если увидит, то не получит ли вместо рабочего сервиса ошибку при установке. Разберем в следующих разделах, как именно это работает на практике и что происходит, если релиз конфигурации у клиента выходит за пределы указанного диапазона.
Это не про версию платформы 1С
Первое, что важно понимать: минимальный и максимальный релиз это не про версию платформы 1С не про те самые номера вида 8.3.18 или 8.3.20, которые многие разработчики привыкли указывать в качестве требований к своим решениям. Здесь речь о совершенно другом уровне, о релизе конкретной конфигурации, с которой совместим ваш сервис. Например, не платформа 8.3.20, а конкретный релиз Бухгалтерии предприятия, скажем, 3.0.150, или конкретный релиз Управления торговлей.
Разница принципиальная. Платформа и конфигурация обновляются отдельно друг от друга и с разной периодичностью: можно годами сидеть на одном релизе платформы, но при этом регулярно обновлять саму конфигурацию, и наоборот. А поскольку ваш сервис в большинстве случаев работает именно с объектами и методами конкретной конфигурации: справочниками, документами, регистрами, типовыми процедурами, то и совместимость логично привязывать не к платформе, а именно к релизу конфигурации, в которой эти объекты определены.
Поэтому, заполняя поля минимального и максимального релиза, важно сразу ориентироваться на номер версии конфигурации, а не платформы: если перепутать одно с другим, система будет проверять совместимость не по тем данным, и в итоге сервис может либо не показаться тем клиентам, кому он на самом деле подходит, либо, наоборот, остаться видимым там, где уже не должен применяться.
Как это работает?
Минимальный релиз это релиз конфигурации, начиная с которого применяется данная версия файла. Если у клиента конфигурация ниже указанного минимального релиза, сервис для него просто не активируется в этой версии.
Максимальный релиз работает в обратную сторону: если релиз конфигурации у клиента выше указанного максимального, файл автоматически деактивируется.
Клиенты далеко не всегда работают на самой последней версии конфигурации. В сервисе есть период между выходом обновления конфигурации и тем, как это обновление реально дойдет до всех баз, и минимальный и максимальный релиз как раз позволяют точно описать, для какого диапазона версий подходит конкретная версия вашего файла.
При этом применяется самая свежая версия файла, совместимая с его текущим релизом конфигурации.
Когда на самом деле нужны минимальный и максимальный релиз?
Разберем на двух практических ситуациях, зачем разработчику вообще указывать эти поля, а не оставлять их пустыми.
Ситуация 1. Сервис проверен на новой версии конфигурации и доработан под нее
Разработчик заранее протестировал свой сервис на новом релизе конфигурации и увидел, что часть логики нужно поправить, чтобы все продолжало работать корректно. После доработки сервис перестает быть совместим со старыми релизами: в них просто нет тех объектов или методов, на которые теперь рассчитан код. Иногда это же несоответствие отлавливают и автоматические проверки совместимости при аудите.
В этом случае при загрузке новой версии разработчик указывает минимальный релиз, то есть тот, с которого начинается корректная работа сервиса. Эта версия автоматически применится клиентам только после того, как их базы будут обновлены до указанной или более новой версии конфигурации. До этого момента у клиентов продолжает работать предыдущая, совместимая с их текущим релизом версия сервиса. Проверки аудита и совместимости тоже проводятся сразу на новом релизе конфигурации, поскольку именно под него написана эта версия.
Ситуация 2. Нужно выпустить новую версию, пока клиенты обновляются неравномерно
Ситуация похожа на первую, но с важным отличием: разработчику нужно выпустить новую версию сервиса по своим собственным причинам, никак не связанным с обновлением конфигурации, например, добавить функциональность или исправить баг. При этом часть баз клиентов на разделителях уже успела обновиться до нового релиза конфигурации, а часть все еще работает на старом.
В такой ситуации можно загрузить в личный кабинет сразу два файла одной новой версии сервиса:
один файл с указанным максимальным релизом — для тех клиентов, кто еще остается на старой конфигурации;
второй файл с указанным минимальным релизом — для тех, кто уже перешел на новую конфигурацию.
Таким образом обе группы клиентов получают актуальную версию сервиса с нужными доработками, но каждая база при этом получает именно тот файл, который совместим с ее текущим релизом конфигурации, без риска установить неподходящую версию.
Как правильно публиковать новую версию
- Заходим в нужный раздел личного кабинета
Открываем личный кабинет 42Clouds, переходим в «Продукты и сервисы» → «Расширения и обработки» и находим карточку своего сервиса в списке.
- Открываем вкладку с версиями
Внутри карточки сервиса переходим на вкладку «Версии файлов» там хранится вся история публикаций, от самой первой версии до текущей. Нажимаем «Добавить новую версию».
- Загружаем сам файл
Формат зависит от типа решения: для расширения загружается файл .cfe, а для обработки, отчета или печатной формы файл собирается как комплект поставки в .zip. Важно заранее убедиться, что файл открывается и работает корректно, прежде чем загружать его в карточку.
- Указываем минимальный и максимальный релиз
Это релизы конкретной конфигурации (например, Бухгалтерии предприятия или Управления торговлей), а не версия платформы 1С. Минимальный релиз определяет, начиная с какой версии конфигурации файл начнет применяться, максимальный до какой версии он будет действовать. Если максимальный релиз не нужен, поле можно оставить пустым, но минимальный указать обязательно, иначе система не сможет понять, кому показывать эту версию.
- Настраиваем регламентные задания, если они есть
Если сервис работает по расписанию, например выполняет автоматическую выгрузку или обмен данными, регламентные задания настраиваются прямо на этом же шаге, при добавлении версии, а не отдельно после публикации.
- Отправляем версию на аудит
После заполнения всех полей версия отправляется на проверку. Пока идет аудит, у пользователей остается доступна предыдущая версия, так что сервис не перестает работать в этот период. После того как новая версия проходит проверку, она становится доступна пользователям, а предыдущая версия никуда не удаляется и остается в истории версий сервиса.
Чек-лист перед публикацией новой версии
☑️ номер версии соответствует логике обновления (патч, минорное, мажорное);
☑️ в описании понятно, что изменилось;
☑️ минимальный и максимальный релиз указаны корректно;
☑️ файл загружен и проверен, что открывается;
☑️ регламентные задания настроены, если они нужны;
☑️ старые версии остаются доступны в истории.
