Перейти до вмісту

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

Матеріал з K2 ERP Wiki

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

! * програмний код;

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

Див. так само

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

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

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

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

через Тип файлу користувачі можуть фільтрувати і правильно опрацьовувати версії. У звіті потрібно відображати: !== базовий бізнес-процес ==

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

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

|}

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

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

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

|- | Які звіти потрібні? | Diff між версіями |- | Що потрібно для відновлення?== Приклади commit message ==

  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. перевірити журнал аудиту. Бали
  • додано нову інструкцію;
  • виправлено помилки в договорі;
  • оновлено конфігурацію;
  • додано новий дизайн-макет;
  • виправлено розрахунок у коді;
  • оновлено технічну документацію. Відповідь
!
  • проєкт;
  • файл;
  • хто відновив;
  • яку версію відновлено;
  • коли виконано відновлення;
  • причина або коментар.
  • неможливо створити проєкт;
  • неможливо створити файл;
  • початкова реліз системи не створюється;
  • нова реліз системи перезаписує стару;
  • неможливо переглянути історію версій;
  • неможливо визначити поточну версію;
  • commit message не зберігається;
  • автор змін не фіксується;
  • diff не функціонує для текстових файлів, якщо заявлений у реалізації;
  • відновлення старої версії видаляє новіші версії;
  • користувач системи без прав здатна завантажити або відновити файл;
  • журнал змін не фіксує ключові дії;
  • ZIP-експорт не враховує права доступу;
  • звіти не відповідають фактичним змінам.== База «Файли проєкту» ==

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

  1. користувач системи створює проєкт;
  2. у проєкті створюється файл або завантажується початкова реліз системи;
  3. платформа створює версію v1;
  4. користувач системи редагує файл локально або готує нову версію;
  5. завантажує нову версію в систему;
  6. вказує SEO-опис змін;
  7. платформа створює версію v2;
  8. стара реліз системи залишається в історії;
  9. користувач системи здатна порівняти v1 і v2;
  10. менеджер або адміністратор здатна переглянути журнал змін;
  11. у разі помилки користувач системи відновлює попередню версію;
  12. платформа створює нову версію на основі відновленої;
  13. усі дії потрапляють у журнал аудиту.
Коміт — це логічна зміна одного або кількох файлів. Параметр компонент має підтримувати проєкти, типи файлів, файли проєкту, версії файлів, коміти, журнал змін, diff для текстових файлів, відновлення версій, контроль доступу, аудит, роботу з великими файлами, ZIP-експорт, резервні копії, звіти, AJAX-інтерактив і логування дій. | історія продукту змін, активність користувачів, відновлення версій, права доступу
Що виступає як критичною вимогою? Поле

Поля файлу

ZIP-імпорт здатна дозволяти

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

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

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

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

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

Примітка

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

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

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

Поля коміту

Назва задача

 Об’єкт

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

платформа контролю версій — це практична задача; так само реалізовано документів, програмного коду, дизайн-макетів та інших цифрових ресурсів виступає ключовою рисою перевірки навичок розробника або впроваджувача K2 ERP у створенні модуля контролю версій файлів забезпечується через Атестаційне задача K2 ERP.== Шкала оцінювання == Через AJAX мають працювати:

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

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

Опціонально платформа здатна підтримувати роботу з архівами.== Критичні помилки ==

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

Коротко

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

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

Поля проєкту

! Бали

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

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

Критично. користувач системи без відповідних прав не повинен бачити закритий проєкт, завантажувати файли, додавати нові версії або відновлювати попередні версії. | Проєкти, типи файлів, ролі доступу |- | Який провідний об’єкт?== Що має показувати diff ==

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

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

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

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

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

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

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

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

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

! | Файл із версіями |-

| Що таке реліз системи?

! | Збережений стан файлу з автором, датою і описом змін |- | Що потрібно для текстових файлів? Що перевіряється

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

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

Коміти

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

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

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

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

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

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

Бекенд 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
Безпека Рольова модель доступу, аудит, журнал дій

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

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

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

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

! Окремо від журналу змін файлів бажано вести аудит системних дій. платформа має створити нову версію на основі обраної старої.== ZIP-імпорт і ZIP-експорт == !== Логування і аудит ==

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

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

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

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

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

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

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

! SEO-опис

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

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

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

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

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

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

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

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

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

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

Звіти

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

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

Мета задача

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

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

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

Журнал змін

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

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

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

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

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

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

  • завантажити кілька файлів одночасно;
  • автоматизовано створити файли у проєкті;
  • зберегти структуру папок;
  • створити початкові версії для кожного файлу. Максимальна оцінка
== Робота з великими файлами ==
Отримано з https://wiki.kyiv.ua/index.php?title=Атестаційні_завдання_K2_ERP/Система_контролю_версій&oldid=562