K2 ERP Wiki Ukraine — База знань з автоматизації та санкцій в Україні

Атестаційні завдання K2 ERP/Система контролю версій: відмінності між версіями

R (обговорення | внесок)
Бюрократи, Адміністратори інтерфейсу, Адміністратори
737 редагувань
ВізуальнийВікірозмітка
Первинна публікація
 
Немає опису редагування
 
Рядок 1: Рядок 1:
{{DISPLAYTITLE:Атестаційні завдання K2 ERP/Система контролю версій}}


= Модуль контролю версій файлів, кодів і документів із журналом змін та можливістю відновлення =
'''Атестаційне завдання K2 ERP — Система контролю версій''' — це практична задача для перевірки навичок розробника або впроваджувача [[K2 ERP]] у створенні модуля контролю версій файлів, документів, програмного коду, дизайн-макетів та інших цифрових ресурсів.
 
Модуль має забезпечувати зберігання історії змін, журнал дій користувачів, порівняння версій, відновлення попередніх станів, контроль доступу, аудит змін, резервне копіювання та зручну роботу з великими наборами файлів.
 
<div style="border:3px solid #1565c0; background:#e3f2fd; padding:14px; margin:16px 0;">
'''Коротко.''' Потрібно реалізувати систему контролю версій: проєкти, файли, версії, коміти, журнал змін, diff, відновлення версій, права доступу, аудит, резервні копії, ZIP-експорт, роботу з великими файлами і звіти.
</div>
 
__TOC__
 
== Назва завдання ==
 
'''Модуль контролю версій файлів, кодів і документів із журналом змін та можливістю відновлення'''.
 
== Мета завдання ==
 
Мета завдання — створити в K2 ERP модуль для централізованого зберігання і контролю версій цифрових ресурсів.
 
Система повинна дозволяти:
 
* вести проєкти;
* створювати структуру файлів у межах проєкту;
* завантажувати початкові версії файлів;
* додавати нові версії файлів;
* зберігати старі версії без перезапису;
* фіксувати автора кожної зміни;
* зберігати опис зміни — commit message;
* вести журнал змін;
* порівнювати дві версії текстових файлів або коду;
* відновлювати будь-яку попередню версію;
* позначати поточну активну версію;
* контролювати доступ до перегляду, редагування, завантаження і відновлення;
* підтримувати архівування файлів;
* формувати звіти про зміни;
* працювати з великими файлами;
* виконувати ZIP-експорт;
* створювати резервні копії файлів і версій.
 
<div style="border:3px solid #2e7d32; background:#e8f5e9; padding:14px; margin:16px 0;">
'''Головний принцип.''' Жодна зміна не повинна втрачатися: кожна версія має зберігатися окремо, мати автора, дату, опис змін і можливість відновлення.
</div>


== Реальний бізнес-контекст ==
== Реальний бізнес-контекст ==
Підприємство:


* розробляє програмне забезпечення, документи, графіку або інші цифрові ресурси;
Підприємство або команда працює з цифровими файлами, які постійно змінюються:
* потребує зберігання всіх версій змін;
 
* має відслідковувати, хто і коли вніс зміни;
* програмний код;
* повинно мати можливість відновлювати попередні версії в разі помилок;
* технічна документація;
* проводить аудит змін для безпеки та відповідності стандартам.
* договори;
* інструкції;
* дизайн-макети;
* креслення;
* презентації;
* конфігураційні файли;
* шаблони документів;
* графіка;
* відео або медіафайли;
* внутрішні регламенти;
* файли проєктів.
 
Без системи контролю версій виникають типові проблеми:
 
* незрозуміло, яка версія файлу актуальна;
* старі файли випадково перезаписуються;
* складно знайти автора змін;
* неможливо швидко відновити попередню версію;
* немає журналу змін;
* немає контролю доступу;
* файли зберігаються у різних папках або в різних користувачів;
* зміни неможливо перевірити під час аудиту.
 
