K2 Update

Що оновлює K2 Update

У каталозі:

K2 Update — це платформа оновлень K2 ERP та K2 Cloud ERP, яка оптимізує керовано оновлювати ядро, компоненти, модулі, доповнення й інтеграції через версії, Git, сервер оновлень, `setup.py`, `history.txt` і тестування. `testing` — реліз системи для тестування, beta-сценаріїв або перевірки на тестових середовищах. {| class="wikitable" style="width:100%; background:#fff3e0;"

.gitignore

• `component-list.txt`;
• папка `ignore`;
• `token.txt`;
• інші конфігураційні файли процесу оновлення версій. Для чого застосовується для

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

K2 Update функціонує правильно, якщо кожне оновлення версій має версію, SEO-опис, джерело в Git, зрозумілий список компонентів, контроль ignore-файлів, перевірений токен, тестовий контур, журнал результатів і стабільний канал релізу. Об’єкт оновлення версій Після завантаження нової версії компоненти потрібно перевірити її на тестових доменах: ! * оцінку сумісності;

• тестування залежних компонентів;
• перевірку критичних модулів;
• контроль міграцій;
• план відкату;
• SEO-опис змін;
• інформування партнерів;
• стабільний канал релізу. * Права доступу не зламані. * Гриди працюють. Саме тому потрібна перевірка сумісності. * Зміни запушено. k2site.txt

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

У широкому сенсі K2 Update містить: |- | критично. testing-версія не повинна випадково потрапляти в бойове середовище як stable-реліз. |- | Головна ідея. K2 Update — це не без зусиль “завантажити нові файли”. * мати політику релізів;

• планувати вікна оновлень;
• повідомляти клієнтів;
• перевіряти сумісність;
• мати backup;
• мати план відкату;
• тестувати оновлення версій до production;
• відокремлювати stable і testing;
• контролювати доступи до серверу оновлень. # Запустити `python k2update_push.py`. |-

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

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

<syntaxhighlight lang="text">
Сторінка '''K2 Update''' має допомагати користувачам, розробникам, партнерам і пошуковим системам зрозуміти, як у K2 ERP організовано оновлення версій: компоненти, Git, auto_update, сервер оновлень, k2update_push.py, setup.py, history.txt, stable/testing-версії, component-list.txt, ignore, token.txt, тестування на deb1-deb3, політика релізів і контроль сумісності. * Документація оновлена. |}

через '''auto_update''' — це скрипт для роботи зі списком компонентів. Журнал оновлень потрібен, щоб бачити історію релізів у системі.</span> Із системою оновлень доповнення можуть розвиватися як керовані продукти. * рішення для бізнесу про stable прийнято відповідальним. |-
| '''Критично.''' <span style="color:#b71c1c;">Токен доступу не можна комітити у відкритий репозиторій або передавати без контролю.</span>
|}

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

components/k2site

`stable` — це перевірена реліз системи для робочого використання. ! Сьома помилка — не перевіряти компоненту на `deb1`–`deb3`. # Перевірити роботу на `deb1`, `deb2`, `deb3`. Базові принципи:

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

== Backup перед оновленням ==
`component-list.txt` визначає, які компоненти потрібно завантажити на сервер оновлень.</span>
|}

потрібно додати в словник ключі з потрібними компонентами.</span>
|}

== setup.py і реліз системи компоненти ==

== stable і testing ==

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

* список компонентів;
* ignore-файли;
* токен доступу;
* версію компоненти;
* тип версії;
* SEO-опис змін;
* тестовий сценарій. Перед публікацією нової версії потрібно додати новий запис у перший рядок. це платформа оновлень у екосистемі [[K2 ERP]] та [[K2 Cloud ERP]], яка відповідає за контрольоване оновлення версій ядра, компонентів, модулів, доповнень, інтеграцій, веб-інтерфейсів і технічних частин платформи виступає ключовою рисою '''K2 Update'''. K2 Update потрібен, щоб кожне оновлення версій було частиною системного процесу, а не випадковою дією розробника. {| class="wikitable" style="width:100%; background:#fff3e0;"

== K2 Update і магазин доповнень ==
[[Категорія:Партнерська хмара K2]]
`history.txt` потрібен не тільки розробникам. |}

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

