Как понять, что мы изменили в конфигурации 1С:Предприятие?

Программист 1С v8.3 (Управляемые формы) IT и автоматизация бизнеса
← К списку

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

Современный подход: 1C:Enterprise Development Tools (EDT) и Git

Начнем с наиболее современного и рекомендуемого подхода, который обеспечивает максимальный контроль над изменениями — это использование среды разработки 1C:Enterprise Development Tools (EDT) в связке с системой контроля версий Git.

Принципы работы EDT и Git

1С:EDT представляет собой полноценную интегрированную среду разработки, которая кардинально меняет подход к работе с конфигурацией 1С. В отличие от Конфигуратора, где конфигурация хранится в бинарном виде в базе данных, EDT рассматривает каждый объект метаданных (справочник, документ, отчет, модуль и т.д.) как отдельный файл или набор файлов. Такой подход делает EDT идеально совместимым с системами контроля версий, такими как Git.

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

Процесс работы с изменениями в EDT и Git

  1. Разработка: Мы вносим изменения в объекты конфигурации прямо в EDT. По мере работы EDT автоматически сохраняет изменения в файлах проекта.

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

  3. Фиксация изменений (Коммит): Когда мы завершили логическую часть работы (например, реализовали новую функцию или исправили ошибку), мы фиксируем изменения в Git. Этот процесс включает следующие шаги:

    • Добавление измененных файлов в индекс (staging): Мы выбираем, какие именно изменения хотим включить в текущий коммит.
    • Написание описательного сообщения коммита: Это один из ключевых моментов. Мы настоятельно рекомендуем использовать четкие и информативные сообщения. Хорошая практика — начинать с краткого заголовка (не более 50 символов) в первой строке, затем оставлять пустую строку, а далее подробно описывать суть изменений, их причины и особенности. Можем также добавлять теги или ссылки на задачи в трекере.
    • Фиксация (commit): После написания сообщения мы фиксируем изменения, создавая новую точку в истории версий.
  4. Работа с бинарными файлами: Объекты конфигурации 1С часто содержат большие бинарные данные (например, макеты, формы). Для эффективной работы с ними в Git рекомендуется использовать расширение Git LFS (Large File Storage), которое поддерживается EDT. Оно позволяет хранить большие файлы вне основного репозитория, оставляя в Git только ссылки на них.

Общие рекомендации по контролю версий с Git

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

Классические методы: Встроенные возможности Конфигуратора 1С

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

Метод 1: Сравнение конфигурации с файлом (.cf)

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

  1. Сохраняем исходное состояние: Перед началом работы или внесением значительных изменений, мы сохраняем текущую конфигурацию в файл. Для этого в Конфигураторе переходим в меню Конфигурация - Сохранить конфигурацию в файл.... Допустим, мы назовем этот файл КонфигурацияДоРаботы.cf.

  2. Вносим изменения: Мы выполняем необходимые доработки в конфигурации.

  3. Сравниваем изменения: После завершения работы мы можем сравнить текущую конфигурацию с сохраненным файлом. Для этого в Конфигураторе переходим в меню Конфигурация - Сравнить, объединить с конфигурацией из файла... и выбираем наш файл КонфигурацияДоРаботы.cf.

  4. Анализируем отчет: Откроется окно сравнения и объединения, где мы сможем увидеть все различия между текущей конфигурацией и конфигурацией из файла. Мы можем фильтровать результаты, просматривать изменения в свойствах объектов, реквизитах, табличных частях, формах и текстах модулей.

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