Система контролю версій вирішує ці проблеми через централізоване зберігання файлів, історію змін і механізм відновлення.
 
== Основний бізнес-процес ==
 
Типовий процес роботи виглядає так:
 
# користувач створює проєкт;
# у проєкті створюється файл або завантажується початкова версія;
# система створює версію v1;
# користувач редагує файл локально або готує нову версію;
# завантажує нову версію в систему;
# вказує опис змін;
# система створює версію v2;
# стара версія залишається в історії;
# користувач може порівняти v1 і v2;
# менеджер або адміністратор може переглянути журнал змін;
# у разі помилки користувач відновлює попередню версію;
# система створює нову версію на основі відновленої;
# усі дії потрапляють у журнал аудиту.
 
== Основні об’єкти модуля ==
 
{| class="wikitable" style="width:100%;"
! Об’єкт
! Призначення
|-
| Проєкти
| Логічні групи файлів
|-
| Файли проєкту
| Окремі файли, що мають історію версій
|-
| Версії файлів
| Збережені стани файлу
|-
| Коміти
| Описані зміни одного або кількох файлів
|-
| Журнал змін
| Хронологія дій користувачів
|-
| Diff
| Порівняння текстових версій
|-
| Відновлення
| Повернення до попередньої версії
|-
| Права доступу
| Хто може переглядати, змінювати, відновлювати або видаляти
|-
| Резервні копії
| Захист від втрати файлів
|-
| Звіти
| Аналітика по змінах, користувачах, проєктах і файлах
|}


Необхідно:
== Довідник «Проєкти» ==


* вести базу версій файлів;
Проєкт об’єднує файли, версії і користувачів.
* зберігати історію змін;
* організувати контроль доступу до редагування і перегляду;
* підтримувати можливість порівняння версій.


== Основні завдання ==
== Поля проєкту ==


=== 1. Структура довідників ===
{| class="wikitable" style="width:100%;"
! Поле
! Опис
|-
| Назва проєкту
| Назва системи, документації, сайту, дизайну або іншого набору файлів
|-
| Опис
| Короткий опис проєкту
|-
| Відповідальний
| Користувач або команда, яка відповідає за проєкт
|-
| Дата створення
| Коли створено проєкт
|-
| Статус
| Активний, архівований, закритий
|-
| Рівень доступу
| Публічний для команди або обмежений
|}


==== Довідник «Проекти» ====
== Довідник «Типи файлів» ==
Поля довідника:


* назва проекту;
Тип файлу допомагає фільтрувати і правильно обробляти версії.
* опис;
* відповідальний користувач або команда;
* дата створення.


==== Довідник «Типи файлів» ====
== Приклади типів файлів ==
Типи файлів:


* програмний код;
* програмний код;
* документація;
* документація;
* конфігураційний файл;
* графіка;
* графіка;
* дизайн-макет;
* креслення;
* презентація;
* таблиця;
* текстовий документ;
* архів;
* медіафайл;
* інше.
* інше.


=== 2. База «Файли проекту» ===
== База «Файли проєкту» ==
 
Файл проєкту — це основний об’єкт, для якого ведеться історія версій.
 
== Колонки бази файлів ==
 
{| class="wikitable" style="width:100%;"
! Колонка
! Опис
|-
| Проєкт
| До якого проєкту належить файл
|-
| Назва файлу
| Назва файлу або ресурсу
|-
| Шлях
| Папка або логічний шлях у проєкті
|-
| Тип файлу
| Код, документація, графіка тощо
|-
| Поточна версія
| Актуальна версія
|-
| Статус
| Активний, архівований, видалений
|-
| Відповідальний
| Хто відповідає за файл
|-
| Дата останньої зміни
| Коли файл змінювався востаннє
|}
 
== Поля файлу ==
 
