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

Поточна версія на 20:42, 1 травня 2026

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

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

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

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

У звіті потрібно відображати: !; Відповідь

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

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

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

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

!;== Коміти ==

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

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

; платформа повинна мати зручний пошук.; характеристика

Коміт — це логічна зміна одного або кількох файлів.; * незрозуміло, яка реліз файлу актуальна;

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

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

; Значення

; Що перевіряється

; Об’єкт

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

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

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

; 100 назва проєкту; назва файлу; тип файлу; автор змін; дата зміни; номер версії; commit message; статус файлу; формат файлу.;== ZIP-імпорт і ZIP-експорт == ZIP-імпорт має змогу дозволяти
Реалізація бази проєктів, файлів і версій	20	Проєкти, типи файлів, файли, версії, поточна реліз, зберігання старих версій
Організація журналу змін і контроль доступу	20	Автори змін, commit message, журнал змін, ролі, права доступу, аудит
Можливість порівняння і відновлення версій	20	Diff для текстових файлів, історичний розвиток версій, відновлення старої версії як нової поточної
Інтерактивність через AJAX і масштабованість системи	20	AJAX-завантаження, актуалізація журналу, фільтри, робота з великими файлами, chunk upload
Зручність роботи з великими об’ємами даних	20	Пошук, фільтри, ZIP-експорт, архівування, резервні копії, звіти
Що таке реліз?; Параметр Назва задача користувач системи із відповідними правами має змогу відновити будь-яку попередню версію.;== Поля версії == Критично. користувач системи без відповідних прав не повинен бачити закритий проєкт, завантажувати файли, додавати нові версії або відновлювати попередні версії.; Максимальна оцінка
Файл	До якого файлу належить реліз
Номер версії	v1, v2, v3 або інший формат
Дата актуалізація	Коли створено версію
Автор змін	Хто завантажив версію
характеристика змін	Commit message
Файл версії	Збережений файл
Розмір	Розмір файлу
Хеш	Контрольна сума, опціонально
Статус версії	Поточна, архівна, відновлена, відхилена

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

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

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

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

