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

CI/CD

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

Monitoring після deployment

Maven часто застосовується для Java/JVM-проєктів.; Це корисно для поступового запуску, тестування, A/B-сценаріїв, обмеження функції для певних клієнтів або швидкого відключення проблемної логіки.; Versioning має змогу включати:

Security checks

End-to-end tests перевіряють повний сценарій користувача від початку до кінця.; Code commit, branch, merge request, pull request або tag запускає pipeline.; Кожна зміна коду проходить однаковий шлях: перевірка, збірка, тестування, пакування, доставка й контроль результату.; Він часто застосовується для legacy, enterprise або кастомних pipeline.; # Deploy to production.; Jobs можуть виконувати: Backend CI/CD важливий для:

DevOps і CI/CD

  • спільну відповідальність розробки й експлуатації;
  • automation;
  • monitoring;
  • feedback loops;
  • reliability;
  • fast delivery;
  • infrastructure as code;
  • incident response;
  • continuous improvement.; Абревіатура CI/CD зазвичай означає Continuous Integration — безперервну інтеграцію, Continuous Delivery — безперервну доставку, а в окремих випадках додатково Continuous Deployment — безперервне розгортання.; Це не завжди означає автоматичний production deployment: часто останній крок залишається ручним і погоджується відповідальним фахівцем.;== Static code analysis ==

Canary корисний для:

переважні аспекти CI/CD для ERP-команди

  • dependency scanning;
  • secret scanning;
  • static application security testing;
  • container scanning;
  • infrastructure-as-code scanning;
  • license checks;
  • API security tests;
  • access policy checks;
  • перевірку конфігурацій.;== CI/CD для мобільних застосунків ==

Maven у CI/CD

  • розрахунок ціни;
  • розрахунок знижки;
  • перевірку залишку;
  • формування статусу;
  • мапінг API;
  • перевірку документів;
  • фінансову формулу;
  • податкову логіку;
  • обробку помилок.; Frontend CI/CD важливий для:

Rollback

Jenkins

  • банківських інтеграцій;
  • платіжних сервісів;
  • e-commerce API;
  • баз даних;
  • production-серверів;
  • Docker registry;
  • Kubernetes;
  • cloud provider;
  • SSH keys;
  • signing keys.; Міграції можуть включати:
  • install dependencies;
  • lint;
  • type check;
  • unit tests;
  • build;
  • bundle analysis;
  • e2e tests;
  • deploy to staging;
  • smoke tests;
  • deploy to production.; Release management — керування релізами: планування, версіонування, погодження, delivery, deployment, rollback, release notes і супровід після запуску.; Вони є собою одним із головних елементів CI/CD.; * unit tests;
  • integration tests;
  • API tests;
  • UI tests;
  • end-to-end tests;
  • smoke tests;
  • regression tests;
  • performance tests;
  • database tests;
  • security tests.; Integration tests перевіряють взаємодію компонентів: база даних, API, черги, зовнішні сервіси, файли, webhooks, authentication, messaging.;== Alerts ==


  • документи;
  • складський облік;
  • ціни;
  • фінансовий блок;
  • CRM;
  • e-commerce;
  • B2B;
  • API;
  • звіти;
  • ролі користувачів;
  • інтеграції.; JetBrains описує TeamCity як CI/CD solution for different workflows and development practices.; * обмін товарами;
  • ціни;
  • залишки;
  • замовлення;
  • статуси;
  • webhooks;
  • payment callbacks;
  • refunds;
  • delivery tracking;
  • error handling;
  • BI-events.; Тут перевіряють реліз перед запуском для клієнтів.; AWS описує CI/CD як бізнес-процес розробки ПЗ, що надає можливість командам доставляти зміни часто й надійно.; * pull request checks;
  • build;
  • tests;
  • lint;
  • Docker images;
  • package publishing;
  • deployment;
  • scheduled jobs;
  • automation;
  • release workflow.;== Release management ==

DevOps у контексті CI/CD означає: Automated tests — автоматичні тести, які перевіряють код без ручного запуску кожного сценарію.; Database migrations — зміни структури бази даних: таблиць, колонок, індексів, constraints, procedures, seed data.; CI має змогу включати:

