K2 Update

K2 Update — це система оновлень у екосистемі K2 ERP та K2 Cloud ERP, яка відповідає за контрольоване оновлення ядра, компонентів, модулів, доповнень, інтеграцій, веб-інтерфейсів і технічних частин платформи.

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

Головна ідея. K2 Update — це не просто “завантажити нові файли”. Це процес керованого розвитку ERP: версія, історія змін, сервер оновлень, перевірка компонентів, тестування й контроль сумісності.

Важливо. Оновлення ERP не можна робити як випадковий FTP-патч. У системі, де є фінанси, документи, склад, CRM, користувачі й права доступу, кожне оновлення має бути зрозумілим і відтворюваним.

Критично. Оновлення без версії, без `history.txt`, без Git і без тестування може зламати робочі процеси клієнта.

Що таке K2 Update

K2 Update — це механізм і процес оновлення K2 ERP, який дозволяє передавати нові версії компонентів, модулів і доповнень на сервер оновлень, а потім розгортати їх у потрібних середовищах.

У широкому сенсі K2 Update включає:

Git-репозиторії компонентів;
скрипт `auto_update`;
сервер оновлень;
список компонентів для завантаження;
ignore-файли;
токен доступу;
версію компоненти в `setup.py`;
опис змін у `history.txt`;
команду `k2update_push.py`;
тестові середовища;
перевірку сумісності;
політику stable/testing-релізів.

У вузькому технічному сенсі K2 Update часто пов’язаний із командою:

python k2update_push.py

Але сама команда — це лише фінальний етап. Перед нею потрібно підготувати компоненту, перевірити Git, змінити версію, описати зміни, налаштувати список завантаження й перевірити результат.

Технічний акцент. K2 Update поєднує Git, компоненти, версії, сервер оновлень і тестування в один контрольований процес.

Навіщо потрібна система оновлень

ERP-система постійно розвивається. У ній додаються нові модулі, виправляються помилки, змінюються форми, оновлюються гриди, додаються інтеграції, уточнюються права доступу, покращується продуктивність і з’являються нові галузеві рішення.

Якщо оновлення не контролювати, дуже швидко виникають проблеми:

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

K2 Update потрібен, щоб кожне оновлення було частиною системного процесу, а не випадковою дією розробника.

Перевага. Керована система оновлень зменшує ризики, спрощує підтримку й дозволяє розвивати K2 ERP як платформу, а не як набір локальних доробок.

Що оновлює K2 Update

K2 Update може використовуватися для оновлення різних частин екосистеми K2.

Об’єкт оновлення	Приклади	Навіщо оновлюється
Ядро K2	базові механізми, доступи, API, системні сервіси	Для розвитку платформи
Компоненти	`k2adm`, `k2site`, `k2update`, CRM, документообіг	Для оновлення окремих модулів
Гриди й форми	таблиці, картки, CRUD, фільтри	Для поліпшення інтерфейсів
Інтеграції	банки, SMS, email, Вчасно, маркетплейси	Для стабільного обміну даними
Звіти	управлінські, фінансові, складські, CRM-звіти	Для актуальної аналітики
Доповнення	модулі з магазину доповнень K2	Для розвитку екосистеми
Шаблони	друковані форми, сторінки, налаштування	Для оновлення типових сценаріїв

K2 Update і компонентна архітектура

K2 Update має сенс саме в компонентній архітектурі. Якщо вся ERP — це один моноліт, будь-яке оновлення стає великим і ризикованим. Якщо система складається з компонентів, можна оновлювати конкретну частину: CRM, документообіг, K2Grid, сайт, інтеграцію, звіт або галузевий модуль.

Компонента має мати:

власний код;
власну структуру;
власну версію;
власну історію змін;
залежності;
документацію;
правила встановлення;
правила оновлення;
тестовий сценарій.

Перевага компонентів. Оновлення компоненти простіше контролювати, тестувати й документувати, ніж оновлення всієї системи одразу.

Git як основа оновлень

Перед тим як компонента потрапить на сервер оновлень, її зміни мають бути зафіксовані в Git.

