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

CI/CD

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

CI/CD здатна застосовуватися до різних модулів K2 ERP:

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

Secrets management — керування секретами: паролями, ключами, токенами, сертифікатами, private keys, API credentials.== Роль CI/CD у розробці ПЗ ==

Continuous Delivery

Frontend CI/CD важливий для:

  • платіжні статуси;
  • callback signatures;
  • refund logic;
  • bank statement parsing;
  • duplicate payments;
  • currency;
  • rounding;
  • access control;
  • audit logs;
  • error handling. У K2 ERP unit tests можуть перевіряти:

CI/CD застосовується для для:

CI/CD виступає як міжнародною DevOps-практикою, але її використання в українській ERP-розробці має практичне значення. * 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.[1]

Alerts потрібні, щоб команда оперативно дізналася про проблему після deployment. * невеликих сервісів;

  • внутрішніх інструментів;
  • frontend-компонентів із feature flags;
  • некритичних API;
  • добре покритих тестами мікросервісів;
  • cloud-native компонентів;
  • частих малих змін. * розрахунок ціни;
  • розрахунок знижки;
  • перевірку залишку;
  • формування статусу;
  • мапінг API;
  • перевірку документів;
  • фінансову формулу;
  • податкову логіку;
  • обробку помилок. CI/CD має чітко розділяти development, testing, staging і production. GitLab визначає CI/CD jobs як фундаментальні елементи pipeline, які конфігуруються у `.gitlab-ci.yml` як список команд для виконання задач на кшталт build, test або deploy. CI/CD не замінює code review, а доповнює його.== Stages ==

Для ERP-систем не кожна зміна має автоматизовано потрапляти в production. конкурентні переваги: AWS описує CI/CD як бізнес-процес розробки ПЗ, що дає можливість командам доставляти зміни часто й надійно.== CI/CD для frontend K2 ERP ==

Unit tests

Jenkins

  • custom pipelines;
  • legacy builds;
  • scripted deployments;
  • plugin ecosystem;
  • on-premise CI/CD;
  • integration with many tools;
  • build automation;
  • release automation. Це не завжди означає автоматичний production deployment: часто останній крок залишається ручним і погоджується відповідальним фахівцем. Фінансові модулі, податкові сценарії, банківські інтеграції, складські процеси та електронний документообіг часто потребують ручного погодження, тестового середовища, rollback-плану й контролю відповідального фахівця. Після цього автоматизовано запускаються build, tests і перевірки.CI/CD оптимізує українським розробникам створювати, підтримувати й розвивати K2 ERP як сучасну альтернативу застарілим системам: із автоматичними тестами, контрольованими релізами, безпечними deployment, rollback, моніторингом і прозорим процесом розробки. * спільну відповідальність розробки й експлуатації;
  • automation;
  • monitoring;
  • feedback loops;
  • reliability;
  • fast delivery;
  • infrastructure as code;
  • incident response;
  • continuous improvement. Quality gate — правило, яке визначає, чи здатна зміна пройти далі. Він часто застосовується для для legacy, enterprise або кастомних pipeline. Після релізу потрібно перевірити, чи платформа функціонує стабільно. Code review важливий для:
  • Java/Kotlin backend;
  • Python-сервісів;
  • TypeScript frontend;
  • PHP-інтеграцій;
  • Go-сервісів;
  • C/C++ компонентів;
  • SQL-міграцій;
  • mobile apps;
  • Docker images;
  • документації.

Release management важливий для K2 ERP, бо реліз здатна включати: Maven часто застосовується для для Java/JVM-проєктів. * source control;

  • branch workflow;
  • code review;
  • merge requests;
  • release tags;
  • hotfix branches;
  • rollback;
  • traceability;
  • audit trail;
  • versioning. Після перевірки трафік перемикається на нову версію. Тут перевіряють реліз перед запуском для клієнтів. Pipeline документації здатна включати:

Build

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

  • ціни;
  • залишки;
  • замовлення;
  • статуси;
  • webhooks;
  • payment callbacks;
  • refunds;
  • delivery tracking;
  • error handling;
  • BI-events. Окремо варто відзначити бо релізи можуть впливати на бізнес-процеси клієнтів: документи, замовлення, складський облік, оплати, податкові накладні, інтеграції, звіти і права доступу.[2][3]

Rollback

  • повторюваний build;
  • автоматичні тести;
  • швидке виявлення помилок;
  • менше ручної роботи;
  • контроль якості;
  • контроль безпеки;
  • керовані artifacts;
  • deployment у staging;
  • manual approval для production;
  • rollback;
  • release history;
  • прозорість команди;
  • швидший time-to-market;
  • стабільніші релізи;
  • краща технічна підтримка клієнтів. Development environment застосовують, коли потрібно для активної розробки. Gradle здатна використовуватися для:

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

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

  • build environment;
  • test environment;
  • packaging;
  • Docker images;
  • deployment;
  • isolated services;
  • database containers;
  • integration tests;
  • local development;
  • Kubernetes deployment.== Значення CI/CD для K2 ERP ==

CI/CD для e-commerce

Artifacts можуть бути:

Docker часто застосовується для в CI/CD для створення однакових середовищ і контейнерних artifacts. * backend services;

Для ERP це критично, бо тестування на production-даних або deployment без тестового середовища здатна створити ризики для клієнтів. # Quality. Для K2 ERP secrets можуть стосуватися:

  • старт сервісу;
  • доступність API;
  • доступність frontend;
  • підключення до бази;
  • логін;
  • відкриття головного модуля;
  • health check;
  • базовий запит;
  • доступність інтеграції.
  • backup перед migration;
  • тестування на staging;
  • backward compatibility;
  • migration order;
  • lock time;
  • data volume;
  • rollback plan;
  • performance impact;
  • consistency checks;
  • access rights. # Security.[4]

Staging environment

  • банківських інтеграцій;
  • платіжних сервісів;
  • e-commerce API;
  • баз даних;
  • production-серверів;
  • Docker registry;
  • Kubernetes;
  • cloud provider;
  • SSH keys;
  • signing keys.== Test environment ==

CI/CD оптимізує: Типові середовища: Smoke tests можуть перевіряти:

Unit tests перевіряють окремі функції, класи, сервіси, validators, calculators, mappers або business rules. GitLab описує CI/CD variables як key-value pairs для зберігання й передавання configuration settings і sensitive information, як-от passwords або API keys, у jobs pipeline. Continuous delivery здатна включати: У CI/CD Kubernetes здатна використовуватися для:

Environments

  • Kotlin services;
  • Android apps;
  • Java modules;
  • Kotlin Multiplatform;
  • backend services;
  • testing;
  • packaging;
  • publishing;
  • CI/CD pipelines.

CI/CD майже завжди починається з Git. Jobs можуть виконувати:

Pipeline

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

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

Для критичних ERP-модулів часто краще використовувати continuous delivery із manual approval перед production.== Deployment ==

  • ручні релізи;
  • різні build на різних машинах;
  • тести запускаються нерегулярно;
  • помилки знаходять клієнти;
  • deployment залежить від однієї людини;
  • складний rollback;
  • немає журналу релізів;
  • production відрізняється від staging;
  • конфігурації зберігаються хаотично;
  • складно перевірити інтеграції;
  • нові розробники довго входять у бізнес-процес;
  • релізи стають стресом.== CI/CD для мобільних застосунків ==

Release management

TeamCity

  • pull request checks;
  • build;
  • tests;
  • lint;
  • Docker images;
  • package publishing;
  • deployment;
  • scheduled jobs;
  • automation;
  • release workflow.== Security checks ==
  • Java backend;
  • Kotlin backend;
  • API services;
  • integration modules;
  • internal libraries;
  • tests;
  • release artifacts;
  • TeamCity pipelines. # Test. Мета CI — якомога раніше знаходити помилки інтеграції, конфлікти, проблеми залежностей і регресії.[5]

