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

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


Атестаційне завдання K2 ERP — Система контролю версій — це практична задача для перевірки навичок розробника або впроваджувача K2 ERP у створенні модуля контролю версій файлів, документів, програмного коду, дизайн-макетів та інших цифрових ресурсів.

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

Коротко. Потрібно реалізувати систему контролю версій: проєкти, файли, версії, коміти, журнал змін, diff, відновлення версій, права доступу, аудит, резервні копії, ZIP-експорт, роботу з великими файлами і звіти.

Назва завдання

Модуль контролю версій файлів, кодів і документів із журналом змін та можливістю відновлення.

Мета завдання

Мета завдання — створити в K2 ERP модуль для централізованого зберігання і контролю версій цифрових ресурсів.

Система повинна дозволяти:

  • вести проєкти;
  • створювати структуру файлів у межах проєкту;
  • завантажувати початкові версії файлів;
  • додавати нові версії файлів;
  • зберігати старі версії без перезапису;
  • фіксувати автора кожної зміни;
  • зберігати опис зміни — commit message;
  • вести журнал змін;
  • порівнювати дві версії текстових файлів або коду;
  • відновлювати будь-яку попередню версію;
  • позначати поточну активну версію;
  • контролювати доступ до перегляду, редагування, завантаження і відновлення;
  • підтримувати архівування файлів;
  • формувати звіти про зміни;
  • працювати з великими файлами;
  • виконувати ZIP-експорт;
  • створювати резервні копії файлів і версій.

Головний принцип. Жодна зміна не повинна втрачатися: кожна версія має зберігатися окремо, мати автора, дату, опис змін і можливість відновлення.

Реальний бізнес-контекст

Підприємство або команда працює з цифровими файлами, які постійно змінюються:

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

Без системи контролю версій виникають типові проблеми:

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

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

Основний бізнес-процес

Типовий процес роботи виглядає так:

  1. користувач створює проєкт;
  2. у проєкті створюється файл або завантажується початкова версія;
  3. система створює версію v1;
  4. користувач редагує файл локально або готує нову версію;
  5. завантажує нову версію в систему;
  6. вказує опис змін;
  7. система створює версію v2;
  8. стара версія залишається в історії;
  9. користувач може порівняти v1 і v2;
  10. менеджер або адміністратор може переглянути журнал змін;
  11. у разі помилки користувач відновлює попередню версію;
  12. система створює нову версію на основі відновленої;
  13. усі дії потрапляють у журнал аудиту.

Основні об’єкти модуля

Об’єкт Призначення
Проєкти Логічні групи файлів
Файли проєкту Окремі файли, що мають історію версій
Версії файлів Збережені стани файлу
Коміти Описані зміни одного або кількох файлів
Журнал змін Хронологія дій користувачів
Diff Порівняння текстових версій
Відновлення Повернення до попередньої версії
Права доступу Хто може переглядати, змінювати, відновлювати або видаляти
Резервні копії Захист від втрати файлів
Звіти Аналітика по змінах, користувачах, проєктах і файлах

Довідник «Проєкти»

Проєкт об’єднує файли, версії і користувачів.

Поля проєкту

Поле Опис
Назва проєкту Назва системи, документації, сайту, дизайну або іншого набору файлів
Опис Короткий опис проєкту
Відповідальний Користувач або команда, яка відповідає за проєкт
Дата створення Коли створено проєкт
Статус Активний, архівований, закритий
Рівень доступу Публічний для команди або обмежений

Довідник «Типи файлів»

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

Приклади типів файлів

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

База «Файли проєкту»

Файл проєкту — це основний об’єкт, для якого ведеться історія версій.

Колонки бази файлів

Колонка Опис
Проєкт До якого проєкту належить файл
Назва файлу Назва файлу або ресурсу
Шлях Папка або логічний шлях у проєкті
Тип файлу Код, документація, графіка тощо
Поточна версія Актуальна версія
Статус Активний, архівований, видалений
Відповідальний Хто відповідає за файл
Дата останньої зміни Коли файл змінювався востаннє