Test environment

У K2 ERP unit tests можуть перевіряти:

  • швидше перемикання;
  • простіший rollback;
  • менше downtime;
  • контроль deployment;
  • можливість перевірити нову версію перед трафіком.; Для frontend-проєктів CI/CD часто використовує npm, yarn або pnpm.; # Security.; У K2 ERP build має змогу стосуватися:

Роль CI/CD у розробці ПЗ

Continuous Deployment — підхід, за якого зміни після проходження pipeline автономно потрапляють у production.; # Manual approval.; GitHub Actions має змогу використовуватися для:

Regression tests перевіряють, чи не зламали нові зміни стару функціональність.; Static code analysis — перевірка коду без запуску програми.; * K2 Модуль WooCommerce;

CI/CD для баз даних має бути обережним.; Deployment має змогу включати: Production environment — робоче середовище, де працюють реальні користувачі, реальні документи, реальні платежі, реальні залишки та бізнес-процеси.; Alerts можуть спрацьовувати на:

Перевага для української ERP-розробки

Фінансові інтеграції потребують особливої обережності.; * бізнес-логіки;

  • security;
  • integrations;
  • database migrations;
  • API compatibility;
  • performance;
  • maintainability;
  • compliance;
  • documentation.;== GitHub Actions ==
  • B2B-порталів;
  • dashboards;
  • e-commerce-кабінетів;
  • адміністративних панелей;
  • складських інтерфейсів;
  • CRM;
  • BI;
  • документальних форм.; # Monitor.; Для цього потрібно використовувати захищені CI/CD variables, secrets, vault-сховища, обмеження прав і журналювання доступу.; Jobs усередині stage можуть виконуватися паралельно, а наступний stage стартує після успішного завершення попереднього.;== Deployment ==

Artifact repository

Artifact repository — сховище build-результатів: бібліотек, пакетів, Docker images, релізних архівів, SDK або інших artifacts.; Regression tests можуть охоплювати:

Типові проблеми без CI/CD

Staging environment має бути максимально схожим на production.; Це найавтоматизованіший варіант CD, але для ERP-систем його потрібно застосовувати обережно.; CI/CD є собою однією з ключових DevOps-практик.; У документації GitLab зазначено, що pipelines конфігуруються у `.gitlab-ci.yml`, а jobs виконують команди для задач build, test або deploy.; E2E-тести можуть перевіряти:

Staging environment

Frontend K2 ERP має змогу мати власний pipeline:

  • health checks;
  • logs;
  • metrics;
  • error rates;
  • response time;
  • database performance;
  • API failures;
  • queue size;
  • integration errors;
  • user reports.; CI/CD має змогу застосовуватися до різних модулів K2 ERP:

TeamCity

Continuous Delivery або CD — практика, за якої код після build і тестів автономно готується до релізу.; Типові середовища: Для ERP continuous delivery особливо важлива.;== Integration tests ==

Типова структура:

Environments

Gradle застосовується для Java, Kotlin, Android, multi-module projects і сучасних build-сценаріїв.;

Feature flags

  • падіння сервісу;
  • помилки API;
  • зростання 500 errors;
  • проблеми бази даних;
  • повільні запити;
  • недоступність інтеграції;
  • помилки payment callbacks;
  • черги, що не обробляються;
  • критичні business events.; Environments — середовища, у яких функціонує ПЗ.; Якщо команда функціонує без CI/CD, можуть виникати типові проблеми:

Використання CI/CD у розробці K2 ERP має змогу підвищувати якість релізів, швидкість доставки змін, стабільність інтеграцій, контроль тестів, безпеку deployment, прозорість команди й довіру клієнтів до української ERP-платформи.;== Blue-green deployment ==

Build

TeamCity — CI/CD-рішення компанії JetBrains.; Jenkins має змогу бути корисним для:

