Обновление рабочей среды 1С

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

Требования к организации среды разработки

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

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

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

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

  1. Все изменения 1С должны вестись в системе контроля версий кода (Хранилище 1С для конфигурации, а если есть внешние обработки, то необходимо дополнительно использовать внешнюю систему контроля версий кода).
  2. Каждое изменение в исходном коде должно быть связано с соответствующей задачей. То есть должна быть внедрена электронная система управления заявками, интегрированная с системами хранения исходного кода.
  3. Для эффективной и оперативной работы необходимы отчеты, в которых объединяется информация из систем контроля версий кода и системы управления заявками.
  4. Должно быть четкое разделение сред разработки, тестирования и рабочей среды.

На приведенной на Рисунке 1 схеме можно увидеть потоки данных и системы, которые использовались для создания структуры управления изменениями в исходном коде 1С, чтобы закрыть требования (1)-(3). Детально по организации работы данной схемы можно прочитать по ссылкам:

Рисунок 1 – Общая схема управления процессов разработки системы 1С

Требование (4) решалось с помощью приведенной на Рисунке 2 схемы организации сред 1С, на которой хотелось бы остановиться подробнее:

Рисунок 2 – Организация сред разработки, тестирования и рабочей среды 1С.

Основные моменты и принципы в организации сред 1С:

  1. Разработчики имеют полные права и могут подключаться к конфигурации только «Сред разработки» и «Тестовых сред для отладки».
  2. «Тестовые среды для отладки» – каждую ночь восстанавливаются с рабочей среды и не подключаются к хранилищу. Используются для решения инцидентов, в которых необходим доступ к текущим рабочим данным для выявления ошибки.
  3. Все изменения в исходный код вносятся через Хранилище 1С, к которому подключены среды разработки и «Основная тестовая среда».
  4. Доступ к обновлению «Основной тестовой среды» имеет выделенный ответственный, который 2-3 раза в день в установленные окна выполняет обновления среды из Хранилища. «Основная тестовая среда» на регулярной основе обновляется рабочими данными один раз в неделю, после чего подключается к хранилищу.
  5. Всё бизнес тестирование проводится исключительно на «Основной тестовой среде».
  6. Рабочая среда не подключена к Хранилищу. Доступ к ней имеет выделенный Менеджер обновлений под специальной учетной записью. Обновление конфигурации производится путем выгрузки данных Хранилища и выполнения процедуры сравнения/объединения для необходимых объектов.

Общий поток изменений исходного кода 1С можно представить следующим образом, изображенным на Рисунке 3:

Рисунок 3 – Схема потоков переноса изменений в исходном коде 1С между средами.

Организация процедуры обновления рабочей среды

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

Рисунок 4 – Общая схема переноса изменений на рабочую 1С.

Действия разработчика:

  1. При успешном завершении тестирования задачи, перевести ее на статус Протестирована. Детально статусы задач описаны в Командная разработка в 1С. Система регистрации запросов. В своей практике для движения задачи по этапам переноса в рабочую среду, я использую отдельный статус, чтобы не смешивать технические значения с бизнес-значениями. Поэтому для протестированных задач появляется поле «Deploy Status (Статус обновления)», которое может принимать следующие значения:
    • 01 – Отправлена на выкладывание – выставляется в момент успешного тестирования задачи разработчиком.
    • 02 – Готова к выкладыванию – задача не заблокирована другими задачами и оформлена в соответствии с процедурой.
    • 03 – Внесена в конфигурацию раб. среды – изменения внесены в конфигурацию рабочей 1С (для внешних обработок выполнен слияние в ветку рабочей среды).
    • 04 – Заблокирована – используется для отображения задач, изменения по которым заблокированы непротестированными задачами.
    • 05 – Перенесена в рабочую среду – задача внедрена в рабочую среду; финальный статус.
  2. Когда разработчик считает, что нет причин, почему задачу нельзя переносить на рабочую среду – он отправляет ее на статус «01 – Отправлена на выкладывание». Так же я использую поле «Deploy Comments (Комментарии обновления)», в которых разработчик может указать важную информацию для Менеджера обновлений.