Поля файлу

Поле Опис
Проєкт Батьківський проєкт
Назва файлу Ім’я файлу
Шлях у проєкті Наприклад: /docs/manual.docx або /src/app.py
Тип файлу Код, документ, графіка, інше
Поточна версія Версія, яка вважається актуальною
Розмір файлу Поточний розмір
Формат Розширення файлу
Відповідальний Користувач, який відповідає за файл
Статус Активний, архівований, видалений

Статуси файлу

Статус Значення
Активний Файл використовується
Архівований Файл збережено для історії
Видалений Файл позначено як видалений, але історія може зберігатися
Заблокований Файл тимчасово недоступний для змін

База «Версії файлів»

Версії зберігають історію змін файлу.

Поля версії

Поле Опис
Файл До якого файлу належить версія
Номер версії v1, v2, v3 або інший формат
Дата оновлення Коли створено версію
Автор змін Хто завантажив версію
Опис змін Commit message
Файл версії Збережений файл
Розмір Розмір файлу
Хеш Контрольна сума, опціонально
Статус версії Поточна, архівна, відновлена, відхилена

Правила версійності

Система повинна дотримуватись таких правил:

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

Важливо. Відновлення старої версії не повинно знищувати новіші версії. Система має створити нову версію на основі обраної старої.

Коміти

Коміт — це логічна зміна одного або кількох файлів.

Поля коміту

Поле Опис
Проєкт До якого проєкту належить коміт
Автор Хто виконав зміну
Дата і час Коли зроблено коміт
Опис змін Commit message
Пов’язані файли Один або кілька файлів
Версії Які версії створено
Статус Збережено, відхилено, відновлено

Приклади commit message

  • додано нову інструкцію;
  • виправлено помилки в договорі;
  • оновлено конфігурацію;
  • додано новий дизайн-макет;
  • виправлено розрахунок у коді;
  • оновлено технічну документацію.

Порівняння версій — diff

Для текстових файлів і коду потрібно реалізувати порівняння версій.

Підтримувані формати для diff

  • TXT;
  • HTML;
  • CSS;
  • JS;
  • PHP;
  • Python;
  • JSON;
  • XML;
  • YAML;
  • SQL;
  • Markdown;
  • інші текстові формати.

Що має показувати diff

  • додані рядки;
  • видалені рядки;
  • змінені рядки;
  • номер рядка;
  • автора зміни, якщо можливо;
  • дату версії;
  • короткий опис змін.

Відновлення версій

Користувач із відповідними правами може відновити будь-яку попередню версію.

Логіка відновлення

  1. користувач відкриває файл;
  2. переглядає історію версій;
  3. обирає потрібну версію;
  4. натискає «Відновити»;
  5. система створює нову версію на основі обраної;
  6. нова версія стає поточною;
  7. дія записується в журнал змін;
  8. у журналі видно, з якої версії виконано відновлення.

Журнал змін

Журнал змін — основа аудиту системи.

Журнал має містити

  • дату і час;
  • користувача;
  • проєкт;
  • файл;
  • версію;
  • дію;
  • опис змін;
  • IP-адресу, опціонально;
  • старе і нове значення, якщо застосовується.

Дії для журналу

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

Контроль доступу

Система має підтримувати права доступу на рівні проєкту, файлу або дії.

Права доступу

  • перегляд проєкту;
  • перегляд файлу;
  • завантаження файлу;
  • створення файлу;
  • завантаження нової версії;
  • порівняння версій;
  • відновлення версії;
  • архівування файлу;
  • видалення файлу;
  • керування правами;
  • перегляд журналу аудиту;
  • експорт ZIP.

Критично. Користувач без відповідних прав не повинен бачити закритий проєкт, завантажувати файли, додавати нові версії або відновлювати попередні версії.

Ролі користувачів