Стандартна логіка роботи:

git status
git add .
git commit -m "Опис зміни"
git pull
git push

Git потрібен для того, щоб команда могла бачити:

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

Важливо. K2 Update не повинен замінювати Git-дисципліну. Спочатку зміни мають бути впорядковані в репозиторії, а вже потім підготовлені до оновлення.

auto_update

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

Скрипт розміщується в корені проєкту на рівні з виконуваним файлом:

app.py

Типовий перехід у каталог:

cd auto_update

Основні команди:

python git_cmd.py clone
python git_cmd.py status
python git_cmd.py commit
python git_cmd.py pull
python git_cmd.py push

`auto_update` особливо корисний, коли проєкт містить багато компонентів. Замість того щоб вручну переходити в кожну папку, розробник може працювати зі списком компонентів централізовано.

Технічний акцент. auto_update — це інструмент для Git-синхронізації компонентів, а не заміна серверу оновлень. Він допомагає підготувати й упорядкувати код.

settings.py в auto_update

У файлі:

auto_update/settings.py

потрібно додати в словник ключі з потрібними компонентами. Повний список компонентів може бути вказаний у:

settings_example.py

Це дозволяє визначити, які компоненти мають бути клоновані або синхронізовані через `auto_update`.

Важливо. Перед запуском `python git_cmd.py clone` потрібно перевірити `settings.py`, щоб не клонувати зайві компоненти й не пропустити потрібні.

Сервер оновлень K2

Сервер оновлень K2 — це середовище, куди завантажуються підготовлені компоненти для подальшого використання в системі оновлень.

Перед завантаженням потрібно налаштувати:

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

Команда завантаження:

python k2update_push.py

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

Каталог builder/config

Налаштування завантаження компонентів на сервер оновлень зберігаються в каталозі:

builder/config

У ньому можуть бути:

`component-list.txt`;
папка `ignore`;
`token.txt`;
інші конфігураційні файли процесу оновлення.

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

component-list.txt

Файл:

builder/config/component-list.txt

містить список компонентів, які потрібно завантажити на сервер оновлень. Кожна компонента додається з нового рядка.

Приклад:

components/k2update
components/k2adm
components/k2site

Цей файл визначає, що саме потрапить у процес публікації.

Важливо. Перед запуском `k2update_push.py` потрібно перевірити `component-list.txt`. Якщо в списку зайва компонента — можна випадково опублікувати не те. Якщо потрібної компоненти немає — вона не потрапить на сервер оновлень.

ignore-файли

У каталозі:

builder/config/ignore

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

Приклад:

k2site.txt

Приклад вмісту:

__pycache__
.gitignore
.git
ej2.min.js

ignore-файли потрібні, щоб не відправляти на сервер оновлень службові, тимчасові, Git-файли, кеші або файли, які не мають бути частиною релізу.

Ризик. Без ignore-файлів на сервер оновлень можуть потрапити `.git`, кеші, тимчасові файли або зайві бібліотеки.

token.txt

Файл:

builder/config/token.txt

містить токен доступу до сервера оновлень.

Критично. Токен доступу не можна комітити у відкритий репозиторій або передавати без контролю. Це службовий доступ до системи оновлень.

Токен потрібен для авторизації під час завантаження компонентів. Доступ до нього мають мати тільки відповідальні розробники або адміністратори релізів.

setup.py і версія компоненти

Перед публікацією нової версії компоненти потрібно оновити її версію у файлі:

setup.py

Приклад:

version = "2.0.4.43"

Також потрібно вказати тип версії.

Для стабільної версії:

version_type = "stable"

Для тестової версії:

version_type = "testing"

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

stable і testing

У K2 Update важливо розрізняти стабільні й тестові версії.

Тип версії	Для чого використовується	Де доречно застосовувати
stable	Перевірена версія для робочого використання	Prod, клієнтські середовища, стабільні релізи
testing	Версія для перевірки, beta або тестування	Dev, Test, deb1-deb3, пілотні середовища

Важливо. testing-версія не повинна випадково потрапляти в бойове середовище як stable-реліз.