{| class="wikitable" style="width:100%;"
! Поле
! Опис
|-
| Проєкт
| Батьківський проєкт
|-
| Назва файлу
| Ім’я файлу
|-
| Шлях у проєкті
| Наприклад: /docs/manual.docx або /src/app.py
|-
| Тип файлу
| Код, документ, графіка, інше
|-
| Поточна версія
| Версія, яка вважається актуальною
|-
| Розмір файлу
| Поточний розмір
|-
| Формат
| Розширення файлу
|-
| Відповідальний
| Користувач, який відповідає за файл
|-
| Статус
| Активний, архівований, видалений
|}
 
== Статуси файлу ==
 
{| class="wikitable" style="width:100%;"
! Статус
! Значення
|-
| Активний
| Файл використовується
|-
| Архівований
| Файл збережено для історії
|-
| Видалений
| Файл позначено як видалений, але історія може зберігатися
|-
| Заблокований
| Файл тимчасово недоступний для змін
|}
 
== База «Версії файлів» ==
 
Версії зберігають історію змін файлу.
 
== Поля версії ==
 
{| class="wikitable" style="width:100%;"
! Поле
! Опис
|-
| Файл
| До якого файлу належить версія
|-
| Номер версії
| v1, v2, v3 або інший формат
|-
| Дата оновлення
| Коли створено версію
|-
| Автор змін
| Хто завантажив версію
|-
| Опис змін
| Commit message
|-
| Файл версії
| Збережений файл
|-
| Розмір
| Розмір файлу
|-
| Хеш
| Контрольна сума, опціонально
|-
| Статус версії
| Поточна, архівна, відновлена, відхилена
|}
 
== Правила версійності ==
 
Система повинна дотримуватись таких правил:
 
* кожне завантаження створює нову версію;
* стара версія не перезаписується;
* кожна версія має автора;
* кожна версія має дату і час;
* кожна версія має опис змін;
* тільки одна версія може бути поточною;
* відновлення старої версії створює нову версію;
* видалення версій дозволено тільки адміністраторам;
* усі дії з версіями логуються.
 
<div style="border:2px solid #f57c00; background:#fff3e0; padding:14px; margin:16px 0;">
'''Важливо.''' Відновлення старої версії не повинно знищувати новіші версії. Система має створити нову версію на основі обраної старої.
</div>
 
== Коміти ==
 
Коміт — це логічна зміна одного або кількох файлів.
 
== Поля коміту ==
 
{| class="wikitable" style="width:100%;"
! Поле
! Опис
|-
| Проєкт
| До якого проєкту належить коміт
|-
| Автор
| Хто виконав зміну
|-
| Дата і час
| Коли зроблено коміт
|-
| Опис змін
| Commit message
|-
| Пов’язані файли
| Один або кілька файлів
|-
| Версії
| Які версії створено
|-
| Статус
| Збережено, відхилено, відновлено
|}
 
== Приклади commit message ==
 
* додано нову інструкцію;
* виправлено помилки в договорі;
* оновлено конфігурацію;
* додано новий дизайн-макет;
* виправлено розрахунок у коді;
* оновлено технічну документацію.
 
== Порівняння версій — diff ==
 
Для текстових файлів і коду потрібно реалізувати порівняння версій.
 
== Підтримувані формати для diff ==
 
* TXT;
* HTML;
* CSS;
* JS;
* PHP;
* Python;
* JSON;
* XML;
* YAML;
* SQL;
* Markdown;
* інші текстові формати.
 
== Що має показувати diff ==
 
* додані рядки;
* видалені рядки;
* змінені рядки;
* номер рядка;
* автора зміни, якщо можливо;
* дату версії;
* короткий опис змін.
 
== Відновлення версій ==
 
Користувач із відповідними правами може відновити будь-яку попередню версію.
 
== Логіка відновлення ==
 
# користувач відкриває файл;
# переглядає історію версій;
# обирає потрібну версію;
# натискає '''«Відновити»''';
# система створює нову версію на основі обраної;
# нова версія стає поточною;
# дія записується в журнал змін;
# у журналі видно, з якої версії виконано відновлення.
 
== Журнал змін ==
 
