1С без драмы: когда обновления работают сами

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

Но существует способ сделать процесс обновления простым и безопасным, что помогает избавиться от стресса и лишних хлопот. В своей статье я покажу, как это сделать.

Проблемы ручного обновления и их последствия

Что мешает нам спокойно работать и обновлять систему?

• Разработчикам приходится тратить много времени на ручное обновление и архивирование.

• Использование административных прав создает угрозу взлома и утечки данных.

• Возникает выгорание сотрудников, увеличивается штат техподдержки.

Все это снижает эффективность и повышает затраты бизнеса.

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

Постоянные ошибки при обновлении и необходимость увеличивать штат – неизбежные последствия традиционного подхода. В итоге система начинает тормозить развитие бизнеса, увеличивает расходы и снижает производительность команды.

Инструмент «Обновлятор» и его возможности

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

Поэтому я предлагаю переход на автоматическое обновление.

Существует инструмент «Обновлятор». Первая версия вышла в 2015 году. Вот что он умеет:

• Проверяет наличие свежих релизов и версий патчей.

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

• Обновляет систему – неожиданно, правда? Устанавливает релиз в удобное время и при этом не заставляет разработчиков задерживаться после работы или релизить в пятницу. Выпускать релизы в пятницу – действительно плохая практика. Следующий день недели – нерабочий (при стандартной пятидневке), и если что-то пойдет не так, то придется работать в выходные. Но при ручном деплое по-другому не получается – в любом случае нужно выгонять пользователей из баз и блокировать вход. В этом случае либо страдает бизнес (останавливается на время обновления), либо разработчики/администраторы остаются в пятницу (конец рабочей недели) после работы и выполняют обновление.

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

Если раскрыть его потенциал полностью, «Обновлятор 1С» фактически становится администратором системы.

Интерфейс программы и регламентные задания

Простота интерфейса облегчает работу с инструментом. Мы быстро выбираем нужную базу, получаем подробную информацию и настраиваем автоматическое выполнение.

На рабочем столе собрана самая необходимая информация. Это древовидная структура конфигураций с версиями, описанием и расположением. Слева находится панель управления этой структурой. Список конфигураций берется из окна запуска 1С. Наверху расположены вкладки с настройками программы.

Расписание заданий «Обновлятора» – это мозг инструмента. На изображении видно, что каждое задание выполняет конкретный функционал.

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

Пример из практики: У меня каждое утро и каждый вечер выполняется проверка обновлений на сайте вендора. Если новых релизов нет – устанавливаются патчи. Это очень удобно: не приходится искать их вручную.

Процесс автоматического обновления базы

Рассмотрим автоматизацию установки релиза вендора и доставку собственных изменений в рабочую базу.

Процесс обновления базы состоит из нескольких этапов:

1. Сначала планируется задание и выполняется проверка наличия нового релиза.

2. Затем выполняется подготовка merge-файла для объединения и переноса метаданных.

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

4. Далее проводится проверка технической совместимости и применимости расширений после обновления.

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

6. И последняя стадия – финальное обновление рабочей базы.

Обратите внимание: Merge-файл автоматизирует типовые сценарии объединения, но при сложных структурных изменениях (перемещение реквизитов, изменение типов) может потребоваться ручная доработка. Это штатная ситуация, а не ошибка инструмента.

Эти шаги позволяют избежать большинства распространенных ошибок и значительно упрощают работу ИТ-команды.

Работа с доработанными конфигурациями и merge-файлами

Мы можем полностью автоматизировать доставку релизов: проверку новых объектов хранилища, выполнение резервных копий и плановое обновление рабочих баз. Например, условно раз в две недели, в четверг.

Таким образом, большая часть работы выполняется машиной, сокращая количество человеческих ресурсов, необходимых для обслуживания системы.

Отдельной болью становится обновление доработанных конфигураций. Редко кто использует полностью типовые решения. Но и с этим мы можем справиться достаточно легко.

На изображении вы видите окно с настройками обновления, открытое из свойств базы. Здесь есть параметр «обновлять с приоритетом новой конфигурации». В обычном случае при этой включенной настройке конфигурация будет заменена.

Однако ниже есть ссылка на настройки объединения. Это и есть тот самый merge-файл. При обновлении программа считывает настройки из него и применяет их так, как будто мы сами выполняем сравнение и объединение в конфигураторе.

Merge-файл показан на изображении. Это полноценный merge-файл, который использует «Обновлятор». Чтобы его создать, нужно вручную вызвать диалог сравнения и объединения из конфигуратора (например, из тестовой базы), отметить в нем нужные изменения и действия и сохранить результат в XML-файл. Затем открыть этот файл редактором и удалить все, кроме блока Objects. После этого изменения сохраняются, а файл загружается в настройки обновления в свойствах базы, которые были показаны на предыдущем изображении.

Совет: Можно либо скопировать блок <Objects> непосредственно в настройки, либо указать путь к отредактированному XML-файлу (удобно, если файл лежит в сетевом каталоге).

