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

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

Що робити?

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

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

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

Чи часто Вас просить замовник, наприклад, змінити форму документа, додати пару реквізитів або розширити довжину найменування? Що ми при цьому кажемо: оновлювати таку конфігурацію нам потрібно буде вручну, обережно й уважно, оскільки можна втратити деякі або всі внесені зміни. І, звісно, це коштуватиме «трошки» дорожче. Одного разу, у далекому 2009-му році я побачив, чому «дорожче»: оновлювати змінену конфігурацію штатними засобами 1С — це пекло.

Ну а чого варті зміни в плані рахунків? Наприклад, рахунок 631 зробити групою й підпорядкувати йому штук п’ять субрахунків для обліку різних видів діяльності. Під час оновлення це ж катастрофа: 1С 7.7, на відміну від вісімки, не має зручного штатного механізму для об’єднання змін, і всі «доопрацювання» потрібно переносити вручну. Крім того, в усіх модулях проведення та модулях форми, де використовується рахунок 631, його потрібно замінити на 6311 (наприклад). Припустімо, у режимі об’єднання можна отримати шматки коду у вигляді коментарів, а потім вручну ухвалити рішення — що залишати. Але що ж буде, якщо Прибуткову Накладну оновлять і постачальники конфігурації, і ми? А що, якщо ми додамо пару реквізитів шапки й виведемо їх на форму? Штатний механізм об’єднання 1С нервово курить осторонь. Адже те, що я опишу, позбавить необхідності документувати у текстових файликах свої доопрацювання та зміни.

Що робити?

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

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

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

2. kdiff3 для об’єднання змін

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

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

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

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

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

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

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

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

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

Конфігурація 041 — С — папка 041

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

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

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

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

Запуск скрипта:

perl correct_dlg.pl -h

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

perl correct_dlg.pl -d SRC

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

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

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

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

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

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

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

Натискаємо F7 і…

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

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

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

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

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

Як бачите, якщо в коді є хоча б невеликий коментар щодо зміни — об’єднати їх не складе труднощів. А якщо таких немає — потрібно трохи розуміти, що змінювалося.

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

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

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

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

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

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

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

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

І об’єднуємо штатною 1С так само просто:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Мухлинін С.М.