Журнал змін — основа аудиту системи.
 
== Журнал має містити ==
 
* дату і час;
* користувача;
* проєкт;
* файл;
* версію;
* дію;
* опис змін;
* IP-адресу, опціонально;
* старе і нове значення, якщо застосовується.
 
== Дії для журналу ==
 
* створення проєкту;
* створення файлу;
* завантаження версії;
* зміна опису;
* зміна статусу;
* відновлення версії;
* архівування файлу;
* видалення файлу;
* завантаження файлу користувачем;
* зміна прав доступу;
* експорт архіву;
* створення резервної копії.
 
== Контроль доступу ==
 
Система має підтримувати права доступу на рівні проєкту, файлу або дії.
 
== Права доступу ==
 
* перегляд проєкту;
* перегляд файлу;
* завантаження файлу;
* створення файлу;
* завантаження нової версії;
* порівняння версій;
* відновлення версії;
* архівування файлу;
* видалення файлу;
* керування правами;
* перегляд журналу аудиту;
* експорт ZIP.
 
<div style="border:3px solid #b71c1c; background:#ffebee; padding:14px; margin:16px 0;">
'''Критично.''' Користувач без відповідних прав не повинен бачити закритий проєкт, завантажувати файли, додавати нові версії або відновлювати попередні версії.
</div>
 
== Ролі користувачів ==
 
{| class="wikitable" style="width:100%;"
! Роль
! Можливості
|-
| Користувач
| Переглядає доступні проєкти і файли
|-
| Редактор
| Додає нові версії файлів і опис змін
|-
| Менеджер проєкту
| Керує файлами проєкту, переглядає журнал змін, відновлює версії
|-
| Аудитор
| Переглядає історію змін і звіти без права редагування
|-
| Адміністратор
| Керує проєктами, правами, файлами, версіями і резервними копіями
|-
| Адміністратор системи
| Налаштовує сховище, права, службові параметри і політики зберігання
|}
 
== Робота з великими файлами ==
 
Для великих файлів бажано реалізувати спеціальний механізм завантаження.
 
== Вимоги до великих файлів ==
 
* chunk upload;
* індикатор прогресу завантаження;
* перевірка розміру файлу;
* перевірка допустимого формату;
* можливість повторити невдале завантаження;
* збереження контрольної суми;
* обмеження розміру відповідно до ролі або налаштувань.
 
== ZIP-імпорт і ZIP-експорт ==
 
Опціонально система може підтримувати роботу з архівами.
 
== ZIP-експорт має дозволяти ==
 
* експортувати один файл із усіма версіями;
* експортувати поточні версії проєкту;
* експортувати архів проєкту;
* додавати журнал змін у ZIP;
* формувати структуру папок.
 
== ZIP-імпорт може дозволяти ==


==== Колонки бази ====
* завантажити кілька файлів одночасно;
* автоматично створити файли у проєкті;
* зберегти структуру папок;
* створити початкові версії для кожного файлу.


* проект;
== Резервне копіювання ==
 
Система має підтримувати резервне копіювання файлів і версій.
 
== Що потрібно резервувати ==
 
* файли;
* усі версії файлів;
* метадані файлів;
* журнал змін;
* права доступу;
* структуру проєктів.
 
== Політика зберігання версій ==
 
Опціонально можна налаштувати правила:
 
* зберігати всі версії безстроково;
* архівувати старі версії;
* обмежувати кількість версій для окремих типів файлів;
* заборонити видалення важливих версій;
* автоматично переносити старі файли в архівне сховище.
 
== Пошук і фільтрація ==
 
Система повинна мати зручний пошук.
 
== Параметри пошуку ==
 
* назва проєкту;
* назва файлу;
* назва файлу;
* тип файлу;
* тип файлу;
* статус:
* автор змін;
** активний;
* дата зміни;
** архівований;
* номер версії;
** видалений;
* commit message;
* дата створення;
* статус файлу;
* відповідальний користувач.
* формат файлу.