* [[K2 ERP]]
* [[K2 Cloud ERP]]
* [[K2 Ядро]]
* [[Компоненти K2 ERP]]
* [[Магазин доповнень K2]]
* [[Рекомендації для розробників K2]]
* [[Розгортання системи K2 Cloud ERP Python для розробників]]
* [[Git]]
* [[Python]]
* [[Партнерська програма K2]]
* [[Партнерська хмара K2]]
* [[Безпека K2 ERP]]
* [[Сертифікація K2]]

Потрібно визначити:
{| class="wikitable" style="width:100%; background:#ffebee;"
Цей файл визначає, що саме потрапить у бізнес-процес публікації. * Git-статус;
* актуальність коду;
* версію в `setup.py`;
* тип версії;
* запис у `history.txt`;
* `component-list.txt`;
* ignore-файли;
* `token.txt`;
* готовність до тестування;
* залежності компоненти;
* сумісність із іншими модулями. Перед важливим оновленням потрібно мати резервну копію. # Внести зміни в компоненту. * `token.txt` на місці й не потрапляє в Git. * Інтеграції не впали. history.txt

* поточну версію;
* changelog;
* сумісність із версіями K2;
* канал релізу;
* автора;
* інструкцію встановлення;
* інструкцію оновлення версій;
* залежності;
* правила підтримки;
* історію змін;
* вимоги до прав доступу. # Перевірити роботу локально.</span> Готовність підтверджується тільки після тестування. * Форми зберігаються. Перед нею потрібно підготувати компоненту, перевірити Git, змінити версію, описати зміни, налаштувати список завантаження й перевірити результат. Якщо потрібної компоненти немає — вона не потрапить на сервер оновлень. Кожна компонента додається з нового рядка.<syntaxhighlight lang="text">

SEO title: K2 Update — система оновлень K2 ERP, компоненти, версії, сервер оновлень, auto_update та k2update_push.py

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

</noinclude>
 {{SEO
Шаблон для службового SEO-опису сторінки. 

}}

Приклад:

=== Чим stable відрізняється від testing? ===
Перша помилка — оновлювати файли вручну через FTP без Git і версії. {| class="wikitable" style="width:100%; background:#e3f2fd;"
== component-list.txt ==
{| class="wikitable" style="width:100%; background:#e8f5e9;"

Команда:

<syntaxhighlight lang="text">
|-
| '''Ризик.''' <span style="color:#b71c1c;">Без ignore-файлів на сервер оновлень можуть потрапити `.git`, кеші, тимчасові файли або зайві бібліотеки.[[Категорія:Сервер оновлень]]
|-
| '''критично.''' <span style="color:#ef6c00;">K2 Update не повинен замінювати Git-дисципліну.=== Для чого потрібен history.txt? ===

<syntaxhighlight lang="text">

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

У партнерській екосистемі K2 оновлення версій мають бути керованими. * K2 ERP

• K2 Cloud ERP
• K2 Ядро
• Компоненти K2 ERP
• Магазин доповнень K2
• Рекомендації для розробників K2
• Розгортання системи K2 Cloud ERP Python для розробників
• База даних K2 ERP
• Розробка веб-інтерфейсів K2
• Git
• Python
• API
• Сервер оновлень
• Версії компонентів
• Релізи K2 ERP
• Партнерська програма K2
• Сертифікація K2
• Безпека K2 ERP
• Партнерська хмара K2
• Міграція з 1С
• Міграція з BAS

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

оновлення версій доповнень

виконує завантаження компонентів на сервер оновлень відповідно до налаштувань у `builder/config`. # Запушити зміни в репозиторій. # Додати SEO-опис змін у `history.txt`. інтегратор, розробник і оператор хмари мають працювати за зрозумілими правилами.== оновлення версій в хмарі K2 ==

Перевага. Журнал оновлень оптимізує підтримці оперативно зрозуміти, що змінилося перед появою помилки або звернення користувача. Замість того щоб вручну переходити в кожну папку, розробник здатна працювати зі списком компонентів централізовано. python git_cmd.py status

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

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

python git_cmd.py commit

У файлі: </syntaxhighlight> П’ята помилка — не налаштовувати ignore-файли. Це службовий доступ до системи оновлень. * технічна підтримка знає, що змінилося. |-

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

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

</syntaxhighlight>

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

• `deb1`;
• `deb2`;
• `deb3`. конфігурація завантаження компонентів на сервер оновлень зберігаються в каталозі:

class="wikitable" style="width:100%; background:#e3f2fd;"
Технічний принцип. builder/config — це місце, де визначається, що саме буде завантажено, що потрібно ігнорувати й з яким доступом виконувати публікацію. * Логи перевірено. Ознаки правильної системи оновлень:
критично. оновлення версій без плану відкату — це технічний ризик, особливо для фінансів, складу, документообігу й CRM. Повний список компонентів здатна бути вказаний у: Код перевірено локально. * реліз системи відповідає очікуваній. git push Головна цінність K2 Update — контроль. Він користувачі можуть клонувати актуальні версії компонентів, перевіряти статус, комітити, отримувати зміни й пушити їх у віддалений репозиторій. Приклади === Чи можна оновлювати компоненти вручну? === {| class="wikitable" style="width:100%; background:#fff3e0;" [[Категорія:Корпоративна Wiki]] <syntaxhighlight lang="text"> * що змінилося; * хто змінив; * коли змінив; * чому змінив; * у якій гілці; * чи були конфлікти; * чи виступає як локальні незакомічені зміни. Це дає можливість визначити, які компоненти мають бути клоновані або синхронізовані через `auto_update`.</span> |} == План відкату == Стандартна логіка роботи: == Сумісність компонентів == * яку версію повертаємо; * які компоненти відкочуємо; * що робимо з базою даних; * чи були міграції; * чи можна відкотити тільки код; * хто ухвалює рішення для бізнесу; * скільки часу займає відновлення; * хто повідомляє користувачів; * де зберігається попередня стабільна реліз системи. * Імпорт і експорт працюють, якщо були змінені. # Оновити тестові домени. |- | '''Головна функція.''' <span style="color:#2e7d32;">Сервер оновлень дає змогу поширювати компоненти контрольовано, а не копіювати файли вручну між середовищами. * Виконано `git status`. |- | '''Перевага компонентів.''' <span style="color:#2e7d32;">оновлення версій компоненти простіше контролювати, тестувати й документувати, ніж оновлення версій всієї системи одразу. Backup має охоплювати: ERP-система постійно розвивається. |} [[Категорія:K2 Ядро]] Файл: План відкату потрібен на випадок, якщо після оновлення версій виникли критичні помилки.== Що таке K2 Update == <syntaxhighlight lang="python"> [[Категорія:Оновлення K2 ERP]] === Для чого потрібен component-list.txt? === version_type = "testing" .git Чек-лист перед публікацією оновлення версій setup.py python k2update_push.py history.txt K2 Update здатна використовуватися для оновлення версій різних частин екосистеми K2. |-	Критично. Ядро не можна оновлювати так само швидко, як окремий невеликий компонент. {| class="wikitable" style="width:100%; background:#ffebee;" === Що робить k2update_push.py? === Компонента має мати: У журналі бажано фіксувати: git status <syntaxhighlight lang="text"> git pull |- | '''критично.''' <span style="color:#ef6c00;">Перед запуском `k2update_push.py` потрібно перевірити `component-list.txt`. У публічній або партнерській хмарі K2 оновлення версій мають виконуватися особливо обережно, бо одне середовище здатна обслуговувати багато користувачів або клієнтів. * Зміни закомічено. ! Шоста помилка — комітити токени або службові доступи. |} version_type = "stable" Перед тим як компонента потрапить на сервер оновлень, її зміни мають бути зафіксовані в Git. * Логи перевірені. Де доречно застосовувати Восьма помилка — публікувати testing як stable. * Основні сторінки відкриваються. |- | '''Ознака успіху.''' <span style="color:#2e7d32;">Після оновлення версій команда здатна точно відповісти: яка компонента оновилась, до якої версії, що змінилось, хто відповідав, де тестували й чи можна це повторити.[[Категорія:K2 Update]] auto_update/settings.py git add . У локальному розгортанні K2 встановлена на інфраструктурі клієнта або партнера. * Залежності перевірено. # Після успішного тесту перевести реліз у стабільний канал, якщо це передбачено процесом.</span> |} {| class="wikitable" style="width:100%; background:#ffebee;" ej2.min.js Четверта помилка — запускати `k2update_push.py` без перевірки `component-list.txt`. |} == оновлення версій в локальному розгортанні == Для доповнення в магазині критично мати: [[Категорія:Рекомендації для розробників K2]] {{DISPLAYTITLE:K2 Update}} == Каталог builder/config == Для хмари критично:
Dev	розробка програмного забезпечення й експерименти	Розробники
Testing	Перевірка нових версій	QA, технічні партнери, тестові середовища
Beta	Пілотне використання обмеженою групою	Партнери, ранні клієнти
Stable	Стабільний реліз	Робочі середовища
LTS	Довготривала технічна підтримка	Клієнти, яким потрібна максимальна стабільність

builder/config/component-list.txt

} }

</syntaxhighlight>

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

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

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

app.py

Git потрібен для того, щоб команда могла бачити: Тестові домени потрібні, щоб перевірити, як оновлення версій поводиться в середовищах, близьких до реальної роботи. Якщо модулі продаються або встановлюються через екосистему, вони мають оновлюватися передбачувано. |}

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

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