; характеристика Журнал змін
class="wikitable" style="width:100%;" Ролі користувачів Рекомендовані сутності бази даних створити проєкт; створити типи файлів; створити файл у проєкті; завантажити початкову версію файлу; перевірити створення версії v1; завантажити нову версію; вказати commit message; перевірити створення версії v2; переглянути історію версій; порівняти v1 і v2 для текстового файлу; відновити v1 як нову поточну версію; перевірити, що нова реліз розроблена без видалення v2; переглянути журнал змін; налаштувати права доступу; перевірити, що користувач системи без прав не має змогу завантажити файл; виконати ZIP-експорт проєкту; сформувати звіт історії змін; сформувати звіт активності користувачів; перевірити журнал аудиту.; Роль файли; усі версії файлів; метадані файлів; журнал змін; права доступу; структуру проєктів.; !; {\| class="wikitable" style="width:100%;" У звіті потрібно відображати: Що потрібно резервувати
Проєкт	До якого проєкту належить коміт
Автор	Хто виконав зміну
Дата і час	Коли зроблено коміт
характеристика змін	Commit message
Пов’язані файли	Один або кілька файлів
Версії	Які версії створено
Статус	Збережено, відхилено, відновлено

Примітка

додано нову інструкцію;
виправлено помилки в договорі;
оновлено конфігурацію;
додано новий дизайн-макет;
виправлено розрахунок у коді;
оновлено технічну документацію.; {| class="wikitable" style="width:100%;"

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

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

; Опціонально можна налаштувати правила: компонент контролю версій файлів, кодів і документів із журналом змін та можливістю відновлення.; Поле Версії зберігають історію змін файлу.;	; Без системи контролю версій виникають типові проблеми: Дії для журналу експортувати один файл із усіма версіями; експортувати поточні версії проєкту; експортувати архів проєкту; додавати журнал змін у ZIP; формувати структуру папок.; \| історичний розвиток змін, активність користувачів, відновлення версій, права доступу
Що є собою критичною вимогою?; центральний принцип. Жодна зміна не повинна втрачатися: кожна реліз має зберігатися окремо, мати автора, дату, характеристика змін і можливість відновлення.; !; * вести проєкти; створювати структуру файлів у межах проєкту; завантажувати початкові версії файлів; додавати нові версії файлів; зберігати старі версії без перезапису; фіксувати автора кожної зміни; зберігати характеристика зміни — commit message; вести журнал змін; порівнювати дві версії текстових файлів або коду; відновлювати будь-яку попередню версію; позначати поточну активну версію; контролювати доступ до перегляду, редагування, завантаження і відновлення; підтримувати архівування файлів; формувати звіти про зміни; працювати з великими файлами; виконувати ZIP-експорт; створювати резервні копії файлів і версій.;== Порівняння версій — 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-експорт, роботу з великими файлами і звіти.; Критерій

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

Фільтри

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

!; !; істотно. Відновлення старої версії не повинно знищувати новіші версії.; | Створення нової версії на основі старої без видалення історії |- | Які звіти потрібні?; !; платформа має створити нову версію на основі обраної старої.;== Звіт «історичний розвиток змін по проєкту» ==

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

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

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

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

Поля коміту

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

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

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

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

Умова складання. задача не має змогу бути зараховане, якщо платформа не надає можливість пройти базовий цикл контролю версій: проєкт → файл → реліз v1 → реліз v2 → історичний розвиток → diff → відновлення → журнал змін → права доступу → звіт.; перевірки навичок розробника або впроваджувача K2 ERP у створенні модуля контролю версій файлів забезпечується через Атестаційне задача K2 ERP — платформа контролю версій — це практична задача; додатково реалізовано документів.; Разом

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

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

!; {| class="wikitable" style="width:100%;"

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

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

!; Критичними помилками вважаються ситуації, коли: !; Питання У звіті потрібно відображати:

Коротко

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

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

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

Окремо варто відзначити програмного коду, дизайн-макетів і інших цифрових ресурсів.;== Статуси файлу ==

компонент має підтримувати проєкти, типи файлів, файли проєкту, версії файлів, коміти, журнал змін, diff для текстових файлів, відновлення версій, контроль доступу, аудит, роботу з великими файлами, ZIP-експорт, резервні копії, звіти, AJAX-інтерактив і логування дій.; {| class="wikitable" style="width:100%;"

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

!;

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

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

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

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

|-

| Що потрібно для текстових файлів?;

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

ключовий бізнес-процес

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

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

!; характеристика

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

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

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

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

кількість створених версій;
кількість змінених файлів;
кількість відновлень;
останню активність.; {| class="wikitable" style="width:100%;"

TXT;
HTML;
CSS;
JS;
PHP;
Python;
JSON;
XML;
YAML;
SQL;
Markdown;
інші текстові формати.;== Звіт «Права доступу» ==

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

Які довідники потрібні?;== База «Версії файлів» == ZIP-експорт має дозволяти проєкт; файл; хто відновив; яку версію відновлено; коли виконано відновлення; причина або коментар.; Поле платформа має підтримувати права доступу на рівні проєкту, файлу або дії.; У звіті потрібно відображати: за проєктом; за типом файлу; за користувачем; за датою; за статусом; за файлами з помилками завантаження; за архівними файлами; за файлами без актуальної версії.; Колонка платформа має підтримувати резервне копіювання файлів і версій.; Проєкт об’єднує файли, версії і користувачів.; !; Бали
користувач системи	Переглядає доступні проєкти і файли
Редактор	Додає нові версії файлів і характеристика змін
Менеджер проєкту	Керує файлами проєкту, переглядає журнал змін, відновлює версії
Аудитор	Переглядає історію змін і звіти без права редагування
Адміністратор	Керує проєктами, правами, файлами, версіями і резервними копіями
Адміністратор системи	Налаштовує сховище, права, службові параметри і політики зберігання

Мета задача

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

Див.; додатково

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

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

!;

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

платформа повинна дозволяти:

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

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