Введение
Одна из важнейших задач, с которой встречаются программисты 1С - обновление конфигураций. Во многих фирмах-франчах знакомство начинающего разработчика/консультанта/сервис-инженера с 1С начинается с обновления программных продуктов. Как правило, новичкам дают задачи по обновлению типовых конфигураций, либо платформ 1С. Обычно, обновление типовых решений не доставляет много хлопот - скачал апдейтник, прокликал несколько раз "далее" - "далее" - "ок" и все готово. Практически тоже самое можно сказать и про обновление платформы - скачал актуальную версию, установил и готово - можно работать. Бывают, конечно, особенности, связанные с нелицензионным ПО, старым железом, однако это все решается на уровне системного администратора, либо сервис-инженера.
Самое интересное начинается при обновлении нетиповой конфигурации. Особенно проблематично обновлять базу, которую не приходилось дорабатывать лично...
Итак, в текущей заметке будет продемонстрировано несколько навыков и инструментов по обновлению нетиповых конфигураций.
Всё описанное тестировалось на платформе 8.3.18.1289 и более поздних версиях.
Доработка типовых конфигураций
В дальнейшем я буду рассматривать некоторые внешние программы для сравнения/объединения программного кода. Для оптимального использования таких инструментов, необходимо поддерживать обновляемую конфигурацию в соответствующем виде - производить доработки в строго определенном формате и использовать один шаблон. Речь пойдет, конечно же, о расширениях.
Всем известно, что в платформе 8.3 появился такой удобный и разнообразный инструмент - расширение конфигурации. Здесь я не буду вдаваться в подробности устройства данного механизма, лишь покажу, как его использовать для дальнейшего без проблемного обновления базы.
Очевидно, что самый сложный этап в обновлении конфигурации - сравнение программных модулей и анализ произведенных доработок. Поэтому использование расширений очевидно - необходимо по максимуму перенести программный код из основной конфигурации в конфигурацию расширений. Для этого существует несколько аннотаций: &Перед, &После, &Вместо и &Вместо (с контролем). В рамках нашей концепции рекомендуется использовать лишь две из них: &Перед и &После. Переносимый в расширения код должен компилироваться и правильно отрабатывать после каждого обновления. Код прописанный До или После типового метода обычно не подвергается критическим ошибкам - он носит, по большей части, дополняющий характер. Например, это может быть добавление своих реквизитов на форму в процедуре "ПриСозданииНаСервере" (Рисунок 1)
Рисунок 1 - Программное добавление реквизитов и элементов на форму
Таким образом возможно максимально разгрузить доработанные модули в основной конфигурации. Использование аннотаций "&Вместо" считается не сильно эффективным, так как при малейшем изменении модуля поставщиком, расширение придется переписывать из-за несоответствия расширяемой процедуры. Инъекции кода и программное переопределение типовой логики лучше производить в основной конфигурации - далее мы увидим, почему так удобнее.
Следующее - доработка форм. Любое редактирование управляемой формы, опять-таки, строго рекомендуется выполнять программно. Во-первых, при ручном редактировании формы в основной конфигурации (используя редактор форм) все настройки будут успешно стерты и по умолчанию взяты из новой конфигурации поставщика (из нового релиза). Производить редактирование формы в расширении тоже не самая удачная идея - теряется визуальное отличие между типовыми и нетиповыми доработками. Поэтому при настройке форм, пользуемся схемой, описанной выше. Все, что можно поместить в расширение по аннотации &Перед, &После - переносим, все остальное (программное изменение логики формы, инъекции кода) оставляем в основной конфигурации.
Последнее - добавление новых объектов, реквизитов. Любое добавление новых объектов необходимо производить только в основной конфигурации. Объясняется такое решение несколькими причинами. Во-первых, при добавлении новых справочников, планов видов характеристик, документов - любых ссылочных объектов, не исключён шанс, что в будущем они могут участвовать в качестве типов реквизитов. Назначить ссылочный тип из расширения объекту основной конфигурации не получится, поэтому целесообразно не создавать новые объекты в расширении. Второе - невозможно использовать конструктор запросов и контекстную подсказку одновременно и для объектов расширения и для объектов основной конфигурации. Для всех объектов конструктор запросов доступен только в пользовательском режиме. И, самое главное для нас - объекты, добавленные в основную конфигурацию не нужно анализировать при обновлении базы. Они не удаляются и не модифицируются. Однако стоит понимать, что связи, используемые в типовых объектах с нетиповыми (назначение типовому регистру нетиповой регистратор, настройка владельца, изменение состава определяемого типа) при накатывании нового релиза - затрутся. Их придется анализировать вручную.
Встроенные средства сравнения/объединения
Обзорно пройдемся по основным этапам сравнения/объединения платформы 1С 8.3. При возникновении окна сравнения, мы должны проанализировать объекты, подвергшиеся изменениям. Устанавливаем фильтр "Показывать только дважды измененные свойства" для понимания, в какие фрагменты кода были внесены изменения нами (сторонними разработчиками) и поставщиком. Далее, можем воспользоваться настройкой объединения модулей, кликнув по шестерёнке (Рисунок 2)
Рисунок 2 - Окно сравнения конфигураций
Перейдя к настройке объединения модулей, видим окно двустороннего сравнения модулей (Рисунок 3)
Рисунок 3 - Штатное двустороннее сравнение модулей
В целом, инструмент помогает произвести анализ выполненных доработок, переходя к каждому измененному методу данного модуля. Слева мы видим дорабатываемую нами конфигурацию (Основная конфигурация), справа - конфигурацию поставщика (новый релиз). Если наша база не сильно доработана, и все программные изменения находятся в расширениях, то такой возможности сравнения будет достаточно для обновления почти типовой конфигурации.
Но давайте рассмотрим недостатки штатного механизма сравнения. Первое - ручное исправление коллизий. Инструмент не может автоматически анализировать доработки. Даже добавленный "сбоку" код должен обрабатываться программистом. Конечно, есть возможность выбора режима обновления - "Объединить с приоритетом основной конфигурации", либо "с приоритетом новой конфигурации поставщика", однако данная возможность не совсем удобна в использовании, к тому же, оставляет лишние комментарии только сбивающие с толку в дальнейшем (хотя, возможно, это дело привычки). Второе - необходимо переключаться на новую процедуру(функцию) после каждой обработки текущей. Отнимает много времени анализ больших и длинных методов, особенно, когда правки в них были не критические. Третье, и самое важное - отсутствие трехстороннего сравнения/объединения. Часто бывает просто необходимо посмотреть на старую конфигурацию поставщика. Необходимо проанализировать типовую старую логику работы метода, сравнить ее с текущей (доработанной), либо сравнить старую типовую логику работы механизма с новой логикой (появившейся в новом релизе). Такая возможность отсутствует в штатных средствах сравнения.
Давайте обзорно рассмотрим некоторые сторонние инструменты сравнения фрагментов кода, используемые при обновлениях 1С.
Perforce P4Merge
Одна из сторонних программ сравнения/объединения, которую считаю дольно удачной, при обновлении нетиповой конфигурации - Perforce P4Merge. Вообще, как можно заметить, платформа предлагает некоторые сторонние программы (Сервис -> Параметры -> Сравнение/Объединение) (Рисунок 4)
Рисунок 4 - Выбор внешней программы
Из всех указанных утилит, больше всего мне приглянулась Perforce P4Merge. Её достоинства заключаются в следующем:
- Удобный и наглядный интерфейс
- Возможность автоматического поиска коллизий
- Трехстороннее сравнение
Для начала покажу, как добавить внешний инструмент сравнения. Скачиваем и устанавливаем Perforce P4Merge (Гуглится довольно быстро). В окне выбора внешней программы позиционируемся на Perforce P4Merge и нажимаем "Изменить" (Рисунок 4). Далее выбираем исполняемый файл с соответствующим названием (Рисунок 5)
Рисунок 5 - Выбор p4merge
Теперь остается в окне "Режим объединения и порядок подчиненных объектов" выбрать Perforce P4Merge и применить настройки.
Далее, в окне сравнения/объединения у нас появится возможность "Объединить с помощью внешней программы" (Рисунок 6)
Рисунок 6 - Объединение с помощью внешней программы
Кратко покажу работу с Perforce P4Merge. После того, как мы нажмем на "шестерёнку" - откроется окно трехстороннего сравнения (Рисунок 7)
Рисунок 7 - Интерфейс объединения "Perforce P4Merge"
В целом интерфейс интуитивно понятен. Первое окно - Основная конфигурация, второе - Старая конфигурация поставщика(до обновления), и третье - Новая конфигурация поставщика (накатываемый релиз). Программа выделяет красной рамкой только те части кода, которые различаются во всех трёх окнах. Так, например, в старой конфигурации в запросе присутствовал фрагмент внутреннего соединения с таблицей "ВТСотрудникиПериодДанных" по двум условиям. В основной конфигурации видно, что второе условие было закомментировано. В новой же конфигурации поставщика вообще отсутствует данное соединение, поэтому конфликт и выделен - решение по объединению должен принимать разработчик. Все остальные моменты практически обрабатываются на автомате. Если изменения есть только в новой конфигурации поставщика, то они и будут применены. Если изменения есть только в основной конфигурации (инъекции кода), то они будут учтены системой. И если фрагмент кода будет изменен в основной конфе, старая и новая конфигурации поставщика совпадают, то будут вынесены правки из основной конфигурации. Вверху, по красным стрелочкам, удобно обходить все конфликты и обрабатывать их используя соответствующие пиктограммы (Квадрат, Сектор, Круг). Кликая по пиктограммам удобно выбирать фрагмент вставки изменения - из основной, из старой, из новой, либо сразу из всех конфигураций (все три фигуры подсвечены).
Программа поможет сократить время при анализе километровых модулей программного кода, а также эффективно справится с объединением доработок.
Kdiff3
Помимо Perforce P4Merge существует ещё ряд внешних программ, имеющих удобный интерфейс трёхстороннего сравнения/объединения, например, Kdiff3. Данный инструмент скачивается и подключается аналогично вышеописанному. Кратко разберем интерфейс Kdiff3.
При открытии окна сравнения конфигураций, выбираем пункт объединения с помощью внешней программы. Интерфейс в целом схож с Perforce P4Merge, однако есть ряд своих особенностей (Рисунок 8)
Рисунок 8 - Интерфейс объединения "Kdiff3"
Слева находится старая конфигурация поставщика, затем основная конфигурация и справа - новая конфигурация поставщика. Разумеется, порядок следования окон можно изменить, на рисунке представлен вид по умолчанию. Программа позволяет перемещаться в модулях по проблемным фрагментам кода - по частям, измененным в основной конфигурации и в новой конфигурации поставщика. Для выбора объединения вверху окна используются кнопки "A" "B" и "C". На этом принципиальные отличия Kdiff3 от Perforce P4Merge по большей части заканчиваются. По своему опыту могу сказать, что удобнее и нагляднее работать с Perforce P4Merge, однако тут уж дело вкуса.
Заключение
В текущей публикации были рассмотрены некоторые этапы по доработке обновляемых конфигураций, а также показаны внешние инструменты трехстороннего сравнения/объединения. Существует множество других программ, позволяющих корректно сравнивать модули при обновлении, но здесь я решил рассмотреть две наиболее часто используемых. Удобство описанных приложений объясняется в простоте их установки и применения - наглядном анализе доработок, используя трехстороннее сравнение. На компьютер, где находится база возможно установить сразу несколько внешних программ и использовать их поочередно, переключаясь по шестерёнке в окне объединения конфигураций (Рисунок 6).
Посыл заметки - применение расширений, для уменьшения разгрузки программных модулей и использование внешних программных средств, для более удобного сравнения/объединения.