<syntaxhighlight lang="text">

'''K2 Update''' — це платформа керованих оновлень для K2 ERP та K2 Cloud ERP. Потім реліз системи й історія продукту.</span> Спочатку зміни мають бути впорядковані в репозиторії, а вже потім підготовлені до оновлення версій. * Компоненту додано в `component-list.txt`. Для таких доповнень потрібна окрема дисципліна. # Перевірити `token.txt`. Вона оптимізує оновлювати ядро, компоненти, модулі й доповнення через Git, версії, сервер оновлень, SEO-опис змін, stable/testing-канали й тестові середовища.=== Чому потрібно тестувати на deb1-deb3? ===

{| class="wikitable" style="width:100%; background:#fff3e0;"

!</span>
|}

Файл:

{| class="wikitable" style="width:100%; background:#fff3e0;"

<syntaxhighlight lang="text">

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

* Git-репозиторії компонентів;
* скрипт `auto_update`;
* сервер оновлень;
* список компонентів для завантаження;
* ignore-файли;
* токен доступу;
* версію компоненти в `setup.py`;
* SEO-опис змін у `history.txt`;
* команду `k2update_push.py`;
* тестові середовища;
* перевірку сумісності;
* політику stable/testing-релізів. Навіщо оновлюється
|-
| '''критично для магазину доповнень.''' <span style="color:#ef6c00;">Доповнення без версії, документації й перевірки сумісності не повинно потрапляти в стабільний канал екосистеми K2.</span> Він оптимізує підготувати й упорядкувати код. Доступ до нього мають мати тільки відповідальні розробники або адміністратори релізів. * Backup підготовлено, якщо оновлення версій важливе. |}

