Как не замучиться с обновлениями

Обновление – это, наверное, одна из самых частых задач, которая стоит практически перед каждым из тех, кто связан с разработкой на 1С.

Главная особенность этой задачи состоит в том, что это не творческий процесс, нужно просто сделать так, чтобы всё работало.

После выполнения этой абсолютно рутинной и скучной работы (выполняется она обычно руками), раздаются звонки, приходят письма: «После вашего обновления, у нас, у нас есть проблемы» – «Я не хочу есть проблемы!»

За долгое время существования 1С появилось много интересных инструментов, которые позволяют сделать этот процесс чуть менее рутинным, чуть более быстрым. Об этом мы и поговорим.

В первую очередь владельцам компаний необходимо понять, что обновления неизбежны.

Подходы к внесению доработок

Краткая памятка по доработке конфигураций:

• Не «ломаем» – избегаем изменения типовых механизмов.

• Все доработки максимально отражаем через код.

• По возможности, минимально затрагиваем объекты поставщика.

• Формы дорабатываем кодом.

• Весь внесенный наш код или измененный код вендора обрамляем комментариями.

Контроль результатов обновления

Как нам проверить те результаты, которые мы получили?

• Первым этапом проверки выступает момент загрузки конфигурации из файлов. После чего мы иногда получаем картинку со многими красными восклицательными знаками. Есть хорошая новость – в платформе 8.3.17 оказалось, что если по этим строчкам кликнуть, то во многих случаях откроется конкретный файлик с указанием проблемного места. Раньше такого не было. Это приятно, это значит, что платформа развивается. Надеюсь, что дальше будет еще лучше, еще проще искать такие проблемы.

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

• Еще – очень хорошо результат загрузки помогают проверить дымовые тесты. С тестами так всегда – чем больше тестов, тем лучше. Здесь показана картинка из многим знакомого Jenkins как раз по результатам выполнения обновлений.

• И также, как я уже упоминал, полезно взять и загруженный cf-ник тут же выгрузить обратно – это позволяет еще раз себя проверить, увидеть, какие там появились артефакты, и закоммитить. Поэтому обычно после коммита слияния у меня еще следует коммит с исправлениями артефактов. И в этот же момент мы еще выгружаем правильный файл поставки. Слить его мы его не можем, так как он имеет не совсем текстовый формат, поэтому мы его просто в момент обновления забираем из новой конфигурации поставщика как он есть, а после загрузки cf-ника мы выгружаем результат и получаем правильный файл поставки.

Про что мы обычно забываем в этом процессе?

• Дополнительные отчеты и обработки, которые лежат в соответствующем справочнике. Мы вроде все обновили, накатили, но потом нам прилетает, что ничего не работает. Здесь рекомендация – храните их и дорабатывайте в Git. Это позволяет, как минимум, о них помнить.

• Опять же, в Git имеет смысл хранить тесты.

• Также забываем о правилах обмена. Рекомендация та же – храните в Git. Здесь вам может помочь разработка GitRules от Олега Тымко. Она позволяет огромный XML-файл правил «Конвертации данных 2» разложить по папкам на отдельные куски кода и комфортно смотреть, что там изменилось, удобно дорабатывать и пр.

• Я уже говорил, что про расширения мы говорить не будем. Тем не менее, их, как минимум, нужно проверить на применимость. Хорошо, что платформа предоставляет нам инструменты для этого, а также мы можем использовать тесты.

• Часто забываем загрузить конфигурацию поставщика. Прежде чем собирать файл поставки для продуктива, не забудьте выполнить стандартное обновление конфигурации поставщика – просто чтобы она попала в базу. Никаких флажков тут уже изменять не нужно – просто запускаем обновление, нажимаем ОК, после чего уже накатываем нашу подготовленную обновленную конфигурацию.