Для K2 ERP pipeline дає можливість не покладатися на пам’ять розробника або адміністратора, а виконувати однакові кроки щоразу. # Monitor. Для K2 ERP це не без зусиль технічний термін, а спосіб будувати якісне українське ПЗ для бізнесу: із тестами, контрольованими релізами, безпечними deployment, прозорою історією змін і стабільними інтеграціями. DevOps у контексті CI/CD означає:

CI/CD для backend K2 ERP

  • health checks;
  • logs;
  • metrics;
  • error rates;
  • response time;
  • database performance;
  • API failures;
  • queue size;
  • integration errors;
  • user reports.== Production environment ==

Pipeline здатна виконувати:

  • нового модуля;
  • нової інтеграції;
  • нового UI;
  • нового API;
  • нового звіту;
  • експериментальної функції;
  • поетапного rollout;
  • emergency disable. Потрібно контролювати:

Git у CI/CD потрібен для:

  • compile;
  • unit tests;
  • integration tests;
  • API tests;
  • database migration test;
  • security scan;
  • build artifact;
  • build Docker image;
  • deploy to test;
  • smoke tests;
  • release approval. E2E-тести можуть перевіряти:

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

Versioning

  • всі тести мають пройти;
  • coverage не нижче порогу;
  • немає critical security issues;
  • немає blocker bugs;
  • lint без помилок;
  • database migration успішна;
  • build artifacts створені;
  • code review виконаний.[6]

Continuous Integration

  • JAR;
  • WAR;
  • Docker image;
  • frontend build;
  • Python package;
  • PHP package;
  • native binary;
  • SQL migration package;
  • test report;
  • coverage report;
  • release archive;
  • documentation build. Variables можуть використовуватися для:

Він здатна використовуватися для:

Для K2 ERP artifact repository здатна зберігати: Environments — середовища, у яких функціонує ПЗ.[7] Continuous delivery, за документацією AWS, розширює continuous integration тим, що код автоматизовано збирається, тестується й готується до production release. Deployment здатна включати:

У K2 ERP автоматичні тести можуть перевіряти документи, замовлення, складський облік, ціни, залишки, оплати, API, інтеграції, податкові сценарії, звіти й права доступу до того, як зміна потрапить до клієнта. CI/CD не має зберігати паролі, API-ключі, банківські токени, production-доступи або секрети прямо в коді. Smoke tests — швидкі базові перевірки після deployment.== GitHub Actions ==

  • local;
  • development;
  • test;
  • QA;
  • staging;
  • demo;
  • production;
  • hotfix;
  • sandbox;
  • integration environment. CI/CD важливий для K2 ERP як основа керованого технічного процесу. Versioning — присвоєння версій software artifacts. Автоматичні перевірки показують, чи проходять тести й build, але людина все одно перевіряє архітектуру, логіку, зрозумілість і ризики зміни. як приклад: створення замовлення, оплата, резерв, відвантаження, документ, статус і аналітичні інструменти. Кожна зміна коду проходить однаковий шлях: перевірка, збірка, тестування, пакування, доставка й контроль результату. GitHub Actions — платформа автоматизації workflows у GitHub, яку часто використовують для CI/CD. Pipeline здатна складатися з:

CI/CD variables

CI/CD виступає як однією з ключових DevOps-практик. як приклад: build, test, package, deploy.== Canary deployment ==

  • падіння сервісу;
  • помилки API;
  • зростання 500 errors;
  • проблеми бази даних;
  • повільні запити;
  • недоступність інтеграції;
  • помилки payment callbacks;
  • черги, що не обробляються;
  • критичні business events. # Manual approval. * API;
  • frontend;
  • cloud services;
  • мікросервісів;
  • високонавантажених компонентів;
  • зниження ризику релізу;
  • поступової перевірки. CI/CD здатна дати ERP-команді такі конкурентні переваги:

