K2 Update
</syntaxhighlight>
</syntaxhighlight>
Чек-лист після актуалізація
|-
| '''Головна ідея.''' <span style="color:#2e7d32;">K2 Update — це не без ускладнень “завантажити нові файли”.; Він потрібен для підтримки, партнерів, тестування й розуміння історії релізів.;</span> Це основа стабільності K2: версії, Git, history, сервер оновлень, тестування, сумісність і відповідальність за реліз.;</span>
|}
builder/config/token.txt
git add .; |}
Рекомендований порядок актуалізація компоненти
ignore-файли потрібні, щоб не відправляти на сервер оновлень службові, тимчасові, Git-файли, кеші або файли, які не мають бути частиною релізу.; version_type = "testing" |- | Критично. Перед оновленням production-середовища має бути backup і зрозумілий план відновлення.; |}
Навіщо потрібна платформа оновлень
Перед важливим оновленням потрібно мати резервну копію.; # Перевірити `token.txt`.;== План відкату == |- | Ризик. Без ignore-файлів на сервер оновлень можуть потрапити `.git`, кеші, тимчасові файли або зайві бібліотеки.; K2 Update потрібен, щоб кожне актуалізація було частиною системного процесу, а не випадковою дією розробника.; Повний список компонентів має змогу бути вказаний у:
Для тестової версії:
- компоненту;
- версію;
- дату актуалізація;
- тип версії;
- автора;
- середовище;
- характеристика змін;
- результат тестування;
- помилки;
- відповідального;
- посилання на Git-коміт;
- дату переходу в stable.; * Запущено `python k2update_push.py`.; У ній додаються нові модулі, виправляються помилки, змінюються форми, оновлюються гриди, додаються інтеграції, уточнюються права доступу, покращується продуктивність і з’являються нові галузеві рішення для бізнесу.; builder/config/ignore
Чи можна оновлювати компоненти вручну?
Стандартна логіка роботи: |-
| Технічний акцент.
K2 Update поєднує Git, компоненти, версії, сервер оновлень і тестування в один контрольований бізнес-процес.; * ignore-файл перевірено.;* ядро оновлюється за правилами K2;
* доповнення оновлюють автори за технічними вимогами платформи;
* сумісність перевіряється перед публікацією;
* для клієнтів мають бути стабільні канали релізів;
* критичні актуалізація мають проходити тестування;
* партнерська хмарна інфраструктура має мати політику backup і відновлення;
* актуалізація не повинні ламати клієнтські процеси.; Компонента має мати:
[[Категорія:Система оновлень K2]]
{{DISPLAYTITLE:K2 Update}}
=== Що таке K2 Update? ===
== SEO-призначення сторінки ==
|-
| '''Технічний акцент.''' <span style="color:#1565c0;">auto_update — це інструмент для Git-синхронізації компонентів, а не заміна серверу оновлень.; python git_cmd.py pull
== Як зрозуміти, що K2 Update функціонує правильно ==
|-
| '''Перевага версійності.''' <span style="color:#2e7d32;">реліз надає можливість зрозуміти, що саме встановлено в середовищі й чи відповідає компонент очікуваному релізу.; Для стабільної версії:
|-
| '''Правильна логіка.''' <span style="color:#2e7d32;">Спочатку Git і тестування.; Він користувачі можуть клонувати актуальні версії компонентів, перевіряти статус, комітити, отримувати зміни й пушити їх у віддалений репозиторій.; # Перевірити роботу локально.;</span>
|}
{| class="wikitable" style="width:100%; background:#e3f2fd;"
[[Категорія:Сервер оновлень]]
* `deb1`;
* `deb2`;
* `deb3`.; |}
'''K2 Update''' — це платформа оновлень K2 ERP та K2 Cloud ERP, яка сприяє керовано оновлювати ядро, компоненти, модулі, доповнення й інтеграції через версії, Git, сервер оновлень, `setup.py`, `history.txt` і тестування.;</span> Помилка в ядрі має змогу вплинути на всю ERP.;</span>
|}
Можливі канали:
!;</span>
|}
[[Категорія:Партнерська програма K2]]
# Отримати актуальний код через `git pull`.; * чи компонента встановлюється;
* чи не виникають помилки;
* чи відкриваються потрібні сторінки;
* чи працюють гриди;
* чи зберігаються форми;
* чи не зламалися права;
* чи працюють залежні модулі;
* чи коректні міграції даних;
* чи немає помилок у логах;
* чи відповідає поведінка опису в `history.txt`.; ERP функціонує з критичними даними, з цієї причини актуалізація без backup — ризик.; Якщо актуалізація не контролювати, дуже оперативно виникають проблеми:
`history.txt` містить характеристика змін у компоненті.; Токен потрібен для авторизації під час завантаження компонентів.; * яку версію повертаємо;
* які компоненти відкочуємо;
* що робимо з базою даних;
* чи були міграції;
* чи можна відкотити тільки код;
* хто ухвалює рішення для бізнесу;
* скільки часу займає відновлення;
* хто повідомляє користувачів;
* де зберігається попередня стабільна реліз.; * `component-list.txt`;
* папка `ignore`;
* `token.txt`;
* інші конфігураційні файли процесу актуалізація.; Git потрібен для того, щоб команда могла бачити:
== актуалізація доповнень ==
У партнерській екосистемі K2 актуалізація мають бути керованими.;</span> Це службовий доступ до системи оновлень.; * Імпорт і експорт працюють, якщо були змінені.; * Залежні модулі перевірені.; Він сприяє підтримці, партнерам, адміністраторам і клієнтам зрозуміти, що саме змінилося.; {| class="wikitable" style="width:100%; background:#ffebee;"
{| class="wikitable" style="width:100%; background:#e8f5e9;"
=== Чому потрібно тестувати на deb1-deb3? ===
* хто відповідає за актуалізація;
* хто має доступ до серверів;
* коли можна оновлювати;
* хто тестує;
* хто підтверджує готовність;
* де зберігається backup;
* як виконувати відкат;
* які компоненти можна оновлювати;
* які актуалізація критичні;
* які потребують погодження.; Приклад:
|-
| '''Dev'''
| розробка програмного забезпечення й експерименти
| Розробники
|-
| '''Testing'''
| Перевірка нових версій
| QA, технічні партнери, тестові середовища
|-
| '''Beta'''
| Пілотне використання обмеженою групою
| Партнери, ранні клієнти
|-
| '''Stable'''
| Стабільний реліз
| Робочі середовища
|-
| '''LTS'''
| Довготривала супровід
| Клієнти, яким потрібна максимальна стабільність
|}
{| class="wikitable" style="width:100%; background:#e3f2fd;"
|-
| '''Архітектурний сенс.''' <span style="color:#1565c0;">Канали релізів допомагають не змішувати експериментальні, тестові й стабільні актуалізація.; |-
| '''істотно.''' <span style="color:#ef6c00;">Перед запуском `python git_cmd.py clone` потрібно перевірити `settings.py`, щоб не клонувати зайві компоненти й не пропустити потрібні.; додатково потрібно вказати тип версії.; * Версію оновлено в `setup.py`.; Для таких доповнень потрібна окрема дисципліна.; * Залежності перевірено.; * Форми зберігаються.; Типовий перехід у каталог:
|-
| '''Технічний принцип.''' <span style="color:#1565c0;">builder/config — це місце, де визначається, що саме буде завантажено, що потрібно ігнорувати й з яким доступом виконувати публікацію.;</span>
|}
!; * Гриди працюють.; # Закомітити зміни.; * Логи перевірено.; Приклад:
[[Категорія:Компоненти K2 ERP]]
Доповнення до K2 можуть створюватися командою K2, партнерами або сторонніми розробниками в межах екосистеми.; Для чого застосовується
Шоста помилка — комітити токени або службові доступи.; # Перевірити роботу на `deb1`, `deb2`, `deb3`.; Приклади
{| class="wikitable" style="width:100%; background:#fff3e0;"
== stable і testing ==
Десята помилка — не мати backup і плану відкату.; cd auto_update
Перед публікацією актуалізація потрібно перевірити, чи компонента сумісна з іншими частинами системи.; Для доповнення в магазині істотно мати:
містить характеристика змін у компоненті.;</span>
|}
settings_example.py
{| class="wikitable" style="width:100%; background:#fff3e0;"
{| class="wikitable" style="width:100%; background:#fff3e0;"
K2 Update має змогу використовуватися для актуалізація різних частин екосистеми K2.; Вона сприяє оновлювати ядро, компоненти, модулі й доповнення через Git, версії, сервер оновлень, характеристика змін, stable/testing-канали й тестові середовища.; # Внести зміни в компоненту.; |}
{| class="wikitable" style="width:100%; background:#fff3e0;"
<syntaxhighlight lang="bash">
Скрипт розміщується в корені проєкту на рівні з виконуваним файлом: Приклад вмісту:
`history.txt` потрібен не тільки розробникам.; Якщо платформа складається з компонентів, можна оновлювати конкретну частину: CRM, електронний документообіг, K2Grid, сайт, інтеграцію, звіт або галузевий компонент.; виконує завантаження компонентів на сервер оновлень відповідно до налаштувань у `builder/config`.; Навпаки, потрібна ще більша дисципліна, бо відповідальність часто лежить на клієнті або партнері.; # Додати характеристика змін у `history.txt`.;== Git як основа оновлень ==Перед запуском. `k2update_push.py` потрібно виконувати тільки після підготовки релізу, а не як випадкову команду “спробувати завантажити”.;
auto_update
Головна цінність K2 Update — контроль.; python k2update_push.py
Потрібно перевірити: settings.py в auto_updatepython git_cmd.py push K2 Update — це платформа керованих оновлень для K2 ERP та K2 Cloud ERP.; Якщо модулі продаються або встановлюються через екосистему, вони мають оновлюватися передбачувано.; Якщо потрібної компоненти немає — вона не потрапить на сервер оновлень.; * Тип версії визначено: `stable` або `testing`.; Спочатку зміни мають бути впорядковані в репозиторії, а вже потім підготовлені до актуалізація.; Команда:
</syntaxhighlight> `auto_update` — це скрипт для роботи зі списком компонентів у Git: клонування, перевірка статусу, commit, pull і push.; Окремо варто відзначити з цієї причини що ядро впливає на всю платформу: базу даних, доступи, API, компоненти, гриди, форми, інтеграції і системні сервіси.; Саме з цієї причини потрібна перевірка сумісності.; Приклад: | |||||||||||||||||||||
істотно для магазину доповнень. Доповнення без версії, документації й перевірки сумісності не повинно потрапляти в стабільний канал екосистеми K2.; # Після успішного тесту перевести реліз у стабільний канал, якщо це передбачено процесом.;</syntaxhighlight>
Типові помилки при оновленняхУ журналі бажано фіксувати: Каталог builder/configПлан відкату потрібен на випадок, якщо після актуалізація виникли критичні помилки.; {| class="wikitable" style="width:100%; background:#e3f2fd;"
|-
| '''Перевага.''' <span style="color:#2e7d32;">Журнал оновлень сприяє підтримці оперативно зрозуміти, що змінилося перед появою помилки або звернення користувача.;</span> Це бізнес-процес керованого розвитку ERP: реліз, історичний розвиток змін, сервер оновлень, перевірка компонентів, тестування й контроль сумісності.;</span>
|}
version_type = "stable"
Перед тим як компонента потрапить на сервер оновлень, її зміни мають бути зафіксовані в Git.; * Backup підготовлено, якщо актуалізація важливе.; * Виконано `git pull`.; * супровід знає, що змінилося.; Тестові домени потрібні, щоб перевірити, як актуалізація поводиться в середовищах, близьких до реальної роботи.; Команда завантаження:
|-
| '''Перевага.''' <span style="color:#2e7d32;">Керована платформа оновлень зменшує ризики, спрощує підтримку й надає можливість розвивати K2 ERP як платформу, а не як набір локальних доробок.; |}
Вона покриває запити: “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 актуалізація”.; |-
| '''істотно.''' <span style="color:#ef6c00;">актуалізація ERP не можна робити як випадковий FTP-патч.;<syntaxhighlight lang="text">
`stable` — це перевірена реліз для робочого використання.; Тип версії
python git_cmd.py commit
k2update_push.pyПолітика оновлень для партнерівПотрібно визначити:
K2 Update і магазин доповнень
Файл: План має відповідати на питання:
Для чого потрібен history.txt?У ньому можуть бути: для кожної компоненти можна створити файл із переліком файлів і папок, які не потрібно завантажувати на сервер оновлень.; Тут актуалізація мають враховувати внутрішні правила компанії.; Файл:
token.txtпотрібно додати в словник ключі з потрібними компонентами.; Команда бачить, що оновлюється, яка реліз встановлена, що змінилося, хто відповідає, де тестували й чи готовий реліз до стабільного використання.;== Поширені запитання ==
У каталозі: Див.; додатковоДруга помилка — не змінювати `setup.py`.; Об’єкт актуалізація </syntaxhighlight> Перед запуском потрібно перевірити: У широкому сенсі K2 Update охоплює: python k2update_push.py
!; Доступ до нього мають мати тільки відповідальні розробники або адміністратори релізів.;</span>
|}
У K2 Update істотно розрізняти стабільні й тестові версії.; `auto_update` особливо корисний, коли проєкт містить багато компонентів.;[[Категорія:Git]]
Автор доповнення має забезпечити:
{| class="wikitable" style="width:100%; background:#ffebee;"
== Сервер оновлень K2 ==
|-
| '''<span style="color:#2e7d32;">stable</span>'''
| Перевірена реліз для робочого використання
| Prod, клієнтські середовища, стабільні релізи
|-
| '''<span style="color:#ef6c00;">testing</span>'''
| реліз для перевірки, beta або тестування
| Dev, Test, deb1-deb3, пілотні середовища
|}
.gitignore
| |||||||||||||||||||||
| Критично. актуалізація без версії, без `history.txt`, без Git і без тестування має змогу зламати робочі процеси клієнта.; У системі, де є собою фінансовий блок, документи, складський облік, CRM, користувачі й права доступу, кожне актуалізація має бути зрозумілим і відтворюваним.; |
components/k2update
python git_cmd.py clone
* оцінку сумісності;
* тестування залежних компонентів;
* перевірку критичних модулів;
* контроль міграцій;
* план відкату;
* характеристика змін;
* інформування партнерів;
* стабільний канал релізу.; * Права доступу не зламані.;== Коротко ==
Що робить k2update_push.py?
</syntaxhighlight>
history.txt
Що оновлює K2 Update
[[Категорія:K2 ERP]]
{| class="wikitable" style="width:100%; background:#e8f5e9;"
ERP-система постійно розвивається.; * характеристика змін додано в `history.txt`.; auto_update/settings.py
.git
містить токен доступу до сервера оновлень.; Перед публікацією нової версії компоненти потрібно оновити її версію у файлі:
У вузькому технічному сенсі K2 Update часто пов’язаний із командою:
[[Категорія:K2 Ядро]]
[[Категорія:Рекомендації для розробників K2]]
[[Категорія:Українське програмне забезпечення]]
актуалізація ядра має проходити за правилами K2 і включати:
</syntaxhighlight>
| - | }
ej2.min.js Перед завантаженням потрібно налаштувати: Тестові домени `deb1`, `deb2`, `deb3` потрібні для перевірки встановлення, сумісності й роботи компоненти перед використанням у стабільному середовищі.; * Зміни запушено.; Замість того щоб вручну переходити в кожну папку, розробник має змогу працювати зі списком компонентів централізовано.; Backup має охоплювати:
|