8»
Микита Зайцев
Тиражные программные продукты отличаются от индивидуальных и заказных прежде всего тем, что разработчик и пользователь программы связаны отношением «один ко многим». Разработчик у продукта – один, а пользователей сотни и тысячи. Тиражный программный продукт непрерывно совершенствуется: разработчик исправляет выявленные ошибки, добавляет новые функции, отражает изменения законодательства и т. д. В случае полностью закрытых систем процесс передачи новой версии конечному пользователю, как правило, тривиален: разработчик выпускает дистрибутив, пользователь получает его и запускает у себя. В случае систем с открытой архитектурой, позволяющих пользователю самостоятельно вносить изменения в прикладное решение, ситуация усложняется: простым обновлением библиотек уже не обойтись. Платформа «1С: Предприятие 8» позволяет пользователям не только изменять и дорабатывать прикладное решение под свои нужды, но и переносить функциональные блоки из одного прикладного решения в другое и даже объединять прикладные решения, полученные от разных производителей, в единый программный комплекс. Разумеется, такая «функциональная свобода» несколько усложняет сопровождение и поддержку прикладных тиражных решений.
В рамках статьи будут подробно рассмотрены механизмы платформы «1С: Предприятие 8», которые должны упростить и регламентировать взаимодействие между разработчиками и пользователями тиражных решений, разобраны некоторые типичные проблемы, возникающие при установке обновлений, а также даны некоторые технические рекомендации по внесению изменений в типовые конфигурации.
Основное средство автоматизации процессов обновления и сопровождения прикладных решений в технологической платформе «1С: Предприятие 8» – механизм поставки и поддержки конфигураций. В документации к платформе и учебной литературе этот механизм описан как единое целое, но в рамках статьи мы для удобства изложения будем использовать термины «механизм поставки» и «механизм поддержки». Дело в том, что каждый из участников процесса работает со своим функциональным блоком.
• Поставщик конфигурации (фирма, выпустившая тиражное решение) работает с функциями механизма поставки конфигураций.
• Пользователь конфигурации (фирма, использующая тиражное решение) работает с функциями механизма поддержки конфигураций.
Сколь бы сложной ни была схема работы с прикладным решением, конкретный специалист, работающий с конкретной конфигурацией, в определенный момент времени выполняет функции либо поставщика, либо пользователя конфигурации.
Полный цикл взаимодействия поставщика и пользователя прикладной конфигурации «1С: Предприятие 8» выглядит следующим образом:
1) поставщик создает первую версию конфигурации (версия 1);
2) посредством механизма поставки поставщик задает правила поставки для всех объектов конфигурации и создает файл поставки конфигурации. Файл имеет стандартное для «1С: Предприятие 8» расширение CF. Но в отличие от файла, полученного при помощи функции «Сохранить конфигурацию в файл», файл поставки содержит внутренний признак «эта конфигурация может быть поставлена на поддержку»;
3) пользователь получает файл поставки первой версии конфигурации и на его основе разворачивает информационную базу. Конфигурация вновь созданной информационной базы получает признак «находится на поддержке поставщика», по умолчанию для нее задается режим «полная поддержка», в котором пользователь не может вносить изменения в конфигурацию;
4) поставщик вносит изменения в конфигурацию и создает следующую версию (версия 2);
5) посредством механизма поставки поставщик (в случае необходимости) изменяет правила поставки для объектов конфигурации и создает файл обновления конфигурации. Этот файл имеет расширение CFU и содержит не всю конфигурацию версии 2, а только описание изменений, которые были сделаны по отношению к версии 1. При создании файла обновления поставщик должен в явном виде указать, для каких именно предыдущих версий он может быть использован;
6) пользователь получает файл обновления и запускает механизм обновления конфигурации в своей информационной базе. В зависимости от режима поддержки, установленного для конфигурации, процесс обновления выполняется по-разному и требует не только разных действий, но и разной квалификации пользователя.
Самая простая ситуация такова: в информационной базе используется одна конфигурация от единственного поставщика; пользователь не вносил никаких изменений в конфигурацию и не менял установленные по умолчанию правила поддержки конфигурации. В этом случае обновление конфигурации происходит в полностью автоматическом режиме, а от пользователя требуется только нажать кнопку «Далее». После того как обновление успешно завершено, рекомендуется выполнить операцию сохранения конфигурации в файл и хранить полную подборку таких файлов. Для чего это нужно? У специалиста, отвечающего за сопровождение информационной базы, возникают следующие типичные проблемы:
1) в информационной базе была активирована возможность внесения изменений в конфигурацию, что было сделано либо случайно, либо действительно планировались какие-то изменения, от которых впоследствии отказались. И теперь хочется вернуть конфигурацию в режим полностью автоматического обновления;
2) через какое-то время после обновления выяснилось, что по каким-то причинам необходимо вернуться к предыдущей версии конфигурации. Обновление конфигурации может содержать ошибки; к сожалению, они встречаются в любом ПО. Ошибок может и не быть, но пользователям может показаться, что новая версия работает неправильно. Важно, что простое восстановление информационной базы из резервной копии не поможет: с момента обновления прошло время, пользователи внесли в систему какие-то данные и, разумеется, не хотят терять результаты своей работы.
Для возврата конфигурации в исходное состояние необходимо выполнить следующие действия:
1) сделать резервную копию информационной базы (резервное копирование необходимо перед выполнением любых действий с конфигурацией);
2) полностью снять конфигурацию с поддержки (в Конфигураторе: меню «Конфигурация», «Поддержка», «Настройка поддержки», «Снять с поддержки»);
3) загрузить конфигурацию из файла, созданного во время предыдущего обновления (в Конфигураторе: меню «Конфигурация», «Загрузить конфигурацию из файла», на вопрос о «полной замене конфигурации без сравнения и объединения» следует ответить утвердительно);
4) сохранить конфигурацию и обновить базу данных.
Важный нюанс: возврат к предыдущей версии конфигурации не всегда выполним. Если в новой версии конфигурации была существенно изменена структура метаданных и во время первого после обновления запуска информационной базы были произведены автоматические операции с объектами (перезапись элементов справочников или проведение документов), принудительный возврат к старой версии может привести к частичной или даже полной неработоспособности информационной базы. Операцию «отката» необходимо вначале выполнить на тестовом клоне информационной базы и только в случае успешного результата приступать к рабочей информационной базе.
Следует понимать, что операции постановки на поддержку и снятия с поддержки изменяют не только некий внутренний признак конфигурации, но и саму структуру информационной базы. «Физический смысл»