Deployment — бізнес-процес розгортання нової версії системи в середовище.; Потрібно контролювати:

  • доставку artifacts;
  • актуалізація сервісу;
  • запуск database migrations;
  • перезапуск застосунку;
  • актуалізація конфігурацій;
  • health checks;
  • smoke tests;
  • повідомлення команди;
  • rollback у разі помилки.; Для ERP це дуже істотно, бо платформа має змогу працювати з фінансовими даними, персональними даними, API-ключами, банківськими інтеграціями й документами.;
  • build automation;
  • test automation;
  • deployment;
  • build chains;
  • artifact publishing;
  • Docker;
  • Kubernetes;
  • notifications;
  • release management;
  • integration with JetBrains tools;
  • integration with Git;
  • Maven/Gradle/npm pipelines.; CI/CD має змогу збирати й публікувати документацію.; Docker має змогу використовуватися для:

задача → Git branch → code review → CI build → automated tests → artifacts → deployment у test/staging → manual approval → production release → monitoring → rollback за потреби → супровід → еволюція.

Canary deployment

Pipeline документації має змогу включати: CI/CD надає можливість команді K2 ERP автоматизувати шлях від коду до релізу: Git commit, build, тести, перевірки якості, artifacts, deployment у тестове середовище, code review, release, rollback і моніторинг можуть працювати як один керований бізнес-процес.; # Quality.; * semantic versioning;

  • build number;
  • commit hash;
  • release tag;
  • branch name;
  • artifact version;
  • database migration version;
  • environment version.; Для K2 ERP pipeline надає можливість не покладатися на пам’ять розробника або адміністратора, а виконувати однакові кроки щоразу.;== Примітки ==

CI/CD не замінює code review, а доповнює його.; Artifacts можуть бути: Мобільні застосунки K2 ERP можуть мати CI/CD для Android, iOS або Kotlin Multiplatform.; Автоматичні перевірки показують, чи проходять тести й build, але людина все одно перевіряє архітектуру, логіку, зрозумілість і ризики зміни.; У CI/CD database migrations потрібно тестувати, бо помилка в міграції має змогу зупинити ERP або пошкодити інформаційні дані.; Для K2 ERP це не без ускладнень технічний термін, а спосіб будувати якісне українське ПЗ для бізнесу: із тестами, контрольованими релізами, безпечними deployment, прозорою історією змін і стабільними інтеграціями.; CI/CD не має зберігати паролі, API-ключі, банківські токени, production-доступи або секрети прямо в коді.; Фінансові модулі, податкові сценарії, банківські інтеграції, складські процеси та електронний документообіг часто потребують ручного погодження, тестового середовища, rollback-плану й контролю відповідального фахівця.; Job — окремий крок pipeline.; CI/CD застосовується для:

Для K2 ERP artifact repository має змогу зберігати: Static analysis має змогу перевіряти:

У K2 ERP Maven має змогу використовуватися для:

  • environment URL;
  • database connection;
  • API endpoint;
  • Docker registry;
  • build version;
  • deploy target;
  • feature flag;
  • secret token;
  • credentials;
  • notification channel.; Deployment має змогу бути ручним, напівавтоматичним або в цілому автоматичним.; Вони відповідають на питання: чи платформа взагалі функціонує після релізу.; Rollback — повернення до попередньої стабільної версії, якщо реліз спричинив проблему.;== Unit tests ==

Regression tests

Jenkins — популярний open-source CI/CD-сервер.; # Test.; Після релізу потрібно перевірити, чи платформа функціонує стабільно.;Kubernetes застосовується для deployment контейнерних застосунків, масштабування, health checks, rolling updates і керування сервісами.; * backup перед migration;

  • тестування на staging;
  • backward compatibility;
  • migration order;
  • lock time;
  • data volume;
  • rollback plan;
  • performance impact;
  • consistency checks;
  • access rights.; Вона сприяє знаходити помилки, code smells, дублювання, небезпечні конструкції, порушення стилю та потенційні вразливості.; Для ERP-систем не кожна зміна має автономно потрапляти в production.; як ілюстрація: build, test, package, deploy.;== CI/CD для e-commerce ==