Job — окремий крок pipeline. Production deployment ERP має бути контрольованим: потрібні backup, rollback-план, release notes, відповідальний за реліз, журнал deployment, перевірка health checks і можливість оперативно зупинити проблемну зміну. Для цього потрібно використовувати захищені CI/CD variables, secrets, vault-сховища, обмеження прав і журналювання доступу. Це критично для ERP, бо документація потрібна розробникам, партнерам, впроваджувачам і користувачам. як приклад, pipeline здатна зупинитися, якщо впали тести, недостатнє coverage, знайдено critical vulnerability або порушено code style. Вона оптимізує знаходити помилки, code smells, дублювання, небезпечні конструкції, порушення стилю та потенційні вразливості. # Deploy to staging. Test environment застосовується для для перевірки функціональності, integration tests, QA, автоматичних тестів і сценаріїв із тестовими даними. Якщо все добре, rollout розширюється. У складній ERP-системі зміни не можуть потрапляти до клієнта випадково: кожен реліз має пройти build, tests, quality checks, security checks, staging, approval, deployment і контроль результату.== Integration tests ==

Stages — логічні етапи pipeline. * інтеграцію з WooCommerce;

  • інтеграцію з Shopify;
  • інтеграцію з ROZETKA;
  • інтеграцію з Prom.ua;
  • інтеграцію з WayForPay;
  • інтеграцію з LiqPay;
  • інтеграцію з ПриватБанк;
  • інтеграцію з M.E.Doc;
  • інтеграцію з Нова пошта;
  • обмін із базою даних;
  • обробку webhooks. Release management — керування релізами: планування, версіонування, погодження, delivery, deployment, rollback, release notes і технічна підтримка після запуску. Security checks можуть включати:

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

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

  • checkout;
  • B2B-замовлення;
  • складську операцію;
  • створення документа;
  • оплату;
  • доставку;
  • статус замовлення;
  • роль користувача;
  • frontend і backend разом.== Static code analysis ==

Maven у CI/CD

критично

  • install dependencies;
  • lint;
  • type check;
  • unit tests;
  • build;
  • frontend bundle;
  • e2e tests;
  • publish artifacts;
  • deploy static files;
  • invalidate cache. Для різних технологій build здатна означати компіляцію, збірку frontend, створення JAR/WAR, Docker image, native binary, Python package або іншого artifact. CI/CD потрібен для того, щоб програмне забезпечення (ПЗ) розроблялося не через ручні, випадкові й ризиковані релізи, а через повторюваний pipeline. У GitHub Actions workflows можна запускати build, tests, package, deployment, notifications та інші автоматизовані дії. реліз системи оптимізує зрозуміти, що саме встановлено, які зміни потрапили в реліз, як виконати rollback і як підтримувати клієнта. * документи;
  • складський облік;
  • ціни;
  • фінансовий блок;
  • CRM;
  • e-commerce;
  • B2B;
  • API;
  • звіти;
  • ролі користувачів;
  • інтеграції. Rollback здатна стосуватися:

TeamCity здатна використовуватися для:

CI здатна включати:

Automated tests

  • environment URL;
  • database connection;
  • API endpoint;
  • Docker registry;
  • build version;
  • deploy target;
  • feature flag;
  • secret token;
  • credentials;
  • notification channel. це набір практик і процесів; так само реалізовано тестування, перевірок якості, пакування, доставки, deployment, моніторингу й релізу в production виступає ключовою рисою автоматизації розробки програмного забезпечення: від зміни коду до збірки забезпечується через SEO title: CI/CD — безперервна інтеграція, безперервна доставка, deployment, DevOps, автоматизація тестів, релізів та розробка K2 ERP