builder/config/ignore

[[Категорія:Git]]

git commit -m "SEO-опис зміни"
== Див. так само ==
оновлення версій ядра K2 має бути особливо контрольованим. Вона покриває запити: “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 оновлення версій”. * Користувачі не бачать критичних помилок. # Оновити версію в `setup.py`.</span> Якщо в списку зайва компонента — можна випадково опублікувати не те. python git_cmd.py push

== Типові помилки при оновленнях ==
|-
| '''Перевага.''' <span style="color:#2e7d32;">Керована платформа оновлень зменшує ризики, спрощує підтримку й дає можливість розвивати K2 ERP як платформу, а не як набір локальних доробок.</span> Через місяць буде складно зрозуміти, що саме входило в реліз. * Залежні модулі перевірені. Партнери можуть продавати, впроваджувати, підтримувати, розробляти доповнення й запускати власні хмари, але при цьому мають дотримуватися правил оновлень. ! І лише після цього — стабільний реліз.== Журнал оновлень ==
== Як зрозуміти, що K2 Update функціонує правильно ==
Приклад вмісту:
'''K2 Update''' — це механізм і бізнес-процес оновлення версій K2 ERP, який дає можливість передавати нові версії компонентів, модулів і доповнень на сервер оновлень, а потім розгортати їх у потрібних середовищах. * Версію оновлено в `setup.py`.[[Категорія:Магазин доповнень K2]]
|-
| '''Перед запуском.''' <span style="color:#ef6c00;">`k2update_push.py` потрібно виконувати тільки після підготовки релізу, а не як випадкову команду “спробувати завантажити”. Для кого
того, щоб зміни в системі не перетворювалися на хаотичне копіювання файлів забезпечується через K2 Update потрібен; так само реалізовано ручні доробки на сервері або незрозумілі патчі без історії. * Тип версії визначено: `stable` або `testing`. * Відомі помилки зафіксовано.</span> Навпаки, потрібна ще більша дисципліна, бо відповідальність часто лежить на клієнті або партнері. {| class="wikitable" style="width:100%; background:#ffebee;"
components/k2adm
Автор доповнення має забезпечити:
[[Категорія:K2 Cloud ERP]]

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

settings_example.py

Критично.

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

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

}