==== Функціонал ====
== Фільтри ==


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


=== 3. База «Версії файлів» ===
== Звіти ==


==== Колонки бази ====
== Звіт «Історія змін по проєкту» ==


У звіті потрібно відображати:
* проєкт;
* файл;
* файл;
* номер версії:
* версію;
** v1;
* автора;
** v2;
* дату зміни;
** v3;
* опис змін;
** наступні версії;
* дію.
* дата оновлення;
 
* користувач, який вніс зміни;
== Звіт «Активність користувачів» ==
* опис змін — commit message;
* файл версії;
* порівняння змін — для текстових документів і коду.


==== Функціонал ====
У звіті потрібно відображати:


* завантаження нової версії файлу;
* користувача;
* зберігання старих версій в архіві;
* кількість створених версій;
* порівняння двох версій — diff для текстових документів або коду;
* кількість змінених файлів;
* відновлення будь-якої версії як поточної.
* кількість відновлень;
* останню активність.


=== 4. Журнал змін ===
== Звіт «Файли без оновлень» ==
Хронологія всіх змін у проектах і файлах:


* дата;
У звіті потрібно відображати:
* хто змінив;
* який файл;
* яка версія;
* опис змін.


==== Функціонал ====
* проєкт;
* файл;
* поточну версію;
* дату останньої зміни;
* відповідального;
* кількість днів без оновлення.


* пошук по користувачу;
== Звіт «Відновлення версій» ==
* пошук по проекту;
* пошук по даті;
* пошук по типу файлу.


=== 5. Контроль доступу ===
У звіті потрібно відображати:


==== Права доступу ====
* проєкт;
* файл;
* хто відновив;
* яку версію відновлено;
* коли виконано відновлення;
* причина або коментар.


* перегляд;
== Звіт «Права доступу» ==
 
У звіті потрібно відображати:
 
* проєкт;
* файл або папку;
* користувача або роль;
* рівень доступу;
* дату надання доступу;
* хто надав доступ.
 
== AJAX-інтерактив ==
 
Інтерфейс має працювати швидко й без перезавантаження сторінок.
 
Через AJAX мають працювати:
 
* створення проєкту;
* створення файлу;
* завантаження нової версії;
* завантаження нової версії;
* оновлення журналу змін;
* фільтрація файлів;
* фільтрація версій;
* перегляд diff;
* відновлення версії;
* відновлення версії;
* видалення файлів або версій — для адміністраторів.
* зміна статусу файлу;
* зміна прав доступу;
* формування звітів;
* запуск ZIP-експорту.


==== Ролі користувачів ====
== Логування і аудит ==


* користувач;
Окремо від журналу змін файлів бажано вести аудит системних дій.
* менеджер проекту;
* адміністратор.


=== 6. Додаткові функції ===
== Аудит має фіксувати ==


* робота через AJAX для оновлення журналу змін у реальному часі;
* входи користувачів;
* підтримка роботи з великими файлами через chunk upload;
* спроби доступу до закритих файлів;
* імпорт / експорт файлів архівом ZIP;
* завантаження файлів;
* автоматичне створення бекапів усіх файлів і версій.
* експорт ZIP;
* зміну прав;
* видалення файлів;
* спроби відновлення без прав;
* помилки завантаження;
* створення резервних копій.


