Технологія розгалуженої розробки конфігурацій

1. Визначення

2. Розробка виправних версій

3. Розробка планової версії

4. Розробка технічних проєктів

5. Нумерація збірок

Додаток 1. Порядок створення сховища технічного проєкту

Додаток 2. Порядок оновлення сховища технічного проєкту до стану основного сховища

Сфера застосування: керований додаток, мобільний додаток, звичайний додаток.

Методична рекомендація (корисна порада)

Цілі впровадження технології:

• Підвищення якості розроблюваної конфігурації
• Підвищення культури розробки та тестування
• Забезпечення безперервного розвитку конфігурацій в умовах жорстких термінів розробки

1. Визначення

Планова версія конфігурації – версія, що містить істотний розвиток функціоналу, строк випуску якої призначається заздалегідь.

Виправна версія – версія, що випускається за потреби термінової публікації виправлень критичних помилок. У виняткових випадках виправна версія може містити якийсь новий функціонал (наприклад, доопрацювання, пов’язані з підтримкою зміни законодавства). Строк випуску визначається під час аналізу кількості та критичності виявлених помилок планової версії.

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

Для організації робіт з розробки та супроводу конфігурацій (зокрема ведення інформації про технічні проєкти та списку помилок) рекомендується використовувати Систему проєктування прикладних рішень (СППР).

2. Розробка виправних версій

2.1. Для випуску кожної виправної версії створюється нове сховище на основі конфігурації останньої випущеної версії.

Важливо – потрібно створювати нове сховище, а не копіювати основне!

2.2. У виправній версії не повинно бути об’ємних доопрацювань конфігурації, інакше потрібно переглядати строки випуску планової версії.

2.3. Усі закладки у сховищі виправної версії повинні містити коментар.

Вимоги до змісту коментарів аналогічні вимогам до закладок у сховищі планової версії (див. п.3.4).

2.4. Усі зміни, що виконуються у виправному релізі, повинні синхронно повторюватися в основному сховищі. Якщо у виправному релізі додаються нові об’єкти (реквізити об’єктів), то переносити зміни потрібно виключно за допомогою порівняння/об’єднання конфігурацій, щоб не відрізнялися внутрішні ідентифікатори об’єктів конфігурації.

2.5. Під час збирання виправної версії рекомендується встановлювати позначку з інформацією про номер збірки на закладці тієї версії сховища, конфігурація якої йде до збірки. Зазвичай це остання на момент збирання закладка.

3. Розробка планової версії

3.1. Розробка планових версій ведеться в основному сховищі конфігурації.

3.2. Закладки до основного сховища повинні здійснюватися таким чином, щоб кожна закладка переводила конфігурацію сховища з одного робочого (готового до випуску) стану в інший.
Не допускається закладка не повністю налагодженого функціоналу! Основне сховище завжди повинно перебувати в «нерозваленому» стані, щоб у будь-який момент можна було розпочати збирання планової версії.

3.3. В основному сховищі дозволяється виконувати такі роботи:

• виправлення помилок, що не потребують перепроєктування, об’ємного кодування та тестування. Якщо помилка потребує великих переробок і/або перегляду проєктних рішень, то виправлення такої помилки повинно вестися в межах технічного проєкту. Порядок роботи з основним сховищем повинен бути таким самим, як і за іншими технічними проєктами;
• вбудовування нових версій бібліотек;
• вбудовування повністю налагоджених проєктів, що пройшли налагоджувальне тестування;
• у виняткових випадках в основному сховищі може вестися розробка деяких проєктів (наприклад, проєктів із масового рефакторингу).

Рекомендується використовувати реалізовані у СППР можливості автоматичного генерування текстів коментарів для закладок, пов’язаних із виправленням помилок і вбудовуванням технічних проєктів.

3.4. Усі закладки до основного сховища повинні містити коментар.

Зміст коментаря залежить від характеру виконаних робіт:

• під час виправлення помилки обов’язково має бути зазначений номер і коротка назва помилки в системі баг-трекінгу;
• під час вбудовування нової версії бібліотеки має бути зазначено назву бібліотеки і точний номер версії бібліотеки;
• під час вбудовування технічних проєктів – номер проєкту в системі ведення проєктної документації, а також коротка назва;
• під час виконання робіт за технічним проєктом в основному сховищі коментар, окрім номера та короткої назви проєкту, повинен містити короткий опис змін, зроблених у цій закладці.

3.5. Усі зміни за технічним проєктом повинні переноситися до основного сховища за одну закладку. Якщо необхідно переносити зміни кілька разів, то потрібно відкривати кілька проєктів.

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