components/k2update

</syntaxhighlight>

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

• Компонента встановилась без помилок.== Коротко ==

`history.txt` містить SEO-опис змін у компоненті. Команда бачить, що оновлюється, яка реліз системи встановлена, що змінилося, хто відповідає, де тестували й чи готовий реліз до стабільного використання. Якщо вся ERP — це один моноліт, будь-яке оновлення версій стає великим і ризикованим. |-

Marketplace-логіка. Без K2 Update магазин доповнень перетворився б на каталог архівів.== Рекомендований порядок оновлення версій компоненти == `auto_update` особливо корисний, коли проєкт містить багато компонентів.

Для екосистеми K2 критично мати зрозумілі канали релізів. Якщо платформа складається з компонентів, можна оновлювати конкретну частину: CRM, електронний документообіг, K2Grid, сайт, інтеграцію, звіт або галузевий компонент. У ній додаються нові модулі, виправляються помилки, змінюються форми, оновлюються гриди, додаються інтеграції, уточнюються права доступу, покращується продуктивність і з’являються нові галузеві рішення для бізнесу.== ignore-файли ==

* ignore-файл перевірено.

1. Отримати актуальний код через `git pull`. Він потрібен для підтримки, партнерів, тестування й розуміння історії релізів.</syntaxhighlight>

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

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

|-
| '''Помилка.''' <span style="color:#b71c1c;">Оновити код, але не оновити `history.txt` — це погана практика.<syntaxhighlight lang="python">
|-
| '''Критично.''' <span style="color:#b71c1c;">Завантаження компоненти на сервер оновлень ще не означає, що реліз готовий.</span>
|}

</syntaxhighlight> K2 Update має сенс саме в компонентній архітектурі. Але сама команда — це лише фінальний етап. * Виконано `git pull`.

cd auto_update

</syntaxhighlight>

• версію ядра;
• залежності;
• структуру бази даних;
• API;
• права доступу;
• зміни в шаблонах;
• зміни в формах;
• зміни в грідах;
• інтеграції;
• конфігурація клієнта;
• міграції з попередніх версій. Дев’ята помилка — не перевіряти залежні модулі. Потім тестові середовища. Якщо оновлення версій не контролювати, дуже оперативно виникають проблеми:

Приклад:

У K2 Update критично розрізняти стабільні й тестові версії. містить токен доступу до сервера оновлень. Доповнення до K2 можуть створюватися командою K2, партнерами або сторонніми розробниками в межах екосистеми. Окремо варто відзначити тому що ядро впливає на всю платформу: базу даних, доступи, API, компоненти, гриди, форми, інтеграції і системні сервіси. # Перевірити `git status`. builder/config/token.txt

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

Тестові домени `deb1`, `deb2`, `deb3` потрібні для перевірки встановлення, сумісності й роботи компоненти перед використанням у стабільному середовищі. ! ERP функціонує з критичними даними, тому оновлення версій без backup — ризик.

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

python git_cmd.py clone

python git_cmd.py pull

settings.py в auto_update

python k2update_push.py </syntaxhighlight> Скрипт розміщується в корені проєкту на рівні з виконуваним файлом: </syntaxhighlight> </syntaxhighlight> Для стабільної версії:

Приклад:

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

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