Build — етап складання програмного забезпечення.; * compile;

  • unit tests;
  • integration tests;
  • API tests;
  • database migration test;
  • security scan;
  • build artifact;
  • build Docker image;
  • deploy to test;
  • smoke tests;
  • release approval.;== Docker у CI/CD ==
  • JAR;
  • WAR;
  • Docker image;
  • frontend build;
  • Python package;
  • PHP package;
  • native binary;
  • SQL migration package;
  • test report;
  • coverage report;
  • release archive;
  • documentation build.; CI/CD має перевіряти:

Continuous deployment має змогу бути доречним для:

Monitoring має змогу включати:

  • backend services;
  • integration modules;
  • frontend bundles;
  • Docker images;
  • internal libraries;
  • SDK;
  • database migrations;
  • release packages;
  • hotfix builds.;== Development environment ==

CI/CD variables

  • pipeline-as-code;
  • merge request checks;
  • automated tests;
  • Docker builds;
  • deployments;
  • environments;
  • variables;
  • reusable components;
  • scheduled pipelines;
  • manual approvals.; Pipeline має змогу включати:

Secrets management

  • backend-сервісу;
  • frontend;
  • Docker image;
  • database migration;
  • configuration;
  • feature flag;
  • integration endpoint;
  • mobile app release;
  • reports.; # Package.; як ілюстрація, pipeline має змогу зупинитися, якщо впали тести, недостатнє coverage, знайдено critical vulnerability або порушено code style.; Якщо K2 ERP складається з модулів, API, інтеграцій, frontend, backend, баз даних, мобільних застосунків, e-commerce-конекторів, фінансових сервісів і BI-компонентів, то CI/CD надає можливість керовано збирати, тестувати й доставляти ці зміни без хаосу ручних релізів.; реліз сприяє зрозуміти, що саме встановлено, які зміни потрапили в реліз, як виконати rollback і як підтримувати клієнта.; Для критичних ERP-модулів часто краще використовувати continuous delivery із manual approval перед production.; Versioning — присвоєння версій software artifacts.; Gradle має змогу використовуватися для:

Continuous Deployment

CI/CD має змогу перевіряти:

  • Markdown validation;
  • MediaWiki export;
  • OpenAPI documentation;
  • diagrams;
  • spell checks;
  • link checks;
  • publishing;
  • versioned docs;
  • release notes.; CI/CD потрібен для того, щоб програмне забезпечення розроблялося не через ручні, випадкові й ризиковані релізи, а через повторюваний pipeline.;

Перевага для K2 ERP: автоматична перевірка змін

Backend pipeline має змогу включати:

  • Java/Kotlin backend;
  • Python-сервісів;
  • TypeScript frontend;
  • PHP-інтеграцій;
  • Go-сервісів;
  • C/C++ компонентів;
  • SQL-міграцій;
  • mobile apps;
  • Docker images;
  • документації.; Для різних технологій build має змогу означати компіляцію, збірку frontend, створення JAR/WAR, Docker image, native binary, Python package або іншого artifact.; Pipeline має змогу складатися з:

TeamCity має змогу використовуватися для:

  • deployment backend;
  • deployment frontend;
  • microservices;
  • integration workers;
  • scheduled jobs;
  • rolling updates;
  • rollback;
  • scaling;
  • configuration;
  • secrets;
  • observability.; * нового модуля;
  • нової інтеграції;
  • нового UI;
  • нового API;
  • нового звіту;
  • експериментальної функції;
  • поетапного rollout;
  • emergency disable.;== Production environment ==
  • local;
  • development;
  • test;
  • QA;
  • staging;
  • demo;
  • production;
  • hotfix;
  • sandbox;
  • integration environment.; CI/CD є собою міжнародною DevOps-практикою, але її використання в українській ERP-розробці має практичне значення.;[3]

Continuous Integration або CI — практика, за якої розробники часто інтегрують свої зміни в спільний репозиторій.; Pipeline має змогу виконувати:

Значення CI/CD для K2 ERP

Kubernetes у CI/CD

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