Роль Можливості
Користувач Переглядає доступні проєкти і файли
Редактор Додає нові версії файлів і опис змін
Менеджер проєкту Керує файлами проєкту, переглядає журнал змін, відновлює версії
Аудитор Переглядає історію змін і звіти без права редагування
Адміністратор Керує проєктами, правами, файлами, версіями і резервними копіями
Адміністратор системи Налаштовує сховище, права, службові параметри і політики зберігання

Робота з великими файлами

Для великих файлів бажано реалізувати спеціальний механізм завантаження.

Вимоги до великих файлів

  • chunk upload;
  • індикатор прогресу завантаження;
  • перевірка розміру файлу;
  • перевірка допустимого формату;
  • можливість повторити невдале завантаження;
  • збереження контрольної суми;
  • обмеження розміру відповідно до ролі або налаштувань.

ZIP-імпорт і ZIP-експорт

Опціонально система може підтримувати роботу з архівами.

ZIP-експорт має дозволяти

  • експортувати один файл із усіма версіями;
  • експортувати поточні версії проєкту;
  • експортувати архів проєкту;
  • додавати журнал змін у ZIP;
  • формувати структуру папок.

ZIP-імпорт може дозволяти

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

Резервне копіювання

Система має підтримувати резервне копіювання файлів і версій.

Що потрібно резервувати

  • файли;
  • усі версії файлів;
  • метадані файлів;
  • журнал змін;
  • права доступу;
  • структуру проєктів.

Політика зберігання версій

Опціонально можна налаштувати правила:

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

Пошук і фільтрація

Система повинна мати зручний пошук.

Параметри пошуку

  • назва проєкту;
  • назва файлу;
  • тип файлу;
  • автор змін;
  • дата зміни;
  • номер версії;
  • commit message;
  • статус файлу;
  • формат файлу.

Фільтри

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

Звіти

Звіт «Історія змін по проєкту»

У звіті потрібно відображати:

  • проєкт;
  • файл;
  • версію;
  • автора;
  • дату зміни;
  • опис змін;
  • дію.

Звіт «Активність користувачів»

У звіті потрібно відображати:

  • користувача;
  • кількість створених версій;
  • кількість змінених файлів;
  • кількість відновлень;
  • останню активність.

Звіт «Файли без оновлень»

У звіті потрібно відображати:

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

Звіт «Відновлення версій»

У звіті потрібно відображати:

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

Звіт «Права доступу»

У звіті потрібно відображати:

  • проєкт;
  • файл або папку;
  • користувача або роль;
  • рівень доступу;
  • дату надання доступу;
  • хто надав доступ.

AJAX-інтерактив

Інтерфейс має працювати швидко й без перезавантаження сторінок.

Через AJAX мають працювати:

  • створення проєкту;
  • створення файлу;
  • завантаження нової версії;
  • оновлення журналу змін;
  • фільтрація файлів;
  • фільтрація версій;
  • перегляд diff;
  • відновлення версії;
  • зміна статусу файлу;
  • зміна прав доступу;
  • формування звітів;
  • запуск ZIP-експорту.

Логування і аудит

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

Аудит має фіксувати

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

Технічні вимоги

Параметр Опис
Бекенд K2 Cloud ERP на Python або PHP
База даних PostgreSQL або MySQL
Фронтенд HTML5, JavaScript
AJAX Fetch API або Axios
UI-компоненти DataTables для проєктів, файлів і версій; Select2 для пошуку по проєктах, користувачах і типах файлів
Файли Збереження на локальному сервері, S3-сумісному сховищі, Google Drive або іншому файловому сховищі
Великі файли Chunk upload, індикатор прогресу, перевірка розміру
Порівняння Diff для текстових документів і коду
Експорт ZIP, PDF, Excel
Безпека Рольова модель доступу, аудит, журнал дій

Рекомендовані сутності бази даних

Для реалізації задачі доцільно передбачити такі сутності:

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

Практичне завдання

У межах атестації потрібно продемонструвати робочий сценарій.