3.7. Під час збирання планової версії рекомендується встановлювати позначку з інформацією про номер збірки на закладці тієї версії сховища, конфігурація якої йде до збірки. Зазвичай це остання на момент збирання закладка.

4. Розробка технічних проєктів

4.1. Розробка кожного технічного проєкту ведеться в окремому сховищі.

За використання СППР сховище технічного проєкту може бути створено автоматично. Якщо СППР не використовується, сховище технічного проєкту потрібно буде створювати вручну, відповідно до порядку, описаного в Додатку 1.

4.2. Під час постановки сховища технічного проєкту на підтримку від основного сховища платформа для всіх об’єктів установлює правило «Об’єкт постачальника, не редагується». Для роботи над технічним проєктом потрібно змінити це правило на «Об’єкт постачальника редагується зі збереженням підтримки».

Правило «Об’єкт постачальника редагується зі збереженням підтримки» потрібно встановлювати лише для тих об’єктів, які змінюються під час виконання технічного проєкту. Правило потрібно змінювати якомога точніше – наприклад, якщо зміни в проєкті стосуватимуться лише форми, то потрібно змінити правило лише для цієї форми, а для об’єкта, якому належить ця форма, потрібно залишити правило «Об’єкт постачальника, не редагується».

Для зміни правил підтримки потрібно захопити лише корінь конфігурації, захоплювати самі об’єкти не потрібно.

Виконання цих рекомендацій дасть змогу спростити процес перенесення змін між основним сховищем і сховищем тех. проєкту.

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

На частоту оновлення можуть впливати такі чинники:

• чи зачіпає технічний проєкт об’єкти інших відповідальних;
• чи проводиться в цей час рефакторинг загальних механізмів;
• чи ведеться зараз в основному сховищі масове виправлення помилок.

Порядок оновлення сховища технічного проєкту описано в додатку 2.

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

Відповідальні за інші технічні проєкти можуть попросити перенести строки внесення до основного сховища.

У СППР узгоджувати строки вбудовування технічних проєктів можна, використовуючи функціональність контрольних точок за технічним проєктом.

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