Трехуровневый контур автоматизации разработки

Теперь давайте расширим возможности и рассмотрим более амбициозную схему – трехуровневый контур автоматизации разработки и доставки изменений под управлением только «Обновлятора».

На схеме представлены три хранилища: dev, test и preprod.

Разработчики помещают свои изменения в dev-хранилище и тестируют их на тестовой базе. После этого «Обновлятор» выгружает файл из хранилища в отдельный каталог.

Далее он объединяет конфигурацию тестового хранилища с этим выгруженным файлом. Для этого он подключается к базе preprod_db, чтобы выполнить непосредственное подключение к хранилищу.

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

К preprod-хранилищу подключена рабочая база. И на последнем этапе, когда тестирование завершено, хранилище preprod также объединяется с файлом, который был ранее выгружен из первого хранилища.

Такая схема используется потому, что вся разработка ведется только на уровне dev-storage. Все остальные базы и хранилища предназначены для тестирования.

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

Раз вся рутинная работа выполняется автоматически, отпадает необходимость предоставлять разработчикам полные административные права в рабочей базе. Можно оставить им только права просмотра в режиме предприятия. Доступ к конфигуратору становится избыточным, потому что «Обновлятор» выполняет всю необходимую работу самостоятельно.

Автоматизация настройки групповой разработки

Настройку групповой разработки тоже можно практически полностью автоматизировать.

Первый шаг – бэкап рабочей базы. Это выполняется автоматически: либо по расписанию, либо по кнопке, по требованию.

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

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

Чтобы захватывать объекты и редактировать их, блокировку нужно снять. Это также можно выполнить скриптом и создать регламентное задание, чтобы операция выполнялась по расписанию.

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

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

Таким образом, мы автоматизируем процесс практически полностью.

Когда такая схема может пригодиться? Например, в понедельник к вам в команду выходит новый разработчик. И ему нужно подготовить не только физическое рабочее место, но и собственный workflow.

В этом случае в пятницу вы просто меняете параметры в скриптах под нового сотрудника: настройки, логин, пароли, расположение баз. На все это уходит примерно десять минут. После этого настраиваете расписание – условно на субботу или воскресенье, когда сервера наименее загружены. «Обновлятор» выполняет все необходимые действия, вам приходит уведомление о том, что все завершено, и в понедельник вы вместе с новым коллегой занимаетесь работой, а не настройкой окружения.

Скрипты, шифрование данных и репозиторий

«Обновлятор» позволяет писать скрипты прямо в собственном интерфейсе в трех вариантах: для командной строки, OneScript и SQL.

Текст скрипта в «Обновляторе» выглядит примерно так, как показано на изображении. Здесь используется команда самого «Обновлятора». Указывается путь к хранилищу, логины, пароли, название расширения – так, как оно называется в конфигураторе, – и несколько дополнительных параметров.

После этого скрипт можно сохранить в файл формата cmd. При этом в самом cmd-файле вы не увидите ни логинов, ни паролей. Хотя они необходимы для подключения к базе и в скрипте используются, хранятся они внутри «Обновлятора», доступ к которому есть только у сотрудника, который им управляет.

Вместе с cmd-файлом выгружается текстовый файл со скриптом. Но он зашифрован. Даже если открыть его в блокноте, узнать логин, пароль или другие параметры подключения невозможно. При этом в самом интерфейсе «Обновлятора» все эти данные отображаются и доступны для работы.

Эти и другие скрипты вы можете найти в моем репозитории на GitHub https://github.com/VladimirProgrammist1C/scripts-for-the-Updater. Репозиторий открыт – форкайте, экспериментируйте, оптимизируйте.

Вопросы безопасности администрирования

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

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

Этот функционал, конечно, относится к привилегированным. Но при этом мы будем соблюдать требования кибербезопасности. Поэтому создадим для «Обновлятора» двух пользователей.

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

Второй – пользователь СУБД для клиент-серверных баз. Ему требуется доступ только для выполнения архивации, восстановления и создания новых информационных баз. Широкие административные полномочия здесь не нужны, поэтому мы не используем основного суперпользователя СУБД.

Эта ссылка https://github.com/VladimirProgrammist1C/Updater-User-Settings ведет в репозиторий на GitHub с инструкцией по созданию таких пользователей. Инструкция получилась довольно объемной, поэтому я вынес ее отдельно.

Итоги

Подводя итоги, можно сказать, что инструмент «Обновлятор» помогает автоматизировать ряд таких рутинных задач, как:

• Установка обновлений на базу под любую из двух популярных СУБД.

• Обновление базы из хранилища с сохранением версионирования.

• Обновление доработанных конфигураций.

Кроме того, инструмент позволяет полностью автоматизировать трехуровневый контур разработки, автоматизировать групповую разработку с использованием хранилища и обеспечить безопасную работу с системой.

*************

Статья написана по итогам доклада (видео), прочитанного на конференции INFOSTART TECH EVENT.