history.txt

Файл:

history.txt

містить опис змін у компоненті. Перед публікацією нової версії потрібно додати новий запис у перший рядок.

Приклад:

2.0.4.43 - додано перевірку прав на експорт у журналі документів

`history.txt` потрібен не тільки розробникам. Він допомагає підтримці, партнерам, адміністраторам і клієнтам зрозуміти, що саме змінилося.

Помилка. Оновити код, але не оновити `history.txt` — це погана практика. Через місяць буде складно зрозуміти, що саме входило в реліз.

k2update_push.py

Команда:

python k2update_push.py

виконує завантаження компонентів на сервер оновлень відповідно до налаштувань у `builder/config`.

Перед запуском потрібно перевірити:

Git-статус;
актуальність коду;
версію в `setup.py`;
тип версії;
запис у `history.txt`;
`component-list.txt`;
ignore-файли;
`token.txt`;
готовність до тестування;
залежності компоненти;
сумісність із іншими модулями.

Перед запуском. `k2update_push.py` потрібно виконувати тільки після підготовки релізу, а не як випадкову команду “спробувати завантажити”.

Тестові домени deb1-deb3

Після завантаження нової версії компоненти потрібно перевірити її на тестових доменах:

`deb1`;
`deb2`;
`deb3`.

Тестові домени потрібні, щоб перевірити, як оновлення поводиться в середовищах, близьких до реальної роботи.

Потрібно перевірити:

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

Критично. Завантаження компоненти на сервер оновлень ще не означає, що реліз готовий. Готовність підтверджується тільки після тестування.

Канали релізів

Для екосистеми K2 важливо мати зрозумілі канали релізів.

Можливі канали:

Канал	Призначення	Для кого
Dev	Розробка й експерименти	Розробники
Testing	Перевірка нових версій	QA, технічні партнери, тестові середовища
Beta	Пілотне використання обмеженою групою	Партнери, ранні клієнти
Stable	Стабільний реліз	Робочі середовища
LTS	Довготривала підтримка	Клієнти, яким потрібна максимальна стабільність

Архітектурний сенс. Канали релізів допомагають не змішувати експериментальні, тестові й стабільні оновлення.

Оновлення ядра K2

Оновлення ядра K2 має бути особливо контрольованим, тому що ядро впливає на всю платформу: базу даних, доступи, API, компоненти, гриди, форми, інтеграції та системні сервіси.

Оновлення ядра має проходити за правилами K2 і включати:

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

Критично. Ядро не можна оновлювати так само легко, як окремий невеликий модуль. Помилка в ядрі може вплинути на всю ERP.

Оновлення доповнень

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

Автор доповнення має забезпечити:

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

Важливо для магазину доповнень. Доповнення без версії, документації й перевірки сумісності не повинно потрапляти в стабільний канал екосистеми K2.

Сумісність компонентів

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

Потрібно врахувати:

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

Ризик. Компонента може працювати сама по собі, але ламати залежний модуль. Саме тому потрібна перевірка сумісності.

Політика оновлень для партнерів

У партнерській екосистемі K2 оновлення мають бути керованими. Партнери можуть продавати, впроваджувати, підтримувати, розробляти доповнення й запускати власні хмари, але при цьому мають дотримуватися правил оновлень.

Базові принципи:

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

Екосистемний принцип. Дисципліна оновлень — це частина довіри до K2 як платформи. Партнер, розробник і оператор хмари мають працювати за зрозумілими правилами.

K2 Update і магазин доповнень

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

Для доповнення в магазині важливо мати:

поточну версію;
changelog;
сумісність із версіями K2;
канал релізу;
автора;
інструкцію встановлення;
інструкцію оновлення;
залежності;
правила підтримки;
історію змін;
вимоги до прав доступу.

Marketplace-логіка. Без K2 Update магазин доповнень перетворився б на каталог архівів. Із системою оновлень доповнення можуть розвиватися як керовані продукти.

Оновлення в хмарі K2

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

Для хмари важливо:

