Но вне зависимости от сценария поддержки, используемого для конкретной информационной базы, можно дать несколько рекомендаций по организации самого процесса поддержки, следование которым позволит избежать некоторых типичных проблем, возникающих при работе со «сложными» информационными базами «1С: Предприятия 8».

Использование буферной информационной базы

Методика использования буферной информационной базы состоит в следующем:

• создается информационная база (в соответствии с выбранным сценарием поддержки), которая будет служить буфером между конфигурацией (или конфигурациями, при сценарии «горизонтальной поддержки») поставщика и рабочей информационной базой;

• в буферной информационной базе посредством механизма поставки формируется файл поставки конфигурации (подробнее о работе механизмов поставки и поддержки конфигурации – в предыдущей статье цикла);

• на основе сформированного файла поставки развертывается рабочая информационная база, в ней устанавливается режим полной поддержки;

• все последующие обновления любых поставщиков «прогоняются через буфер»: обновление устанавливается на буферную базу, в ней формируется свой файл обновления, и именно он используется для обновления рабочей базы.

Зачем вводить в цепочку поддержки лишний элемент? В этом «лишнем элементе» есть определенный смысл. Использование буферной информационной базы позволяет:

• избежать редкой, но крайне неприятной проблемы – «установка обновления привела к частичной или полной неработоспособности информационной базы». Конечно, рабочую базу можно точно так же восстановить из резервной копии, как и буферную (хотя на это уйдет, возможно, на порядок больше времени), но в случае буферной базы неудачная попытка обновления будет абсолютно прозрачна для пользователей и не приведет к прерыванию рабочих процессов;

• легко передавать в рабочую базу изменения, сделанные в конфигурации непосредственно на стороне конечного пользователя (например, силами собственного ИТ-отдела). В этом случае буферная и рабочая информационные базы работают по сценарию «вертикальной поддержки», изменения делаются в буферной базе (для обеспечения групповой разработки и возможности «отката» изменений она подключается к хранилищу конфигураций) и после отладки передаются в полностью автоматическом режиме в рабочую базу с помощью штатного механизма поставки и поддержки;

• проводить автоматизированное функциональное тестирование как обновлений, получаемых от поставщиков, так и собственных доработок конфигурации.

При этом трудозатраты на операции «сформировать обновление в буферной базе» и «установить обновление на рабочую базу» можно свести практически к нулю – эти операции поддаются автоматизации штатными средствами платформы «1С: Предприятие 8». Для указанных операций необходимо использовать пакетный режим работы Конфигуратора (запуск из командной строки или командного файла Windows с передачей параметров через набор ключей). Например, так может выглядеть строка запуска Конфигуратора с командой «сформировать файл обновления» в самом простом случае:

1cv8.exe CONFIG /Smyservermybase /WA+ /CreateDistributeFiles – cfufile – v2.0.4

А так в самом простом случае может выглядеть строка запуска с командой «установить обновление на рабочую базу»:

1cv8.exe CONFIG /Smyservermybase /WA+ /UpdateCfg\srvcfu2.0.51Cv8.cfu /UpdateDBCfg

Перечень параметров командной строки, используемых для управления Конфигуратором в пакетном режиме, содержится в документации к «1С: Предприятию 8», этот перечень также легко найти в Интернете.

Функциональное тестирование обновлений

Любимая программистами «Общая теория ошибок» гласит: обновление программного обеспечения – это отличный способ внести в него дополнительные ошибки. Шутки шутками, но в сложной информационной системе, разные элементы которой созданы разными командами разработчиков и собраны в единое целое еще одной командой, процесс обновления действительно чреват риском породить в работающей системе ошибки. Обновление может само по себе содержать ошибку (ошибки есть в любом ПО); обновление по разным причинам может оказаться несовместимым с доработками, сделанными в конфигурации; наконец, ошибка может быть допущена в процессе объединения конфигураций (сотни объектов, все нужно проверить, для всех выставить правильный режим обновления, ничего не упустить).

Тест-центр, результаты тестирования

Борьбу с ошибками можно вести двумя принципиально разными способами:

• дождаться, пока ошибка обнаружится сама собой (обычно в этом охотно помогают пользователи информационной системы) и попытаться исправить ее на ходу;

• перед тем как отдавать обновленную систему в эксплуатацию, провести функциональное тестирование, проверить работоспособность ключевых функций, сравнить результаты расчетов с эталонами. В случае выявления ошибок – локализовать, исправить, снова провести функциональное тестирование. И так до тех пор, пока все тесты не будут пройдены успешно.

Первый способ подкупает своей простотой – фактически делать ничего не нужно; даже если в конфигурацию и были внесены ошибки, пользователи легко могут их не заметить, а если и заметят, всегда можно свалить вину на поставщика тиражной конфигурации. Но привлекательность простых решений в ИТ обманчива. Во-первых, когда ошибка все-таки замечена, придется затратить значительное количество самых ценных и невосполнимых ресурсов – нервов и времени. К сожалению, самая серьезная ошибка выявляется именно в тот момент, когда она является критичной в высшей степени, а задача на исправление ставится в виде «нужно было еще позавчера». Во-вторых, оба способа представляют собой итерационный процесс, но при первом способе число ошибок после каждой итерации практически не уменьшается. Исправления, которые вносятся в систему на ходу, без предварительного анализа и последующей комплексной проверки, по статистике в ~80 % случаев приводят к возникновению новых ошибок.

Собственно, вопрос, требуется ли функциональное тестирование при обновлении сложных интегрированных конфигураций «1С: Предприятия 8», даже и не стоит. Тестирование требуется, это ясно. Вопрос стоит другой: существуют ли средства, которые помогут упростить, ускорить и, по возможности, автоматизировать тестирование?

Такое средство есть, и называется оно «1С: Корпоративный инструментальный пакет». Этот программный продукт разработан фирмой «1С» и представляет собой набор инструментальных средств для повышения производительности, стабильности и масштабируемости информационных систем на платформе «1С: Предприятие 8». На данный момент пакет содержит две конфигурации:

• «Центр управления производительностью». Этот инструмент мы рассмотрим в следующей статье нашего цикла;

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

Что представляет собой конфигурация «Тест-центр»? Это готовая инфраструктура для хранения, настройки и выполнения тестовых сценариев, а также для сбора и анализа результатов тестирования. Конфигурация легко встраивается в любую информационную базу «1С: Предприятия 8». Тестовый сценарий представляет собой заданную специалистом-тестировщиком последовательность действий, выполняемых «виртуальными пользователями». «Действие» в терминах «Тест-центра» – созданная на основании шаблона обработка, в модуле которой запрограммированы выполняемые «виртуальным пользователем» операции с объектами информационной базы. Действие может быть довольно простым (создать и записать элемент справочника), сложным (выполнить запрос, на основании результатов запроса создать, заполнить и

Добавить отзыв
ВСЕ ОТЗЫВЫ О КНИГЕ В ИЗБРАННОЕ

0

Вы можете отметить интересные вам фрагменты текста, которые будут доступны по уникальной ссылке в адресной строке браузера.

Отметить Добавить цитату
×