Действия менеджера обновлений:

  • Возможна процедура, в рамках которой Менеджер обновлений проверяет корректность оформления отправленной на выкладывание задачи: есть ли подтверждение, что она протестирована, корректность статусов и заполненных полей, наличие изменений в коде и т.д. Здесь все зависит от ваших внутренних процедур и регламентов. В случае успешного прохождения проверок, Менеджер обновлений переводит задачу на статус «02 – Готова к выкладыванию». Данный статус нужен, чтобы отделить задачи, отобранные для обновления от задач, который разработчики продолжают отправлять на выкладывание. В результате данного шага у нас появляется предварительный состав релиза обновления системы. Здесь Менеджер обновлений сохраняет конфигурацию 1С из хранилища в отдельный файл.
  • После формирования предварительного перечня задач готовых к выкладыванию, необходимо провести анализ блокировок. Блокировка: это модуль 1С, который изменялся в рамках нескольких задач, часть из которых протестирована и готова к переносу, а по части идет тестирование или разработка. Нам необходимо разделить объекты системы, которые мы можем перенести, взяв последнюю версию, от объектов, которые обновлять нельзя или по которым необходимо выполнить выборочное обновление исходного кода.
    • На этом шаге мы сталкиваемся с насущной необходимостью иметь связь между задачами и изменениями в исходном коде системы. Если такая связь у нас есть, то Менеджеру обновлений на помощь приходит отчет, который наглядно показывает, какие задачи можно переносить в рабочую среду, а по каким необходимо принимать отдельные решения. Пример отчета приведен на Рисунке 5.
    • В примере отчета цветом сразу подсвечиваются задачи в зоне риска и Менеджер обновлений тут же посмотреть по каким именно файлам идет блокировка, какие задачи блокируют файлы и статус этих задач.
    • По результатам анализ данного отчета, Менеджер обновлений по каждой «оранжевой» задаче принимает решение, готов ли он выполнить выборочное обновление соответствующих файлов или задача переводится на статус «04 – Заблокирована» и исключается из релиза.
    • По результатам анализа, формируется окончательный состав релиза обновления системы.
Рисунок 5 – Пример отчета о состоянии задач для переноса в рабочую среду
  • После формирования перечня задач входящих в окончательный релиз, Менеджер обновления выполняет сравнение и объединение конфигурации рабочей среды с выгруженным образом из хранилища 1С. Чтобы проще ориентироваться какие объекты необходимо перенести, целесообразно реализовать следующий отчет, который показывает перечень объектов для объединения – пример отчета на Рис. 6. В отчете объекты группируются, тем самым получается плоский список объектов, по которым необходимо выполнить объединение.
Рисунок 6 – Пример отчета с перечным файлов, для объединения
  • Следующим этапом идет подготовка внешних обработок и разовых скриптов для обновления. Здесь процесс выглядит похожим образом – вначале формируется отчет с перечнем номеров изменений в системе хранения версий, которые нужно слить в основную ветку (Рис. 7). Менеджер обновлений идет по данному списку выполняет слияние изменений (последовательно или одним пакетом).
Рисунок 7 – Пример отчета с номерами изменений в системе хранения версий.
  • Теперь все задачи переводятся на статус «03 – Внесена в конфигурацию раб. среды», таким образом релиз готов к выкладыванию и можно планировать обновление. Считаю данный статус целесообразно вводить, он позволяет добавлять задачи к релизу так как нас есть четкое разграничение задач, по которым изменения в конфигуратор изменений уже внесены, и которые еще надо внести. Я думаю, что у всех возникала ситуация, когда при еженедельном обновлении среды, возникают задачи, которые необходимо включить в релиз, после того как подготовка к обновлению уже началась. Статус «03 – Внесена в конфигурацию раб. среды» дает Менеджеру изменений необходимую гибкость: после того как основной массив задач подготовлен к релизу, можно, если позволяет время прогнать по описанному выше алгоритму дополнительно отправленные на выкладывание задачи.
  • Обновление среды целесообразно выполнять в нерабочее время (рано с утра, в пересменок, в обеденный перерыв), при этом Менеджер обновлений или Первая линия поддержки обязательно делают рассылку на пользователей, где указывают дату, время начала и планируемое время окончания обновления среды, а так же перечень задач, которые будут перенесены на рабочую среду. Обновление конфигуратора выполняется простым применением изменений, а для выполнения обработок и скриптов используется отчет, показанный на Рис. 6, только сформированный для перечня обработок, а не элементов Хранилища.
  • Финальным этапом, после завершения обновления, Менеджер изменений закрывает задачи и присваивает финальный статус Статус обновления – «05 – Перенесена в рабочую среду». Работа по обновлению рабочей среды завершена.

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

  1. Описанная процедура обновления работает как в текущей устаревшей среде разработки 1С (с использованием Хранилища), так же она будет работать и в активно развиваемой оболочке 1С Eclipse. Самые трудоемкие операции в описанной выше процедуре – это выборочное обновление файлов хранилища и процесс объединения конфигурации, при больших релизах. Новые инструменты надеюсь позволят автоматизировать ручные операции, при этом сам подход не должен будет поменяться.
  2. Описанная процедура обеспечивает командную работу в одной конфигурации как локальной группы разработчиков 1С, так и внешних подрядчиков (использовалось в реальных условиях при работе более 20 разработчиков одновременно на каждую конфигурацию).
  3. Теперь мы можем использовать для процесса обновления 1С сотрудников технической поддержки или выделенных сотрудников отдела разработки, а не самих разработчиков, которые могут больше времени уделять собственно своим непосредственным обязанностям. Естественно, при сложных выборочных обновлениях требуется привлечение разработчика, но это скорее исключение, чем правило.
  4. И ключевое, мы существенно приближаем момент стабильной и безошибочной работы информационной системы нашего предприятия. Именно для достижения этой цели данная процедура была разработана и внедрена.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *