← На главную

При развертывании и активной доработке нетиповой конфигурации 1С (особенно на базе БСП) одним из ключевых вопросов становится организация процесса обновления рабочей базы. Частота изменений, потребность в оперативности и необходимость минимизации рисков требуют продуманного подхода. Давайте вместе рассмотрим различные варианты, их преимущества и недостатки, а также современные практики, которые помогут вам оптимизировать этот процесс.

Предположим, что вы, как и автор темы, работаете с тремя типами баз:

1. Разработческие базы: Несколько легких баз без данных, связанных хранилищем конфигурации.
2. Тестовая база: Для объединения всех изменений разработчиков и их последующего тестирования.
3. Рабочая база: Непосредственно продуктивная база предприятия.

Обновления в таких условиях, особенно если они частые (раз в 5-7 дней) и конфигурация будет активно дорабатываться, требуют взвешенного решения. Рассмотрим два основных варианта и дополнительные рекомендации.

Вариант 1: Обновление рабочей базы напрямую из хранилища конфигурации

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

Преимущества:

1. Высокая скорость обновлений: Это одно из главных преимуществ данного метода. Процесс получения изменений из хранилища и их применения в базу происходит значительно быстрее по сравнению с формированием и накатыванием поставок.
2. Возможность выборочного получения объектов: Если вам нужно внести только точечные изменения или исправления, вы можете получить из хранилища не всю конфигурацию, а лишь отдельные объекты метаданных. Это может быть полезно для оперативного устранения критических ошибок.
3. История изменений: Хранилище 1С ведет историю всех изменений. Это позволяет отслеживать, кто и когда внес определенные изменения, и при необходимости сравнивать текущую версию объекта с предыдущими.

Недостатки:

1. Риск попадания недоделанного или нестабильного кода: Это главный и самый серьезный минус. Если в хранилище попадает код, который еще не прошел полное тестирование, или содержит ошибки, он может быть случайно или намеренно получен в рабочую базу, что приведет к сбоям в работе.
2. Ограниченные возможности глобального отката: Хотя хранилище позволяет сравнивать версии и точечно возвращать код, полноценный глобальный откат конфигурации со всеми изменениями метаданных (например, удалением новых объектов) может быть сложным и трудоемким, часто сопровождаемым "мутью" и непредсказуемым поведением. Обычно это сводится к ручному восстановлению кода из предыдущих версий.
3. Отсутствие стандартного окна сравнения/объединения: При простом получении из хранилища (Конфигурация -> Обновить конфигурацию базы данных -> Обновить конфигурацию базы данных) окно сравнения и объединения, привычное при обновлениях от поставщика, не появится, если в рабочей базе нет локальных изменений. Это означает, что вы получаете "как есть", без дополнительного контроля.

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

Вариант 2: Обновление рабочей базы через формирование поставки

Этот подход предполагает, что для каждого релиза (порции изменений) вы меняете версию конфигурации, в тестовой базе формируете файл поставки (.cfu или .cf), а затем уже эту поставку накатываете на рабочую базу.

Преимущества:

1. Контролируемый процесс обновления: Поставка обычно формируется из уже протестированной и стабильной версии конфигурации. Это значительно снижает риск попадания недоделанного или ошибочного кода в продуктивную среду.
2. Наличие окна сравнения и объединения: При накатывании поставки (особенно если это файл .cf или .cfu, который отличается от текущей конфигурации в базе) всегда появляется окно сравнения и объединения. Это дает администратору или программисту полный контроль над всеми вносимыми изменениями, позволяя тщательно проанализировать их, выбрать, что принимать, а что нет, и настроить параметры объединения, как при обновлении типовых конфигураций. Это позволяет избежать случайных ошибок и гарантирует, что в базу попадет только то, что необходимо.
3. Изоляция от текущей разработки: Поставка представляет собой "снимок" конфигурации на определенный момент времени. Это означает, что даже если разработчики продолжают активно работать с хранилищем и вносить новые изменения, сформированная поставка остается стабильной версией, не зависящей от дальнейшей работы.

Недостатки:

1. Длительность и трудоемкость процесса: Формирование поставки, смена версий, а затем ее накатывание – это значительно более долгий и трудоемкий процесс по сравнению с получением из хранилища. Это может быть критично при частых обновлениях.
2. Необходимость хранения предыдущих версий: Для возможности отката к предыдущей версии вам придется отдельно хранить файлы поставок или конфигураций предыдущих релизов.
3. Отсутствие гибкости в выборочном обновлении: Поставка – это всегда целостный пакет изменений. Вы не можете выборочно применить только часть объектов из поставки (хотя в окне сравнения вы можете выборочно отключать изменения, но это не то же самое, что "получить объект из хранилища").

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

Дополнительные рекомендации и современные практики для оптимизации процесса

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

1. Использование расширений конфигурации вместо прямых доработок

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

   • Минимизация конфликтов: Расширения позволяют вносить изменения или добавлять новый функционал, не снимая конфигурацию с поддержки поставщика и не изменяя ее непосредственно. Это значительно упрощает последующие обновления самой типовой части конфигурации, так как уменьшает количество конфликтов при сравнении и объединении.
   • Модульность: Доработки, оформленные в виде расширений, становятся более модульными и независимыми от основной конфигурации.
   • Гибкость: Внешние доработки, такие как печатные формы и отчеты, также могут быть реализованы без изменения основной конфигурации, что повышает их переносимость и управляемость.

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

2. Использование внешних систем контроля версий (СКВ) типа Git

   Хотя хранилище 1С предоставляет базовые функции контроля версий, для более гибкой групповой разработки, детального отслеживания изменений и возможности отката, особенно при использовании среды разработки 1C:Enterprise Development Tools (EDT), мы советуем использовать Git. Рассмотрим его преимущества:

   • Детальная история изменений: Git предоставляет более продвинутые функции по сравнению со стандартным хранилищем 1С, включая удобную историю изменений, возможность сравнения любых версий и ветвление.
   • Гибкая работа с ветками: Вы можете создавать отдельные ветки для каждой задачи, проводить слияния, решать конфликты и возвращаться к предыдущим состояниям с гораздо большей гибкостью.
   • Интеграция с 1C:EDT: Если вы используете 1C:EDT, она имеет встроенную поддержку Git, что позволяет работать с этой системой без ограничений, храня конфигурацию в виде файлов.

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

3. Принципы CI/CD (Continuous Integration/Continuous Delivery) для 1С

   Современные практики разработки подразумевают применение CI/CD, что позволяет автоматизировать процессы интеграции изменений, тестирования и доставки обновлений. Для 1С это может включать:

   1. Хранение конфигурации в Git: Как уже обсуждалось, это основа для автоматизации.
   2. Автоматическая проверка изменений: При каждом коммите в Git можно настроить автоматическую проверку кода на соответствие стандартам или на наличие синтаксических ошибок.
   3. Запуск автоматизированных тестов: Для повышения качества релизов и снижения ошибок мы рекомендуем использовать инструменты автоматизированного тестирования, такие как Vanessa-Automation, xUnitFor1C или встроенные механизмы 1С:EDT. Тесты должны запускаться автоматически при каждом изменении.
   4. Автоматическая сборка конфигурации: Можно настроить автоматическую сборку конфигурации из файлов Git в файл .cf или .cfu без ручной работы администратора.
   5. Автоматизированное развертывание обновлений: На финальном этапе можно автоматизировать процесс накатывания обновлений в тестовые и продуктивные базы.

   Внедрение CI/CD для 1С позволяет значительно повысить качество и скорость выпуска релизов, а также обеспечить прозрачность процесса внедрения изменений.

4. Соблюдение стандартов разработки и документирование

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

   • Комментирование изменений: Мы должны комментировать все изменения с указанием автора, даты и сути задачи. Это позволяет быстро понять, зачем был изменен тот или иной участок кода.
   • Уникальные префиксы: Используйте уникальные префиксы для новых объектов метаданных (справочников, документов, регистров, реквизитов, форм и т.д.), чтобы отделять их от типового функционала. Например, АВ_СправочникНовый.
   • Сохранение типового кода: При изменении или удалении типового кода мы должны сохранять его исходный вариант в виде комментария. Это позволяет быстро вернуться к оригиналу при необходимости.

   Такой подход упрощает процесс сравнения и объединения, помогает понять назначение доработок и минимизирует путаницу.

5. Тщательное тестирование

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

6. Резервное копирование

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

7. Автоматизация рутинных операций

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

Заключение и выбор оптимального варианта

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

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

В условиях частых обновлений (раз в 5-7 дней) и сильно доработанной конфигурации, мы рекомендуем не ограничиваться только одним из этих подходов, а рассмотреть внедрение комплексной стратегии:

1. Максимальное использование расширений конфигурации для всех доработок.
2. Переход на внешнюю систему контроля версий типа Git (особенно при работе с 1C:EDT).
3. Постепенное внедрение практик CI/CD для автоматизации тестирования и развертывания.
4. Строгое документирование и стандартизация кода.
5. Обязательное тестирование на тестовой базе с участием пользователей.
6. Регулярное резервное копирование перед каждым обновлением.

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