Правильне оновлення нетипової (зміненої) конфігурації 1с 7

Що таке нетипова конфігурація 1С?

Що робити?

Для початку, спробуємо сформулювати завдання. Нам потрібно отримати конфігурацію, що складається з нового релізу і всіх наших доробок. Якщо наші доопрацювання суперечать змінам постачальника - прийняти рішення про пріоритет тієї чи іншої доопрацювання. Конфігурація повинна бути робоча і дані, що зберігаються в базі, не повинні бути втрачені.

Увага! Даний посібник призначено тільки для прямих рук! Якщо таких немає - дешевше звернутися до фахівців.

необхідний софт

gcomp для розбирання та збирання файлу MD. Величезна подяка Федору Езееву за таку корисну утиліту.

kdiff3 для об'єднань змін

correct_dlg.pl, що входить в джентельменський набір gcomp

порядок поновлення

Нехай є вихідна робоча конфігурація, в яку розробники не вносили ніяких змін. Назвемо цю конфігурацію А. вона буде служити відправною точкою -Загальна предком в процесі об'єднання. Як знайти цю конфігурацію? Насамперед потрібно визначити, який реліз конфігурації постачальника був базовим.

У робочій базі йдемо в константи - номер релізу і дивимося номер.

Також відразу звернемо увагу, чи були коректно встановлені попередні оновлення (виправлення помилок неписьменних оновлень - тема для окремої статті). Номер релізу в найменуванні і в значенні повинен збігатися.

Значить, у нас є реліз 7.70.040. Нам потрібно оновити його до поточного (7.70.041). Це може бути і на 5-10 релізів пізніше, не обов'язково оновлювати по одному. Але в будь-якому випадку нам потрібно мати обидва релізу постачальника - 040 і 041. Ймовірно, може стати в нагоді добірка всіх МД постачальника, випущених в останні пару років.

Отже, вихідні дані:

Конфігурація 040 - А - папка 040

Конфігурація наша робоча (допрацьована 040) - В - папка 040MY

Конфігурація 041 - З - папка 041

Складемо всі три МД у відповідні папки.

Розібрати А, В і С на текстові файли за допомогою gcomp

На виході отримаємо для кожної конфігурації папки Src.

Обробити скриптом correct_dlg.pl (в складі gcomp) все три версії, якщо розробники мають різні теми робочого столу / різні версії ОС (7 і ХР).

perl correct_dlg.pl -h

покаже опис параметрів

perl correct_dlg.pl -d SRC

виправить всі діалогові форми в каталозі SRC.

І отримаємо приблизно такий результат роботи скрипта:

Завантажити А, В і С в kdiff3, результат об'єднання - R. Виглядає це приблизно так:

Тиснемо Ок і дивимося, як легко kdiff3 обходить поодинокі конфлікти самостійно. Я б не сказав, що моя конфігурація «трохи» змінена: швидше, в ній не залишилося живого місця без доробок.

Але з шістьма-то конфліктами нам треба буде впоратися самостійно.

Файли GUIData і Tagstream вказати з папки В

Виконати напівавтоматичне об'єднання каталогів. Конфлікти вирішуються вручну, але їх зазвичай дуже мало - лише двічі змінені рядки коду / процедури і поїхали діалоги.

Тиснемо F7 і ...

По кожному конфліктного файлу побачимо повідомлення з кількістю вирішених / невирішених конфліктів.

Як відбувається злиття? Про це наочна картинка з конфліктом:

У конфігураціях А і В однакові рядки, а в С постачальник вніс зміни. Ці зміни і переходять в результат, бо два рівні / третій з відмінностями.

Аналогічно, і мої доопрацювання перейдуть в результат:

Тиснемо Ок, перевіряємо зміни і йдемо далі по F7.

А ось і приклад конфлікту:

Відразу зазначу, поле «Є підставою для:» можна сміливо приймати з будь-якого джерела, наприклад, ставити з В. Головне - посилання.

Вельми цікавий об'єкт - ІдентіфікаториКонфігураціі. Я тут завжди вибираю найбільший номер Ід.

Файл Об'ектиМетаданних потрібно об'єднати так, щоб туди увійшли всі нові об'єкти В і С. Пріоритет кодів Ід віддаємо конфігурації В.

Виписати список двічі змінених таблиць (А-В є зміни + А-С теж є зміни), з ними робота окремо. Єдиний геморой на хвилин двадцять.

Зібрати МД з папки R. Усунути дублі числових кодів (МАКСІДОМ + 1), рядки з дублями текстових кодів видалити.

У копії конфігурації a виконати об'єднання з R, після видалити віддалені розробниками об'єкти. Список віддалених об'єктів можна отримати, об'єднавши тому R з a - до звіту (коротко).

Копіюємо простіше простого:

І об'єднуємо штатної 1С також просто:

І відразу тиснемо Ок - адже ми вже об'єднали всі наші доопрацювання.

Я зазвичай роблю синтаксичну перевірку, бо можна трохи помилитися при об'єднанні.

Повідомлення про відсутність помилок не може не радувати:

Вручну об'єднати двічі змінені таблиці, відкривши всі три версії в конфігураторі А. Трохи пізніше розповім, як користуватися 1cv81fv - допоможе з таблицями.

Копію А (вона ж R) перевіряємо на синтаксис / працездатність. Двічі змінені спільно діалоги потрібно підправити, щоб всі елементи були видні і розташовувалися коректно. Перевіряємо помічник поновлення на цій тестовій копії.

Залити через Завантажити змінену в робочу копію.

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

Загалом, разом з написанням цієї статті, на оновлення я витратив дві години. А скільки Ви берете з замовника за дві години такої роботи?

Чого бажано уникнути:

Видалення об'єктів, тому що їх важко шукати при об'єднанні з А: механізм об'єднань 1С не відслідковує перейменувань.

Перейменування об'єктів, так як це буде видалення і створення.

Дуже частого об'єднання в робочу версію, тому що саме об'єднання витратний за часом процес і вимагає зупинки розробки всіх розробників.

Об'єднання змін без достатнього тестування В або С.

Не по зубах? Звертайтеся до нас. Беремо оплату за виконану обсяг роботи, а не за просіженние годинник у замовника.