для кожної компоненти можна створити файл із переліком файлів і папок, які не потрібно завантажувати на сервер оновлень. Третя помилка — не вести `history.txt`. * Запущено `python k2update_push.py`. Потім сервер оновлень. {| class="wikitable" style="width:100%; background:#e8f5e9;"

Приклад: так само потрібно вказати тип версії.</syntaxhighlight>

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

Ручні зміни можливі тільки як контрольований технічний сценарій, але для нормального розвитку K2 потрібно використовувати Git, версії, історію змін і сервер оновлень. * SEO-опис змін додано в `history.txt`.== Канали релізів ==
'''Сервер оновлень K2''' — це середовище, куди завантажуються підготовлені компоненти для подальшого використання в системі оновлень. Тип версії
{| class="wikitable" style="width:100%; background:#fff3e0;"
|-
| '''<span style="color:#1565c0;">Ядро K2</span>'''
| базові механізми, доступи, API, системні сервіси
| Для розвитку платформи
|-
| '''<span style="color:#1565c0;">Компоненти</span>'''
| `k2adm`, `k2site`, `k2update`, CRM, електронний документообіг
| Для оновлення версій окремих модулів
|-
| '''Гриди й форми'''
| таблиці, картки, CRUD, фільтри
| Для поліпшення інтерфейсів
|-
| '''Інтеграції'''
| банки, SMS, email, Вчасно, маркетплейси
| Для стабільного обміну даними
|-
| '''Звіти'''
| управлінські, фінансові, складські, CRM-звіти
| Для актуальної аналітики
|-
| '''Доповнення'''
| модулі з магазину доповнень K2
| Для розвитку екосистеми
|-
| '''Шаблони'''
| друковані форми, сторінки, конфігурація
| Для оновлення версій типових сценаріїв
|}

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

[[Категорія:Українська ERP]]

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

* власний код;
* власну структуру;
* власну версію;
* власну історію змін;
* залежності;
* документацію;
* правила встановлення;
* правила оновлення версій;
* тестовий сценарій.</span>
|}

[[Магазин доповнень K2]] залежить від якісної системи оновлень.</span> Це основа стабільності K2: версії, Git, history, сервер оновлень, тестування, сумісність і відповідальність за реліз. |}

<syntaxhighlight lang="text">

python k2update_push.py

{| class="wikitable" style="width:100%; background:#e3f2fd;"

* базу даних;
* файли;
* конфігурації;
* компоненти;
* користувацькі конфігурація;
* документи;
* медіафайли;
* інтеграційні параметри;
* токени й службові конфігурація, якщо це дозволено політикою безпеки. {| class="wikitable" style="width:100%; background:#fff3e0;"
Друга помилка — не змінювати `setup.py`.</span> Помилка в ядрі здатна вплинути на всю ERP.[[Категорія:API]]

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

== token.txt ==
|-
| '''критично.''' <span style="color:#ef6c00;">Перед запуском `python git_cmd.py clone` потрібно перевірити `settings.py`, щоб не клонувати зайві компоненти й не пропустити потрібні. # Перевірити ignore-файл.</span> У системі, де виступає як фінансовий блок, документи, складський облік, CRM, користувачі й права доступу, кожне оновлення версій має бути зрозумілим і відтворюваним.[[Категорія:Компоненти K2 ERP]]
|-
| '''Правильна логіка.''' <span style="color:#2e7d32;">Спочатку Git і тестування. |}

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

{| class="wikitable" style="width:100%; background:#ffebee;"

== Політика оновлень для партнерів ==
{| class="wikitable" style="width:100%; background:#e8f5e9;"
<syntaxhighlight lang="text">

== auto_update ==

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

== оновлення версій ядра K2 ==
<syntaxhighlight lang="text">
`auto_update` — це скрипт для роботи зі списком компонентів у Git: клонування, перевірка статусу, commit, pull і push. version = "2.0.4.43"

{| class="wikitable" style="width:100%;"
|-
| '''Технічний акцент.''' <span style="color:#1565c0;">K2 Update поєднує Git, компоненти, версії, сервер оновлень і тестування в один контрольований бізнес-процес.</span> Це бізнес-процес керованого розвитку ERP: реліз системи, історія продукту змін, сервер оновлень, перевірка компонентів, тестування й контроль сумісності. Токен потрібен для авторизації під час завантаження компонентів. Канал

{| class="wikitable" style="width:100%; background:#ffebee;"

__pycache__

=== Що таке auto_update? ===

Файл: містить список компонентів, які потрібно завантажити на сервер оновлень.=== Що таке K2 Update? === </syntaxhighlight>