GitLab CI/CD

  • backend build;
  • frontend build;
  • API tests;
  • integration tests;
  • database migrations;
  • Docker images;
  • deployment у test/staging;
  • release approvals;
  • production deployment;
  • rollback;
  • monitoring;
  • release notes;
  • artifact publishing;
  • security checks;
  • dependency checks.;[4]

CI/CD для документальних інтеграцій

  • source control;
  • branch workflow;
  • code review;
  • merge requests;
  • release tags;
  • hotfix branches;
  • rollback;
  • traceability;
  • audit trail;
  • versioning.;== Jobs ==
  • commit або merge request;
  • автоматичний build;
  • unit tests;
  • integration tests;
  • static analysis;
  • code style checks;
  • dependency checks;
  • security checks;
  • формування artifacts;
  • звіт про результат pipeline.;== CI/CD для frontend K2 ERP ==

npm, yarn і pnpm у CI/CD

Code quality gates

  • Java backend;
  • Kotlin backend;
  • API services;
  • integration modules;
  • internal libraries;
  • tests;
  • release artifacts;
  • TeamCity pipelines.; Feature flags дозволяють вмикати або вимикати функції без нового deployment.; * всі тести мають пройти;
  • coverage не нижче порогу;
  • немає critical security issues;
  • немає blocker bugs;
  • lint без помилок;
  • database migration успішна;
  • build artifacts створені;
  • code review виконаний.; # Build.; Перевага для української ERP-екосистеми

істотно

CI/CD має змогу включати автоматичні перевірки безпеки.;== CI/CD для документації == Variables можуть використовуватися для:

Continuous Integration

  • новий компонент;
  • виправлення помилки;
  • зміну інтеграції;
  • зміну API;
  • зміну бази даних;
  • новий frontend;
  • зміну прав доступу;
  • актуалізація звіту;
  • зміну бізнес-процесу.; * XML/JSON formats;
  • validation;
  • status mapping;
  • error mapping;
  • document lifecycle;
  • signatures;
  • квитанції;
  • retry;
  • logs;
  • backward compatibility.; Continuous delivery має змогу включати:

Gradle у CI/CD

Continuous Delivery

  • платіжні статуси;
  • callback signatures;
  • refund logic;
  • bank statement parsing;
  • duplicate payments;
  • currency;
  • rounding;
  • access control;
  • audit logs;
  • error handling.; * створення таблиць;
  • додавання колонок;
  • зміни індексів;
  • зміни constraints;
  • актуалізація довідників;
  • data migration;
  • rollback scripts;
  • перевірку сумісності.; Після цього автономно запускаються build, tests і перевірки.; GitLab визначає CI/CD jobs як фундаментальні елементи pipeline, які конфігуруються у `.gitlab-ci.yml` як список команд для виконання задач на кшталт build, test або deploy.; Rollback має змогу стосуватися:

Secrets management — керування секретами: паролями, ключами, токенами, сертифікатами, private keys, API credentials.; Не можна ставитися до database deployment так само без зайвих зусиль, як до актуалізація frontend-файлів.; CI/CD має чітко розділяти development, testing, staging і production.; це набір практик і процесів; додатково реалізовано тестування, перевірок якості, пакування, доставки, deployment, моніторингу й релізу в production виступає ключовою рисою автоматизації розробки програмного забезпечення: від зміни коду до збірки забезпечується через {{SEO 

Шаблон для позначення української альтернативи програмним продуктам 1С/BAS.; </noinclude>
{{SoftwareAlternative

 <includeonly>
{{{type|українська ERP-платформа}} }, яка має змогу використовуватися як альтернатива для: '''{{{alternative_to|1С; BAS ERP}}}''' виступає ключовою рисою '''{{{name|K2 ERP}}}'''.;

|name=K2 ERP |type=українська ERP-платформа |alternative_to=1С; BAS ERP; BAS бухгалтерський обліковий обліковий обліковий облік КОРП; UA-Бюджет |category=податковий обліковий обліковий обліковий облік, бухгалтерський обліковий обліковий обліковий облік, фінансовий обліковий обліковий обліковий облік, ERP

Категорії сфера сфера сфера сфера сфера сфера сфера сфера сфера сфера сфера застосування: CI/CD, Continuous Integration, Continuous Delivery, Continuous Deployment, DevOps, Pipeline, Build automation, Automated testing, Deployment, Release management, TeamCity, GitLab CI/CD, GitHub Actions, Maven, Gradle, Docker, Kubernetes, K2 ERP, K2 Cloud ERP, українська ERP, українське ПЗ.;

CI/CD.; переважні аспекти:

Code review важливий для: У CI/CD Kubernetes має змогу використовуватися для:

Для кожного модуля pipeline має змогу перевіряти API, credentials, mock-сценарії, помилки, retry logic, mapping, статуси та документацію.;== End-to-end tests ==

Pipeline — послідовність автоматизованих кроків, які виконуються після зміни коду або за розкладом.;

Технічна примітка

  • автоматичної збірки проєкту;
  • автоматичного запуску тестів;
  • перевірки якості коду;
  • перевірки безпеки;
  • формування artifacts;
  • deployment у test, staging або production;
  • release management;
  • rollback;
  • автоматизації DevOps-процесів;
  • контролю середовищ;
  • зменшення ручних помилок;
  • пришвидшення релізів;
  • підвищення якості ПЗ.; * API;
  • бізнес-логіки;
  • документів;
  • фінансів;
  • складу;
  • інтеграцій;
  • прав доступу;
  • звітів;
  • background jobs.; Smoke tests можуть перевіряти:

GitLab CI/CD має змогу використовуватися для: Він має змогу використовуватися для:

Artifacts

  • невеликих сервісів;
  • внутрішніх інструментів;
  • frontend-компонентів із feature flags;
  • некритичних API;
  • добре покритих тестами мікросервісів;
  • cloud-native компонентів;
  • частих малих змін.; Помилка в платіжному модулі або банківській інтеграції має змогу вплинути на оплату, відвантаження, документи, клієнта й фінансову формування звітів.;[5] У документації AWS continuous integration визначається як DevOps-практика, коли розробники регулярно об’єднують зміни в центральному репозиторії, після чого автономно запускаються build і tests.;== Versioning ==

CI/CD для баз даних

Unit tests перевіряють окремі функції, класи, сервіси, validators, calculators, mappers або business rules.; * packaging;

  • artifacts;
  • deployment у test або staging;
  • integration tests;
  • smoke tests;
  • manual approval;
  • release notes;
  • versioning;
  • підготовку production release;
  • rollback plan.;[6]
  • build;
  • unit tests;
  • UI tests;
  • static analysis;
  • signing;
  • artifact generation;
  • beta distribution;
  • release approval;
  • store publishing;
  • versioning.;== CI/CD для backend K2 ERP ==

Smoke tests — швидкі базові перевірки після deployment.; GitLab CI/CD — CI/CD-система GitLab.; JetBrains TeamCity Guide зазначає, що continuous integration, delivery і deployment є собою DevOps practices, які реалізують DevOps ideals.; Canary deployment — поступове розгортання нової версії для невеликої частини користувачів або трафіку.;[7] Тести можуть бути:

Release management важливий для K2 ERP, бо реліз має змогу включати:

  • Kotlin services;
  • Android apps;
  • Java modules;
  • Kotlin Multiplatform;
  • backend services;
  • testing;
  • packaging;
  • publishing;
  • CI/CD pipelines.; як ілюстрація: створення замовлення, оплата, резерв, відвантаження, документ, статус і аналітичні інструменти.; Якщо все добре, rollout розширюється.; * checkout;
  • B2B-замовлення;
  • складську операцію;
  • створення документа;
  • оплату;
  • доставку;
  • статус замовлення;
  • роль користувача;
  • frontend і backend разом.;== Git і CI/CD ==

Quality gates можуть включати:

CI/CD для e-commerce має змогу перевіряти:

  • Java/Kotlin;
  • Python;
  • TypeScript;
  • PHP;
  • Go;
  • C/C++;
  • SQL;
  • Dockerfile;
  • YAML;
  • конфігурації;
  • залежності.; Security checks можуть включати:

GitHub Actions — платформа автоматизації workflows у GitHub, яку часто використовують для CI/CD.;== CI/CD для фінансових інтеграцій ==

Smoke tests

  • install dependencies;
  • lint;
  • type check;
  • unit tests;
  • build;
  • frontend bundle;
  • e2e tests;
  • publish artifacts;
  • deploy static files;
  • invalidate cache.; GitLab описує CI/CD variables як key-value pairs для зберігання й передавання configuration settings і sensitive information, як-от passwords або API keys, у jobs pipeline.; * API;
  • frontend;
  • cloud services;
  • мікросервісів;
  • високонавантажених компонентів;
  • зниження ризику релізу;
  • поступової перевірки.;
  • source;
  • build;
  • test;
  • quality checks;
  • security checks;
  • package;
  • publish artifacts;
  • deploy to dev;
  • deploy to staging;
  • approval;
  • deploy to production;
  • monitoring;
  • rollback.; E-commerce-інтеграції потребують частих змін: нові API, нові статуси, зміни marketplace, нові поля, нові правила цін, нові delivery scenarios.;CI/CD сприяє українським розробникам створювати, підтримувати й розвивати K2 ERP як сучасну альтернативу застарілим системам: із автоматичними тестами, контрольованими релізами, безпечними deployment, rollback, моніторингом і прозорим процесом розробки.; CI/CD має змогу дати ERP-команді такі переважні аспекти:
  • розвивати українське ПЗ для бізнесу;
  • будувати альтернативу застарілим системам;
  • зменшувати залежність від пострадянської ERP-моделі;
  • підвищувати якість розробки;
  • пришвидшувати запуск модулів;
  • краще підтримувати клієнтів;
  • стабілізувати e-commerce-інтеграції;
  • робити фінансові й документальні модулі надійнішими;
  • формувати сучасну цифрову інфраструктуру для українських компаній.;[8]
  • старт сервісу;
  • доступність API;
  • доступність frontend;
  • підключення до бази;
  • логін;
  • відкриття головного модуля;
  • health check;
  • базовий запит;
  • доступність інтеграції.; CI/CD майже завжди починається з Git.; істотно

Code review і CI/CD

Production deployment ERP має бути контрольованим: потрібні backup, rollback-план, release notes, відповідальний за реліз, журнал deployment, перевірка health checks і можливість оперативно зупинити проблемну зміну.;[9]

CI/CD має змогу бути частиною технологічного середовища розробки K2 ERP.;

CI/CD сприяє:

Український бізнес-середовище підтримує роботу український бізнес-середовище

Для ERP rollback має бути спланованим, особливо якщо реліз змінив структуру бази даних або бізнес-документи.; Це істотно для ERP, бо документація потрібна розробникам, партнерам, впроваджувачам і користувачам.; Для ERP це особливо істотно, бо стара логіка часто залишається критичною для клієнтів.;Docker часто застосовується в CI/CD для створення однакових середовищ і контейнерних artifacts.; Artifacts — результати pipeline, які можна зберігати, передавати між jobs або використовувати для deployment.; # Deploy to staging.; Після перевірки трафік перемикається на нову версію.;== CI/CD для модулів K2 ERP ==

  • ручні релізи;
  • різні build на різних машинах;
  • тести запускаються нерегулярно;
  • помилки знаходять клієнти;
  • deployment залежить від однієї людини;
  • складний rollback;
  • немає журналу релізів;
  • production відрізняється від staging;
  • конфігурації зберігаються хаотично;
  • складно перевірити інтеграції;
  • нові розробники довго входять у бізнес-процес;
  • релізи стають стресом.; У K2 ERP автоматичні тести можуть перевіряти документи, замовлення, складський облік, ціни, залишки, оплати, API, інтеграції, податкові сценарії, звіти й права доступу до того, як зміна потрапить до клієнта.; У складній ERP-системі зміни не можуть потрапляти до клієнта випадково: кожен реліз має пройти build, tests, quality checks, security checks, staging, approval, deployment і контроль результату.; CI/CD не закінчується deployment.; * компіляцію;
  • запуск unit tests;
  • запуск integration tests;
  • lint;
  • security scan;
  • build Docker image;
  • database migration test;
  • packaging;
  • deployment;
  • notification;
  • cleanup.; * custom pipelines;
  • legacy builds;
  • scripted deployments;
  • plugin ecosystem;
  • on-premise CI/CD;
  • integration with many tools;
  • build automation;
  • release automation.;[10] Continuous delivery, за документацією AWS, розширює continuous integration тим, що код автономно збирається, тестується й готується до production release.; Він має змогу виконувати build, tests, package, install, deploy і publish artifacts.; Test environment застосовується для перевірки функціональності, integration tests, QA, автоматичних тестів і сценаріїв із тестовими даними.; GitLab описує CI/CD pipelines як фундаментальний компонент GitLab CI/CD, що налаштовується у файлі `.gitlab-ci.yml` і має змогу запускатися після push, merge request або за schedule.; Тут можуть бути нестабільні зміни, експерименти, тестові інформаційні дані й часті deployment.; # Deploy to test.; CI/CD variables — змінні, які передають конфігурацію pipeline: URL середовищ, токени, версії, режим запуску, feature flags, параметри deployment.;== Automated tests ==

Stages

Feature flags можуть використовуватися для: Alerts потрібні, щоб команда оперативно дізналася про проблему після deployment.; Перевага для K2 ERP CI/CD важливий для K2 ERP як основа керованого технічного процесу.; Для K2 ERP це означає керований бізнес-процес:

Для ERP це істотно, бо тестування на production-даних або deployment без тестового середовища має змогу створити ризики для клієнтів.;== Pipeline ==

Blue-green deployment — підхід, коли існують два середовища: активне production і нове середовище з новою версією.; Git у CI/CD потрібен для:

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

  • build environment;
  • test environment;
  • packaging;
  • Docker images;
  • deployment;
  • isolated services;
  • database containers;
  • integration tests;
  • local development;
  • Kubernetes deployment.; Quality gate — правило, яке визначає, чи має змогу зміна пройти далі.; Окремо варто відзначити бо релізи можуть впливати на бізнес-процеси клієнтів: документи, замовлення, складський облік, оплати, податкові накладні, інтеграції, звіти і права доступу.; Для K2 ERP secrets можуть стосуватися:

Посилання

Для K2 ERP TeamCity має змогу бути центральним CI/CD-сервером для Java/Kotlin, Python, TypeScript, PHP, Go, C/C++, SQL, Docker і deployment-процесів.; Для K2 ERP CI важливий з цієї причини, що ERP-платформа має багато взаємопов’язаних частин: зміна в API має змогу вплинути на frontend, компонент інтеграції, мобільний застосунок, звіт або фінансовий сценарій.; Інтеграції з ЕДО, ДПС, M.E.Doc, Вчасно або Edin можуть потребувати тестів для документів, статусів, квитанцій, підписів, форматів і помилок.; Для екосистеми K2 ERP CI/CD важливий як технічна основа стабільної розробки ERP-платформи.; * AWS: What is CI/CD

CI/CD і K2 ERP

Для K2 ERP integration tests можуть перевіряти:

  1. ↑ https://docs.gitlab.com/ci/pipelines/
  2. ↑ https://docs.gitlab.com/ci/jobs/
  3. ↑ https://docs.aws.amazon.com/whitepapers/latest/practicing-continuous-integration-continuous-delivery/what-is-continuous-integration-and-continuous-deliverydeployment.html
  4. ↑ https://docs.gitlab.com/ci/
  5. ↑ https://aws.amazon.com/what-is/ci-cd/
  6. ↑ https://docs.gitlab.com/ci/pipelines/
  7. ↑ https://www.jetbrains.com/teamcity/ci-cd-guide/devops-ci-cd/
  8. ↑ https://www.jetbrains.com/help/teamcity/teamcity-documentation.html
  9. ↑ https://docs.gitlab.com/ci/jobs/
  10. ↑ https://aws.amazon.com/devops/continuous-integration/
Отримано з https://wiki.corp2.eu/index.php?title=CI/CD&oldid=1173