мати політику релізів;
планувати вікна оновлень;
повідомляти клієнтів;
перевіряти сумісність;
мати backup;
мати план відкату;
тестувати оновлення до production;
відокремлювати stable і testing;
контролювати доступи до серверу оновлень.

Оновлення в локальному розгортанні

У локальному розгортанні K2 встановлена на інфраструктурі клієнта або партнера. Тут оновлення мають враховувати внутрішні правила компанії.

Потрібно визначити:

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

Важливо для on-premise. Локальне розгортання не означає “оновлюємо як хочемо”. Навпаки, потрібна ще більша дисципліна, бо відповідальність часто лежить на клієнті або партнері.

Backup перед оновленням

Перед важливим оновленням потрібно мати резервну копію. ERP працює з критичними даними, тому оновлення без backup — ризик.

Backup має охоплювати:

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

Критично. Перед оновленням production-середовища має бути backup і зрозумілий план відновлення.

План відкату

План відкату потрібен на випадок, якщо після оновлення виникли критичні помилки.

План має відповідати на питання:

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

Важливо. Оновлення без плану відкату — це технічний ризик, особливо для фінансів, складу, документообігу й CRM.

Журнал оновлень

Журнал оновлень потрібен, щоб бачити історію релізів у системі.

У журналі бажано фіксувати:

компоненту;
версію;
дату оновлення;
тип версії;
автора;
середовище;
опис змін;
результат тестування;
помилки;
відповідального;
посилання на Git-коміт;
дату переходу в stable.

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

Типові помилки при оновленнях

Перша помилка — оновлювати файли вручну через FTP без Git і версії.

Друга помилка — не змінювати `setup.py`.

Третя помилка — не вести `history.txt`.

Четверта помилка — запускати `k2update_push.py` без перевірки `component-list.txt`.

П’ята помилка — не налаштовувати ignore-файли.

Шоста помилка — комітити токени або службові доступи.

Сьома помилка — не перевіряти компоненту на `deb1`–`deb3`.

Восьма помилка — публікувати testing як stable.

Дев’ята помилка — не перевіряти залежні модулі.

Десята помилка — не мати backup і плану відкату.

Критично. Найнебезпечніше оновлення — те, про яке ніхто не може сказати: що змінилося, хто змінив, яка версія й де це перевіряли.

Чек-лист перед публікацією оновлення

Код перевірено локально.
Виконано `git status`.
Зміни закомічено.
Виконано `git pull`.
Конфлікти відсутні.
Зміни запушено.
Версію оновлено в `setup.py`.
Тип версії визначено: `stable` або `testing`.
Опис змін додано в `history.txt`.
Компоненту додано в `component-list.txt`.
ignore-файл перевірено.
`token.txt` на місці й не потрапляє в Git.
Залежності перевірено.
Backup підготовлено, якщо оновлення важливе.
Запущено `python k2update_push.py`.
Оновлення перевірено на тестовому середовищі.
Логи перевірено.
Відомі помилки зафіксовано.
Рішення про stable прийнято відповідальним.

Чек-лист після оновлення

Компонента встановилась без помилок.
Версія відповідає очікуваній.
Основні сторінки відкриваються.
Форми зберігаються.
Гриди працюють.
Права доступу не зламані.
Імпорт і експорт працюють, якщо були змінені.
Інтеграції не впали.
Логи перевірені.
Користувачі не бачать критичних помилок.
Залежні модулі перевірені.
Документація оновлена.
Підтримка знає, що змінилося.

Як зрозуміти, що K2 Update працює правильно

K2 Update працює правильно, якщо кожне оновлення має версію, опис, джерело в Git, зрозумілий список компонентів, контроль ignore-файлів, перевірений токен, тестовий контур, журнал результатів і стабільний канал релізу.

Ознаки правильної системи оновлень:

немає ручних FTP-патчів без історії;
компоненти мають версії;
зміни описані в `history.txt`;
розробники працюють через Git;
сервер оновлень використовується контрольовано;
testing і stable не змішуються;
партнери розуміють політику релізів;
клієнти не отримують випадкові незавершені оновлення;
є backup і план відкату;
помилки після оновлень можна відстежити.

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