Мінімальний сценарій:

  1. створити проєкт;
  2. створити типи файлів;
  3. створити файл у проєкті;
  4. завантажити початкову версію файлу;
  5. перевірити створення версії v1;
  6. завантажити нову версію;
  7. вказати commit message;
  8. перевірити створення версії v2;
  9. переглянути історію версій;
  10. порівняти v1 і v2 для текстового файлу;
  11. відновити v1 як нову поточну версію;
  12. перевірити, що нова версія створена без видалення v2;
  13. переглянути журнал змін;
  14. налаштувати права доступу;
  15. перевірити, що користувач без прав не може завантажити файл;
  16. виконати ZIP-експорт проєкту;
  17. сформувати звіт історії змін;
  18. сформувати звіт активності користувачів;
  19. перевірити журнал аудиту.

Критерії оцінювання

Критерій Бали Що перевіряється
Реалізація бази проєктів, файлів і версій 20 Проєкти, типи файлів, файли, версії, поточна версія, зберігання старих версій
Організація журналу змін і контроль доступу 20 Автори змін, commit message, журнал змін, ролі, права доступу, аудит
Можливість порівняння і відновлення версій 20 Diff для текстових файлів, історія версій, відновлення старої версії як нової поточної
Інтерактивність через AJAX і масштабованість системи 20 AJAX-завантаження, оновлення журналу, фільтри, робота з великими файлами, chunk upload
Зручність роботи з великими об’ємами даних 20 Пошук, фільтри, ZIP-експорт, архівування, резервні копії, звіти
Разом 100 Максимальна оцінка

Шкала оцінювання

Бали Рівень Опис
90–100 Відмінно Модуль повністю працює: проєкти, файли, версії, коміти, diff, відновлення, права доступу, аудит, ZIP-експорт і звіти реалізовані коректно
75–89 Добре Основна логіка працює, є незначні недоліки, які не руйнують процес контролю версій
60–74 Зараховано Базовий сценарій працює, але частина функцій реалізована неповно або потребує доопрацювання
0–59 Не зараховано Відсутня критична логіка: проєкти, файли, версії, журнал змін, diff, відновлення або права доступу

Критичні помилки

Критичними помилками вважаються ситуації, коли:

  • неможливо створити проєкт;
  • неможливо створити файл;
  • початкова версія не створюється;
  • нова версія перезаписує стару;
  • неможливо переглянути історію версій;
  • неможливо визначити поточну версію;
  • commit message не зберігається;
  • автор змін не фіксується;
  • diff не працює для текстових файлів, якщо заявлений у реалізації;
  • відновлення старої версії видаляє новіші версії;
  • користувач без прав може завантажити або відновити файл;
  • журнал змін не фіксує ключові дії;
  • ZIP-експорт не враховує права доступу;
  • звіти не відповідають фактичним змінам.

Умова складання. Завдання не може бути зараховане, якщо система не дозволяє пройти базовий цикл контролю версій: проєкт → файл → версія v1 → версія v2 → історія → diff → відновлення → журнал змін → права доступу → звіт.

Очікуваний результат

У результаті виконання атестаційного завдання має бути створений модуль системи контролю версій у K2 ERP.

Модуль має підтримувати проєкти, типи файлів, файли проєкту, версії файлів, коміти, журнал змін, diff для текстових файлів, відновлення версій, контроль доступу, аудит, роботу з великими файлами, ZIP-експорт, резервні копії, звіти, AJAX-інтерактив і логування дій.

Примітка

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

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

Коротко

Питання Відповідь
Що потрібно створити? Модуль контролю версій файлів, коду і документів
Які довідники потрібні? Проєкти, типи файлів, ролі доступу
Який головний об’єкт? Файл із версіями
Що таке версія? Збережений стан файлу з автором, датою і описом змін
Що потрібно для текстових файлів? Diff між версіями
Що потрібно для відновлення? Створення нової версії на основі старої без видалення історії
Які звіти потрібні? Історія змін, активність користувачів, відновлення версій, права доступу
Що є критичною вимогою? Нова версія не повинна перезаписувати стару

Див. також

Отримано з https://wiki.erp.kyiv.ua/index.php?title=Атестаційні_завдання_K2_ERP/Система_контролю_версій&oldid=562