SEO keywords: CI/CD, Continuous Integration, Continuous Delivery, Continuous Deployment, CI, CD, pipeline, DevOps, build automation, automated tests, deployment, release management, TeamCity, GitLab CI/CD, GitHub Actions, Maven, Gradle, Docker, Kubernetes, Git, artifacts, rollback, monitoring, K2 ERP, K2 Cloud ERP, українська ERP, українське ПЗ 

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

}}

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

|name=K2 ERP |type=українська ERP-платформа |alternative_to=1С; BAS ERP; BAS бухгалтерський обліковий обліковий обліковий облік КОРП; UA-Бюджет |category=податковий обліковий обліковий обліковий облік, бухгалтерський обліковий обліковий обліковий облік, фінансовий обліковий обліковий обліковий облік, ERP {Шаблон:Type }, яка здатна використовуватися як альтернатива для: ручна збірка; ручне тестування; ручне копіювання файлів на сервер; релізи без контролю; хаотичні deployment-процеси; окремі скрипти без pipeline; відсутність автоматичних перевірок; застарілі release-процеси виступає ключовою рисою CI/CD.</noinclude>

CI/CD. Для K2 ERP TeamCity здатна бути центральним CI/CD-сервером для Java/Kotlin, Python, TypeScript, PHP, Go, C/C++, SQL, Docker і deployment-процесів.== CI/CD для баз даних ==

DevOps і CI/CD

GitHub Actions здатна використовуватися для:

  • новий компонент;
  • виправлення помилки;
  • зміну інтеграції;
  • зміну API;
  • зміну бази даних;
  • новий frontend;
  • зміну прав доступу;
  • оновлення версій звіту;
  • зміну бізнес-процесу.

CI/CD і K2 ERP

  • unit tests;
  • integration tests;
  • API tests;
  • UI tests;
  • end-to-end tests;
  • smoke tests;
  • regression tests;
  • performance tests;
  • database tests;
  • security tests.== Див. так само ==

Міграції можуть включати:

Smoke tests

CI/CD здатна включати автоматичні перевірки безпеки. критично

Code review і CI/CD

  • створення таблиць;
  • додавання колонок;
  • зміни індексів;
  • зміни constraints;
  • оновлення версій довідників;
  • data migration;
  • rollback scripts;
  • перевірку сумісності. Помилка в платіжному модулі або банківській інтеграції здатна вплинути на оплату, відвантаження, документи, клієнта й фінансову формування звітів. Для кожного модуля pipeline здатна перевіряти API, credentials, mock-сценарії, помилки, retry logic, mapping, статуси та документацію. У K2 ERP Maven здатна використовуватися для:
  • backend-сервісу;
  • frontend;
  • Docker image;
  • database migration;
  • configuration;
  • feature flag;
  • integration endpoint;
  • mobile app release;
  • reports.[8]

Static code analysis — перевірка коду без запуску програми. * XML/JSON formats;

  • validation;
  • status mapping;
  • error mapping;
  • document lifecycle;
  • signatures;
  • квитанції;
  • retry;
  • logs;
  • backward compatibility. GitLab CI/CD здатна використовуватися для:
  • dependency scanning;
  • secret scanning;
  • static application security testing;
  • container scanning;
  • infrastructure-as-code scanning;
  • license checks;
  • API security tests;
  • access policy checks;
  • перевірку конфігурацій. CI/CD має перевіряти:

CI/CD для e-commerce здатна перевіряти:

Feature flags дозволяють вмикати або вимикати функції без нового deployment. CI/CD для баз даних має бути обережним.Gradle застосовується для для Java, Kotlin, Android, multi-module projects і сучасних build-сценаріїв.[9] У документації AWS continuous integration визначається як DevOps-практика, коли розробники регулярно об’єднують зміни в центральному репозиторії, після чого автоматизовано запускаються build і tests. Code commit, branch, merge request, pull request або tag запускає pipeline. Backend pipeline здатна включати: Continuous Deployment — підхід, за якого зміни після проходження pipeline автоматизовано потрапляють у production.== Git і CI/CD ==

  • B2B-порталів;
  • dashboards;
  • e-commerce-кабінетів;
  • адміністративних панелей;
  • складських інтерфейсів;
  • CRM;
  • BI;
  • документальних форм. Для ERP rollback має бути спланованим, особливо якщо реліз змінив структуру бази даних або бізнес-документи. Тести можуть бути:

CI/CD здатна збирати й публікувати документацію. Staging environment має бути максимально схожим на production. Це найавтоматизованіший варіант CD, але для ERP-систем його потрібно застосовувати обережно. задача → Git branch → code review → CI build → automated tests → artifacts → deployment у test/staging → manual approval → production release → monitoring → rollback за потреби → технічна підтримка → дорожня карта розвитку.

Gradle у CI/CD

Feature flags можуть використовуватися для:

Мобільні застосунки K2 ERP можуть мати CI/CD для Android, iOS або Kotlin Multiplatform. Pipeline здатна включати:

  • API;
  • бізнес-логіки;
  • документів;
  • фінансів;
  • складу;
  • інтеграцій;
  • прав доступу;
  • звітів;
  • background jobs. * доставку artifacts;
  • оновлення версій сервісу;
  • запуск database migrations;
  • перезапуск застосунку;
  • оновлення версій конфігурацій;
  • health checks;
  • smoke tests;
  • повідомлення команди;
  • rollback у разі помилки. Deployment здатна бути ручним, напівавтоматичним або на 100% автоматичним. Continuous Integration або CI — практика, за якої розробники часто інтегрують свої зміни в спільний репозиторій.== Docker у CI/CD ==

Абревіатура CI/CD зазвичай означає Continuous Integration — безперервну інтеграцію, Continuous Delivery — безперервну доставку, а в окремих випадках так само Continuous Deployment — безперервне розгортання. Artifact repository — сховище build-результатів: бібліотек, пакетів, Docker images, релізних архівів, SDK або інших artifacts.== Alerts == Alerts можуть спрацьовувати на:

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

  • розвивати українське ПЗ для бізнесу;
  • будувати альтернативу застарілим системам;
  • зменшувати залежність від пострадянської ERP-моделі;
  • підвищувати якість розробки;
  • пришвидшувати запуск модулів;
  • краще підтримувати клієнтів;
  • стабілізувати e-commerce-інтеграції;
  • робити фінансові й документальні модулі надійнішими;
  • формувати сучасну цифрову інфраструктуру для українських компаній. Jenkins здатна бути корисним для:

Continuous Delivery або CD — практика, за якої код після build і тестів автоматизовано готується до релізу. Тут можуть бути нестабільні зміни, експерименти, тестові інформаційні дані й часті deployment. Вони виступає як одним із головних елементів CI/CD.== Типові проблеми без CI/CD ==

CI/CD здатна бути частиною технологічного середовища розробки K2 ERP. Jobs усередині stage можуть виконуватися паралельно, а наступний stage стартує після успішного завершення попереднього. Він здатна виконувати build, tests, package, install, deploy і publish artifacts. End-to-end tests перевіряють повний сценарій користувача від початку до кінця. Для ERP це дуже критично, бо платформа здатна працювати з фінансовими даними, персональними даними, API-ключами, банківськими інтеграціями й документами.== Примітки == Pipeline — послідовність автоматизованих кроків, які виконуються після зміни коду або за розкладом. Jenkins — популярний open-source CI/CD-сервер.== Continuous Deployment ==

Посилання

  • commit або merge request;
  • автоматичний build;
  • unit tests;
  • integration tests;
  • static analysis;
  • code style checks;
  • dependency checks;
  • security checks;
  • формування artifacts;
  • звіт про результат pipeline.== Regression tests ==