Метод 2: Использование хранилища конфигурации 1С

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

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

  2. Подключаем базу разработки: Мы подключаем нашу информационную базу разработки к созданному локальному хранилищу.

  3. Создаем "общую" базу для общего хранилища: Дополнительно создаем еще одну информационную базу (без данных), которую подключаем к общему хранилищу конфигурации, используемому всей командой. Это будет наша "чистая" база для актуализации и сравнения.

  4. Актуализируем локальное хранилище: Перед началом разработки мы получаем актуальную версию конфигурации из общего хранилища в наше локальное хранилище.

  5. Разрабатываем: Мы вносим свои доработки в конфигурацию в нашей базе разработки.

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

  7. Заливаем свои доработки в локальное хранилище: Мы помещаем свои изменения из базы разработки в наше локальное хранилище (пока не помещая их в общее хранилище).

  8. Сравниваем конфигурации: Теперь у нас есть две актуальные базы, каждая подключена к своему хранилищу (локальному и общему). Мы выполняем сравнение конфигурации базы данных с конфигурацией хранилища в обеих базах. Это даст нам два полных отчета о сравнении.

    • В нашей базе разработки: Конфигурация базы данных vs Конфигурация хранилища (содержит наши доработки).
    • В "общей" базе: Конфигурация базы данных vs Конфигурация хранилища (содержит актуальную общую конфигурацию).
  9. Анализируем отчеты: Мы сравниваем эти два отчета о сравнении между собой с помощью любого удобного инструмента для сравнения текстов (например, стандартный Блокнот, Notepad++, или специализированные diff-утилиты). Это позволяет нам увидеть чистые изменения, которые мы внесли, относительно актуальной общей конфигурации.

Общие возможности сравнения и объединения в Конфигураторе

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

Специализированные инструменты и рекомендации при работе с поддержкой

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

Специализированные инструменты для обновления

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

Работа с поддержкой конфигурации

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

  1. Три конфигурации: Платформа автоматически анализирует изменения, учитывая три конфигурации:

    • Текущая конфигурация клиента: Наша измененная конфигурация.
    • Предыдущая конфигурация поставщика: Версия конфигурации поставщика, на основе которой мы делали свои доработки (хранится в нашей конфигурации).
    • Новая конфигурация поставщика: Обновленная версия конфигурации от поставщика.
  2. Автоматический анализ и правила: Платформа автоматически анализирует изменения и назначает правила обновления. Однако сложные сценарии (например, когда и поставщик, и мы изменили один и тот же объект или процедуру) требуют ручного вмешательства для разрешения конфликтов.

  3. Рекомендации:

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

Отслеживание изменений с помощью комментариев в коде

Помимо инструментальных средств, существует простая, но эффективная практика, которая помогает нам ориентироваться в собственных изменениях — это комментирование кода.

Как эффективно комментировать изменения

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

  1. Используем шаблоны текста: Для удобства мы можем настроить "Шаблоны текста" в Конфигураторе через меню Сервис - Шаблоны текста - Настроить.... Это позволит нам быстро вставлять маркеры комментариев с помощью автозамены (например, по комбинации CTRL+Q).

  2. Примеры маркеров: Мы можем использовать следующие маркеры:

    • //+ для начала блока наших изменений.
    • //- для конца блока наших изменений.

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

Пример использования комментариев


//+ Изменение от 15.03.2024 (Иванов И.И.): Добавлена проверка прав перед записью документа
Если Не ПравоДоступа("Изменение", Метаданные.Документы.РеализацияТоваровУслуг) Тогда
    Отказ = Истина;
    Сообщить("Недостаточно прав для изменения документа Реализация товаров и услуг.");
КонецЕсли;
//- Изменение от 15.03.2024

//+ Изменение от 16.03.2024 (Петров П.П.): Оптимизация запроса получения остатков
Запрос = Новый Запрос;
Запрос.Текст = "ВЫБРАТЬ
               |    ОстаткиТоваровОстатки.Номенклатура,
               |    ОстаткиТоваровОстатки.КоличествоОстаток
               |ИЗ
               |    РегистрНакопления.ОстаткиТоваров.Остатки КАК ОстаткиТоваровОстатки
               |ГДЕ
               |    ОстаткиТоваровОстатки.Склад = &Склад";
Запрос.УстановитьПараметр("Склад", СкладОтгрузки);
РезультатЗапроса = Запрос.Выполнить().Выгрузить();
//- Изменение от 16.03.2024

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

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

← К списку