4.6. Внесення напрацювань технічного проєкту до основного сховища не повинно призводити до тривалого захоплення об’єктів основного сховища. Це досягається тим, що спочатку сховище технічного проєкту оновлюється до стану основного сховища (за методикою, описаною в додатку 2. Якщо змін багато, то таке оновлення може зайняти досить багато часу (до кількох днів) – за цей час конфігурація основного сховища може змінитися. Тому процес оновлення може бути ітеративним – на кожній ітерації оновлення відмінності в конфігураціях ставатимуть дедалі ближчими до величини змін, внесених технічним проєктом.

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

Починати перенесення змін до основного сховища (захоплювати об’єкти в основному сховищі) слід лише тоді, коли конфігурація технічного проєкту відрізнятиметься від конфігурації основного сховища практично лише змінами, що вносяться проєктом.

4.7. Відповідальний за технічний проєкт повинен уважно ставитися до внесення змін до основного сховища. Потрібно пам’ятати, що основне сховище повинно в будь-який момент часу перебувати в стані готовності до випуску планової версії.

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

4.8. Після перевірки перенесення змін і до закладки змін до основного сховища відповідальний обов’язково повинен запустити перевірку конфігурації. Перевірку потрібно проводити з максимальними налаштуваннями.
Закладка змін до основного сховища допускається лише після того, як буде виправлено всі помилки, виявлені перевіркою конфігурації, які були внесені проєктом.

4.9. Після перенесення змін до основного сховища відповідальний за технічний проєкт видаляє сховище проєкту

5. Нумерація збірок

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

5.1. Номер збірки слід збільшувати як в основному сховищі, так і у сховищі виправного релізу у двох випадках:

• безпосередньо перед збиранням релізу. Це необхідно, щоб повний номер зібраного релізу гарантовано відрізнявся від повного номера попереднього релізу;
• під час закладки до сховища обробника оновлення інформаційної бази. Це необхідно, щоб після оновлення зі сховища в усіх учасників розробки доданий обробник оновлення запускався автоматично (лише для конфігурацій, заснованих на Бібліотеці Стандартних Підсистем).

5.2.1. Під час додавання до сховища обробників оновлення інформаційної бази рекомендується в межах цієї самої закладки підвищувати номер збірки. Існує два можливі сценарії:

• Обробник оновлення додається під час розробки технічного проєкту до сховища технічного проєкту. У цьому випадку під час перенесення змін до основного сховища слід збільшити номер збірки основного сховища.
• Обробник оновлення додається в межах виправлення помилки. Якщо помилка виправляється лише в одному сховищі (основному або виправному), то номер збірки підвищується лише в ньому, якщо у двох – отже потрібно збільшити номер в обох сховищах.

5.2.2. Обробник і зміну номера збірки потрібно поміщати до сховища в межах однієї закладки. При цьому обробник оновлення повинен бути «прив’язаний» до того номера збірки, який разом із ним поміщається до сховища.

5.2.3. Якщо в межах однієї конфігурації обробники оновлення розділені за технологічними підсистемами (наприклад, у конфігурації 1С:ERP обробники розділені на підсистеми УправлениеПредприятием і УправлениеТорговлей), то потрібно підвищувати номер збірки як підсистеми, до якої належить обробник, так і конфігурації.

5.3. Номер збірки необхідно змінювати:

1. У властивостях конфігурації.
2. У процедурі ОбновлениеИнформационнойБазы<ИмяБиблиотеки>.ПриДобавленииПодсистемы (лише для конфігурацій, заснованих на Библиотеке Стандартных Подсистем).

Додаток 1. Порядок створення сховища технічного проєкту

1. Оновити зі сховища конфігурацію інформаційної бази, підключену до основного сховища
2. Створити файл постачання конфігурації основного сховища (*.cf)
3. До інформаційної бази, яка використовуватиметься для роботи над технічним проєктом, завантажити конфігурацію з файлу постачання. Після завантаження конфігурації з файлу постачання конфігурація перебуватиме на підтримці без можливості зміни.
4. Створити сховище конфігурації у відповідній спільній папці (під час створення сховища платформа ввімкне в конфігурації можливість зміни)
5. Додати користувача ЛишеПерегляд (без пароля, без права захоплення об’єктів). Цього користувача не потрібно використовувати для підключення бази до сховища – лише для оновлення зі сховища (отримання конфігурації сховища)
6. Додати до сховища користувачів, перелічених у проєкті (логін – прізвище співробітника, без пароля, з правом захоплення об’єктів). Не потрібно використовувати для роботи учасників проєкту логін користувача ЛишеПерегляд.

Додаток 2. Порядок оновлення сховища технічного проєкту до стану основного сховища

Перед виконанням перенесення змін зі сховища технічного проєкту (далі СТП) до основного сховища (далі ОС) виконується оновлення СТП до стану ОС.

Щоб оновити СТП до стану ОС, необхідно виконати таке:

1. Оновити інформаційну базу, підключену до ОС.
2. Створити файл постачання конфігурації ОС.
3. Захопити всі об’єкти в СТП.
4. Запустити порівняння основної конфігурації та конфігурації постачальника (Конфігурація – Порівняти конфігурації). Результати порівняння зберегти до файлу – це зміни, внесені до конфігурації під час роботи над технічним проєктом. У меню «Дії» вибрати пункт «Звіт про порівняння конфігурацій». Для подальшого використання краще вивести та зберегти звіт про порівняння і в текстовому форматі, і у форматі табличного документа.
   
   
5. Оновити конфігурацію (Конфігурація – Підтримка – Оновити конфігурацію – Вибір файлу оновлення – вказати файл постачання конфігурації, створений на кроці 2).
   
   У вікні порівняння та об’єднання конфігурацій, що з’явиться, натиснути кнопку "Фільтр" і встановити прапорець Показувати лише двічі змінені властивості".
   
   
   
   На ці об’єкти потрібно звернути увагу під час об’єднання, інші зміни можна об’єднувати без перевірки.
   
   
6. У діалозі, який з’являється після натискання кнопки «Виконати» вікна порівняння та об’єднання конфігурацій, для нових об’єктів постачальника потрібно встановити правило «Об’єкт не редагується» – як для об’єктів із правилом «Зміни дозволені», так і для об’єктів із правилом «Зміни не рекомендуються», для всіх інших установити прапорець «Зберігати поточний режим» (за замовчуванням його встановлено).
   
   
7. Після завершення об’єднання потрібно виправити об’єкти, яких стосується технічний проєкт, зміни в яких було затерто під час оновлення. По суті це означає, що потрібно повторно внести доопрацювання, реалізовані в межах технічного проєкту, до об’єктів конфігурації.
8. Запустити порівняння оновленої основної конфігурації технічного проєкту та оновленої конфігурації постачальника (Конфігурація – Порівняти конфігурації)
   
   
9. Результати порівняння зберегти до файлу, ім’я файлу повинно відрізнятися від імені файлу, створеного на кроці 6. У меню «Дії» вибрати пункт «Звіт про порівняння конфігурацій». Для подальшого використання краще вивести та зберегти звіт про порівняння в текстовому форматі.
10. Порівняти файли, створені на кроці 4 і кроці 9. За правильного оновлення порівняння файлів не повинно показати відмінностей.