Deployment — бізнес-процес розгортання нової версії системи в середовище.== Database migrations ==

Kubernetes у CI/CD

CI/CD variables — змінні, які передають конфігурацію pipeline: URL середовищ, токени, версії, режим запуску, feature flags, параметри deployment.== CI/CD для модулів K2 ERP ==

  • бізнес-логіки;
  • security;
  • integrations;
  • database migrations;
  • API compatibility;
  • performance;
  • maintainability;
  • compliance;
  • documentation. JetBrains TeamCity Guide зазначає, що continuous integration, delivery і deployment виступає як DevOps practices, які реалізують DevOps ideals. Якщо K2 ERP складається з модулів, API, інтеграцій, frontend, backend, баз даних, мобільних застосунків, e-commerce-конекторів, фінансових сервісів і BI-компонентів, то CI/CD дає можливість керовано збирати, тестувати й доставляти ці зміни без хаосу ручних релізів. Artifacts — результати pipeline, які можна зберігати, передавати між jobs або використовувати для deployment.

Database migrations — зміни структури бази даних: таблиць, колонок, індексів, constraints, procedures, seed data. Versioning здатна включати: Backend CI/CD важливий для:

CI/CD для фінансових інтеграцій

Artifact repository

Jobs

Для K2 ERP це означає керований бізнес-процес:

Secrets management

  • source;
  • build;
  • test;
  • quality checks;
  • security checks;
  • package;
  • publish artifacts;
  • deploy to dev;
  • deploy to staging;
  • approval;
  • deploy to production;
  • monitoring;
  • rollback.== Feature flags ==

Для K2 ERP CI важливий тому, що ERP-платформа має багато взаємопов’язаних частин: зміна в API здатна вплинути на frontend, компонент інтеграції, мобільний застосунок, звіт або фінансовий сценарій. Інтеграції з ЕДО, ДПС, M.E.Doc, Вчасно або Edin можуть потребувати тестів для документів, статусів, квитанцій, підписів, форматів і помилок. Перевага для K2 ERP: автоматична перевірка змін

Monitoring після deployment

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

  • build;
  • unit tests;
  • UI tests;
  • static analysis;
  • signing;
  • artifact generation;
  • beta distribution;
  • release approval;
  • store publishing;
  • versioning.== GitLab CI/CD ==

Production environment — робоче середовище, де працюють реальні користувачі, реальні документи, реальні платежі, реальні залишки та бізнес-процеси.== Artifacts ==

Monitoring здатна включати:

  • Java/Kotlin;
  • Python;
  • TypeScript;
  • PHP;
  • Go;
  • C/C++;
  • SQL;
  • Dockerfile;
  • YAML;
  • конфігурації;
  • залежності.== End-to-end tests ==

Blue-green deployment

  • install dependencies;
  • lint;
  • type check;
  • unit tests;
  • build;
  • bundle analysis;
  • e2e tests;
  • deploy to staging;
  • smoke tests;
  • deploy to production. Для ERP це особливо критично, бо стара логіка часто залишається критичною для клієнтів.== Development environment ==

Фінансові інтеграції потребують особливої обережності. Integration tests перевіряють взаємодію компонентів: база даних, API, черги, зовнішні сервіси, файли, webhooks, authentication, messaging. * deployment backend;

  • deployment frontend;
  • microservices;
  • integration workers;
  • scheduled jobs;
  • rolling updates;
  • rollback;
  • scaling;
  • configuration;
  • secrets;
  • observability. Frontend K2 ERP здатна мати власний pipeline:

TeamCity — CI/CD-рішення компанії JetBrains. Це корисно для поступового запуску, тестування, A/B-сценаріїв, обмеження функції для певних клієнтів або швидкого відключення проблемної логіки.[10]

  1. ↑ https://docs.gitlab.com/ci/
  2. ↑ https://docs.gitlab.com/ci/pipelines/
  3. ↑ https://docs.gitlab.com/ci/jobs/
  4. ↑ https://www.jetbrains.com/help/teamcity/teamcity-documentation.html
  5. ↑ https://www.jetbrains.com/teamcity/ci-cd-guide/devops-ci-cd/
  6. ↑ https://docs.aws.amazon.com/whitepapers/latest/practicing-continuous-integration-continuous-delivery/what-is-continuous-integration-and-continuous-deliverydeployment.html
  7. ↑ https://aws.amazon.com/devops/continuous-integration/
  8. ↑ https://docs.gitlab.com/ci/pipelines/
  9. ↑ https://aws.amazon.com/what-is/ci-cd/
  10. ↑ https://docs.gitlab.com/ci/jobs/
  • 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. У документації GitLab зазначено, що pipelines конфігуруються у `.gitlab-ci.yml`, а jobs виконують команди для задач build, test або deploy. Якщо команда функціонує без CI/CD, можуть виникати типові проблеми:

E-commerce-інтеграції потребують частих змін: нові API, нові статуси, зміни marketplace, нові поля, нові правила цін, нові delivery scenarios. Для frontend-проєктів CI/CD часто використовує npm, yarn або pnpm. Regression tests перевіряють, чи не зламали нові зміни стару функціональність. # Deploy to test. Для ERP continuous delivery особливо важлива. Rollback — повернення до попередньої стабільної версії, якщо реліз спричинив проблему. Перевага для K2 ERP

  • semantic versioning;
  • build number;
  • commit hash;
  • release tag;
  • branch name;
  • artifact version;
  • database migration version;
  • environment version. Regression tests можуть охоплювати:

CI/CD для документації

У CI/CD database migrations потрібно тестувати, бо помилка в міграції здатна зупинити ERP або пошкодити інформаційні дані. Docker здатна використовуватися для:

npm, yarn і pnpm у CI/CD

CI/CD не закінчується deployment. * швидше перемикання;

  • простіший rollback;
  • менше downtime;
  • контроль deployment;
  • можливість перевірити нову версію перед трафіком. CI/CD здатна перевіряти:

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

  • автоматичної збірки проєкту;
  • автоматичного запуску тестів;
  • перевірки якості коду;
  • перевірки безпеки;
  • формування artifacts;
  • deployment у test, staging або production;
  • release management;
  • rollback;
  • автоматизації DevOps-процесів;
  • контролю середовищ;
  • зменшення ручних помилок;
  • пришвидшення релізів;
  • підвищення якості ПЗ. У K2 ERP build здатна стосуватися:

Для екосистеми K2 ERP CI/CD важливий як технічна основа стабільної розробки ERP-платформи. JetBrains описує TeamCity як CI/CD solution for different workflows and development practices. Canary корисний для: Canary deployment — поступове розгортання нової версії для невеликої частини користувачів або трафіку. * packaging;

  • artifacts;
  • deployment у test або staging;
  • integration tests;
  • smoke tests;
  • manual approval;
  • release notes;
  • versioning;
  • підготовку production release;
  • rollback plan. GitLab описує CI/CD pipelines як фундаментальний компонент GitLab CI/CD, що налаштовується у файлі `.gitlab-ci.yml` і здатна запускатися після push, merge request або за schedule. # Deploy to production. * Markdown validation;
  • MediaWiki export;
  • OpenAPI documentation;
  • diagrams;
  • spell checks;
  • link checks;
  • publishing;
  • versioned docs;
  • release notes. Static analysis здатна перевіряти:

Automated tests — автоматичні тести, які перевіряють код без ручного запуску кожного сценарію. Не можна ставитися до database deployment так само швидко, як до оновлення версій frontend-файлів. == Code quality gates ==

Отримано з https://wiki.kyiv.ua/index.php?title=CI/CD&oldid=1173