== Технічні вимоги ==
== Технічні вимоги ==
{| class="wikitable"
 
!Параметр
{| class="wikitable" style="width:100%;"
!Опис
! Параметр
! Опис
|-
| Бекенд
| K2 Cloud ERP на Python або PHP
|-
| База даних
| PostgreSQL або MySQL
|-
| Фронтенд
| HTML5, JavaScript
|-
| AJAX
| Fetch API або Axios
|-
|-
|Бекенд
| UI-компоненти
|K2 Cloud ERP на Python або PHP
| DataTables для проєктів, файлів і версій; Select2 для пошуку по проєктах, користувачах і типах файлів
|-
|-
|БД
| Файли
|PostgreSQL або MySQL
| Збереження на локальному сервері, S3-сумісному сховищі, Google Drive або іншому файловому сховищі
|-
|-
|Фронтенд
| Великі файли
|HTML5, JavaScript, AJAX, Fetch API або Axios
| Chunk upload, індикатор прогресу, перевірка розміру
|-
|-
|UI-компоненти
| Порівняння
|DataTables для проектів, файлів і версій; Select2 для пошуку по проектах
| Diff для текстових документів і коду
|-
|-
|Файли
| Експорт
|Збереження на локальному сервері або Amazon S3 / Google Drive, опціонально
| ZIP, PDF, Excel
|-
|-
|Друк
| Безпека
|Генерація звітів про зміни у PDF або Excel
| Рольова модель доступу, аудит, журнал дій
|}
|}


== Критерії оцінки ==
== Рекомендовані сутності бази даних ==
{| class="wikitable"
 
!Критерій
Для реалізації задачі доцільно передбачити такі сутності:
!Бали
 
* проєкти;
* типи файлів;
* файли проєкту;
* версії файлів;
* коміти;
* зв’язок комітів і файлів;
* права доступу;
* ролі;
* користувачі проєкту;
* журнал змін;
* журнал аудиту;
* diff-дані, якщо зберігаються;
* резервні копії;
* ZIP-експорти;
* налаштування сховища;
* звіти.
 
== Практичне завдання ==
 
У межах атестації потрібно продемонструвати робочий сценарій.
 
Мінімальний сценарій:
 
# створити проєкт;
# створити типи файлів;
# створити файл у проєкті;
# завантажити початкову версію файлу;
# перевірити створення версії v1;
# завантажити нову версію;
# вказати commit message;
# перевірити створення версії v2;
# переглянути історію версій;
# порівняти v1 і v2 для текстового файлу;
# відновити v1 як нову поточну версію;
# перевірити, що нова версія створена без видалення v2;
# переглянути журнал змін;
# налаштувати права доступу;
# перевірити, що користувач без прав не може завантажити файл;
# виконати ZIP-експорт проєкту;
# сформувати звіт історії змін;
# сформувати звіт активності користувачів;
# перевірити журнал аудиту.
 
== Критерії оцінювання ==
 
{| class="wikitable" style="width:100%;"
! Критерій
! Бали
! Що перевіряється
|-
| Реалізація бази проєктів, файлів і версій
| 20
| Проєкти, типи файлів, файли, версії, поточна версія, зберігання старих версій
|-
|-
|Реалізація бази проектів, файлів і версій
| Організація журналу змін і контроль доступу
|20
| 20
| Автори змін, commit message, журнал змін, ролі, права доступу, аудит
|-
|-
|Організація журналу змін і контроль доступу
| Можливість порівняння і відновлення версій
|20
| 20
| Diff для текстових файлів, історія версій, відновлення старої версії як нової поточної
|-
|-
|Можливість порівняння і відновлення версій
| Інтерактивність через AJAX і масштабованість системи
|20
| 20
| AJAX-завантаження, оновлення журналу, фільтри, робота з великими файлами, chunk upload
|-
|-
|Інтерактивність через AJAX і масштабованість системи
| Зручність роботи з великими об’ємами даних
|20
| 20
| Пошук, фільтри, ZIP-експорт, архівування, резервні копії, звіти
|-
|-
|Зручність роботи з великими об’ємами даних
! Разом
|20
! 100
! Максимальна оцінка
|}
|}
== Шкала оцінювання ==
{| class="wikitable" style="width:100%;"
! Бали
! Рівень
! Опис
|-
| 90–100
| Відмінно
| Модуль повністю працює: проєкти, файли, версії, коміти, diff, відновлення, права доступу, аудит, ZIP-експорт і звіти реалізовані коректно
|-
| 75–89
| Добре
| Основна логіка працює, є незначні недоліки, які не руйнують процес контролю версій
|-
| 60–74
| Зараховано
| Базовий сценарій працює, але частина функцій реалізована неповно або потребує доопрацювання
|-
| 0–59
| Не зараховано
| Відсутня критична логіка: проєкти, файли, версії, журнал змін, diff, відновлення або права доступу
|}
== Критичні помилки ==
Критичними помилками вважаються ситуації, коли:
* неможливо створити проєкт;
* неможливо створити файл;
* початкова версія не створюється;
* нова версія перезаписує стару;
* неможливо переглянути історію версій;
* неможливо визначити поточну версію;
* commit message не зберігається;
* автор змін не фіксується;
* diff не працює для текстових файлів, якщо заявлений у реалізації;
* відновлення старої версії видаляє новіші версії;
* користувач без прав може завантажити або відновити файл;
* журнал змін не фіксує ключові дії;
* ZIP-експорт не враховує права доступу;
* звіти не відповідають фактичним змінам.
<div style="border:3px solid #b71c1c; background:#ffebee; padding:14px; margin:16px 0;">
'''Умова складання.''' Завдання не може бути зараховане, якщо система не дозволяє пройти базовий цикл контролю версій: проєкт → файл → версія v1 → версія v2 → історія → diff → відновлення → журнал змін → права доступу → звіт.
</div>
== Очікуваний результат ==
У результаті виконання атестаційного завдання має бути створений модуль системи контролю версій у K2 ERP.
Модуль має підтримувати проєкти, типи файлів, файли проєкту, версії файлів, коміти, журнал змін, diff для текстових файлів, відновлення версій, контроль доступу, аудит, роботу з великими файлами, ZIP-експорт, резервні копії, звіти, AJAX-інтерактив і логування дій.