Поширені запитання

Що таке K2 Update?

K2 Update — це система оновлень K2 ERP та K2 Cloud ERP, яка допомагає керовано оновлювати ядро, компоненти, модулі, доповнення й інтеграції через версії, Git, сервер оновлень, `setup.py`, `history.txt` і тестування.

Що таке auto_update?

`auto_update` — це скрипт для роботи зі списком компонентів у Git: клонування, перевірка статусу, commit, pull і push.

Що робить k2update_push.py?

`k2update_push.py` завантажує компоненти на сервер оновлень відповідно до налаштувань у `builder/config`.

Для чого потрібен component-list.txt?

`component-list.txt` визначає, які компоненти потрібно завантажити на сервер оновлень.

Для чого потрібен history.txt?

`history.txt` містить опис змін у компоненті. Він потрібен для підтримки, партнерів, тестування й розуміння історії релізів.

Чим stable відрізняється від testing?

`stable` — це перевірена версія для робочого використання. `testing` — версія для тестування, beta-сценаріїв або перевірки на тестових середовищах.

Чому потрібно тестувати на deb1-deb3?

Тестові домени `deb1`, `deb2`, `deb3` потрібні для перевірки встановлення, сумісності й роботи компоненти перед використанням у стабільному середовищі.

Чи можна оновлювати компоненти вручну?

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

Пов’язані сторінки

SEO-призначення сторінки

Сторінка K2 Update має допомагати користувачам, розробникам, партнерам і пошуковим системам зрозуміти, як у K2 ERP організовано оновлення: компоненти, Git, auto_update, сервер оновлень, k2update_push.py, setup.py, history.txt, stable/testing-версії, component-list.txt, ignore, token.txt, тестування на deb1-deb3, політика релізів і контроль сумісності.

Вона покриває запити: “K2 Update”, “K2 ERP Update”, “система оновлень K2”, “оновлення K2 ERP”, “k2update_push.py”, “auto_update K2”, “сервер оновлень K2”, “component-list.txt K2”, “setup.py K2”, “history.txt K2”, “stable testing K2”, “оновлення компонентів K2 ERP”, “релізи K2 ERP”, “українська ERP оновлення”.

Коротко

K2 Update — це система керованих оновлень для K2 ERP та K2 Cloud ERP. Вона допомагає оновлювати ядро, компоненти, модулі й доповнення через Git, версії, сервер оновлень, опис змін, stable/testing-канали й тестові середовища.

Головна цінність K2 Update — контроль. Команда бачить, що оновлюється, яка версія встановлена, що змінилося, хто відповідає, де тестували й чи готовий реліз до стабільного використання.

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

Див. також

Що таке K2 Update

Навіщо потрібна система оновлень

Що оновлює K2 Update

K2 Update і компонентна архітектура

Git як основа оновлень

auto_update

settings.py в auto_update

Сервер оновлень K2

Каталог builder/config

component-list.txt

ignore-файли

token.txt

setup.py і версія компоненти

stable і testing

history.txt

k2update_push.py

Рекомендований порядок оновлення компоненти

Тестові домени deb1-deb3

Канали релізів

Оновлення ядра K2

Оновлення доповнень

Сумісність компонентів

Політика оновлень для партнерів

K2 Update і магазин доповнень

Оновлення в хмарі K2

Оновлення в локальному розгортанні

Backup перед оновленням

План відкату

Журнал оновлень

Типові помилки при оновленнях

Чек-лист перед публікацією оновлення

Чек-лист після оновлення

Як зрозуміти, що K2 Update працює правильно

Поширені запитання

Що таке K2 Update?

Що таке auto_update?

Що робить k2update_push.py?

Для чого потрібен component-list.txt?

Для чого потрібен history.txt?

Чим stable відрізняється від testing?

Чому потрібно тестувати на deb1-deb3?

Чи можна оновлювати компоненти вручну?

Пов’язані сторінки

SEO-призначення сторінки

Коротко

Див. також