== Примітка ==
== Примітка ==
Система контролю версій — критично важлива для управління життєвим циклом:


* документів;
Система контролю версій критично важлива для управління життєвим циклом цифрових ресурсів: документів, програмного коду, дизайн-макетів, креслень, конфігурацій і технічної документації.
* програмного коду;
 
* дизайн-макетів;
Вона забезпечує прозорість змін, надійне збереження історії, можливість швидкого відновлення після помилки та контроль доступу до важливих файлів.
* іншої цифрової інформації.
 
== Коротко ==
 
{| class="wikitable" style="width:100%;"
! Питання
! Відповідь
|-
| Що потрібно створити?
| Модуль контролю версій файлів, коду і документів
|-
| Які довідники потрібні?
| Проєкти, типи файлів, ролі доступу
|-
| Який головний об’єкт?
| Файл із версіями
|-
| Що таке версія?
| Збережений стан файлу з автором, датою і описом змін
|-
| Що потрібно для текстових файлів?
| Diff між версіями
|-
| Що потрібно для відновлення?
| Створення нової версії на основі старої без видалення історії
|-
| Які звіти потрібні?
| Історія змін, активність користувачів, відновлення версій, права доступу
|-
| Що є критичною вимогою?
| Нова версія не повинна перезаписувати стару
|}
 
== Див. також ==


Вона забезпечує:
* [[K2 Cloud ERP|K2 ERP]]
* [[K2 ERP]]
* [[Атестаційні завдання K2 ERP]]
* [[Веб-архів документів]]
* [[Документообіг]]
* [[Файл]]
* [[Версійність]]
* [[Журнал змін]]
* [[Права доступу]]
* [[Diff]]
* [[Backup]]
* [[AJAX]]


* прозорість змін;
[[Категорія:K2 ERP]]
* надійність збереження історії;
[[Категорія:Атестаційні завдання K2]]
* швидке відновлення у разі помилок.
[[Категорія:Система контролю версій]]
[[Категорія:Версійність]]
[[Категорія:Документообіг]]
[[Категорія:Права доступу]]
[[Категорія:Корпоративна Wiki]]
Отримано з https://wiki.erp.kyiv.ua/index.php?title=Атестаційні_завдання_K2_ERP/Система_контролю_версій