Автоматическая интеграция что это

Интеграция корпоративного приложения с внешними системами

Ни одна информационная система не способна решать все задачи компании. Между различными приложениями возникает необходимость обмена данными, делать это вручную сложно и занимает много времени. Необходима автоматическая интеграция с помощью таких технологий, как SOAP, REST, или готовых коннекторов. О технологиях интеграции и их применении в SimpleOne расскажем в нашей статье.

Интеграции в корпоративных приложениях

Корпоративные приложения получают, обрабатывают и передают данные. Зачастую для выполнения одного бизнес-процесса компания использует несколько информационных систем, и между ними происходит обмен данными. Одна система получает информацию от пользователя и передаёт в другие через каналы интеграции. Например, для авторизации на сервисном портале пользователь не создаёт новую учетную запись: система получает данные из Active Directory, а приложение контроля доступа загружает справочник сотрудников из базы данных ERP SAP.

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

Простейшие способы интеграции — это обмен файлами и сообщениями или обращение к общей базе данных. Эти способы имеют множество недостатков, особенно в эпоху распространения веб-приложений. Форматы файлов могут отличаться, а выгрузка, загрузка и конвертация — это дополнительное влияние человеческого фактора и труда. Давать всем подряд доступ к одной базе данных и контролировать правильность её использования различными приложениями — серьёзный риск для целостности и безопасности хранения данных.

На смену этим архаичным и неудобным способам интеграции пришли современные технологии, использующие API (интерфейсы прикладного программирования) для связи веб-приложений. Разработчики создают свои информационные системы с API-интерфейсами, чтобы приложения могли взаимодействовать и передавать данные друг другу. Существуют два основных стиля API — SOAP и REST, они имеют различные архитектуры, но в большинстве случаев используют общий транспорт — HTTP-протокол.

Технологии интеграции

SOAP и REST решают одинаковую задачу: позволяют разработчикам с помощью API настраивать обмен данными между приложениями. Но если SOAP является протоколом обмена информацией, то REST — это стиль или набор рекомендаций, которым должен следовать разработчик для предоставления веб-службы — RESTful, то есть разработанной с учётом требований REST и не нарушающей тех ограничений, которые он накладывает.

SOAP — протокол, REST — архитектурный стиль

SOAP (Simple Object Access Protocol) — отлично стандартизированный и давно используемый протокол. Это одна из причин, по которой его выбирают как API корпоративных приложений. Он работает поверх протоколов HTTP, SMTP, TCP или UDP, но передаёт данные только в формате XML. Для устаревших систем и тех, которые производят сложные транзакции, а также предъявляют высокие требования к безопасности, SOAP всё ещё хороший вариант. Он широко применяется в банковских и других финансовых приложениях, CRM, коммунальными службами и при оказании телекоммуникационных услуг. Там, где важна стабильность и целостность данных, используют SOAP, например, работа светофоров, канализации и электроснабжения города должна всегда выполняться безотказно и предсказуемо. Возможность асинхронной передачи данных по SMTP делает этот протокол незаменимым для интеграции в системах с нестабильным каналом связи.

REST (REpresentational State Transfer) — довольно молодой, но очень популярный архитектурный стиль для создания интеграционных API. Он приобрёл популярность у разработчиков в 2018 году, и на текущий момент большинство интернет-сервисов его используют как общедоступный API-интерфейс. Twitter, WordPress, Google Maps и другие известные приложения имеют REST API для взаимодействия с другими веб-сервисами и пользовательскими сайтами.

Для обмена данными REST использует только HTTP в качестве транспортного протокола, но форматы сообщений могут быть любыми — HTML, JSON, XML, YAML или простой текст. Универсальным является формат JSON (JavaScript Object Notatio): его легко анализировать, у него простой синтаксис и он не зависит от языка программирования. В JSON используется меньше слов, его проще писать и читать, такие сообщения имеют меньший вес, поэтому скорость их передачи выше, чем с XML.

REST — простой, удобный и универсальный способ интеграции корпоративных приложений, в большинстве случаев веб-сервисы RESTful могут взаимодействовать с любыми другими сервисами.

SOAP vs REST. REST работает быстрее, а разработка RESTful-сервисов проще. SOAP взаимодействует с операциями, поэтому лучше подходит для реализации транзакций и сложной логики. Кроме того, SOAP может работать с любым протоколом транспортного уровня вместо HTTP и используется в большинстве устаревших информационных систем, с которыми может потребоваться интеграция.

Для чего нужны коннекторы

Для того чтобы упростить настройку взаимодействия между информационными системами, администратор может использовать коннекторы. Коннектор — это готовое решение для взаимодействия с определённым приложением, например системой мониторинга, SAP, SharePoint, 1С и другими. Достаточно указать адрес внешней системы и задать параметры обмена данными, и коннектор сам будет отвечать за взаимодействие, конвертацию и проверку передаваемых сообщений.

Настройку коннекторов администратор выполняет с использованием графического интерфейса приложения (GUI) без необходимости программирования, такой подход отлично вписывается в концепцию No Code.

Пример реализации коннектора — взаимодействие ITSM-системы и системы мониторинга. Для настройки их интеграции администратор ITSM вводит адрес внешней системы, настраивает набор событий, которые должен принимать коннектор, и правила их обработки. Таким образом, ITSM-система оперативно получает информацию от системы мониторинга — коннектор обрабатывает поступающие данные и в соответствии с заданными правилами производит действия с данными ITSM-системы.

Способы интеграции в SimpleOne

Интеграция SimpleOne с другими корпоративными приложениями настраивается через REST API, интерфейс позволяет создавать, читать и обновлять данные в таблицах платформы.

REST-клиент

Чтобы связать стороннее приложение с SimpleOne, администратор должен в редакторе REST-запросов (REST Client) создать запрос к внешнему сервису (REST Request), а также запланировать его регулярное исполнение. В панели администрирования создаётся REST-запрос, для него указывается заголовок, дополнительные методы запроса и их параметры при необходимости, а также профили аутентификации.

Настройку REST-запросов и REST Bot Engine может выполнить администратор платформы с помощью GUI без глубоких знаний API и навыков программирования.

Настройка REST API в SimpleOne: пример настройки запроса для интеграции co Slack Настройка REST API в SimpleOne: пример настройки заголовка запроса Настройка REST API в SimpleOne: пример настройки дополнительных методов

Коннекторы

Отдельно в SimpleOne реализован коннектор для интеграции с мессенджерами и системами искусственного интеллекта — REST Bot Engine. Он позволяет настроить взаимодействие с чат-ботами и передавать информацию о происходящих в системе событиях в мессенджеры ответственных сотрудников. Например, при создании пользователем инцидента члены группы технической поддержки получат сообщение об этом прямо в свой мессенджер.

REST API

ESM-платформа SimpleOne предлагает задокументированный набор готовых операций с данными для взаимодействия сторонних систем с нашей платформой посредством REST API.

Scripted REST API

Когда готовых методов для работы сторонней системы с данными SimpleOne недостаточно, можно создать свои собственные сценарии обработки запросов с помощью инструмента Scripted REST API. Для этого достаточно создать новый модуль API, с помощью low-code-инструментария настроить действия и параметры, после чего связать параметры запросов к API с созданными модулями и действиями.

Это позволит настроить сложную логику обработки REST-запросов от внешних систем.

Заключение

Наличие API для веб-приложения — это общепринятый стандарт корпоративной интеграции. Он позволяет бизнес-платформам, решающим различные задачи, взаимодействовать без дополнительной разработки. В SimpleOne реализованы no-code-инструменты для настройки запросов к внешним системам, REST API с возможностью его расширения через интерфейс системы, а также универсальные и специализированные коннекторы к популярным информационным системам. Всё это позволяет быстро настраивать взаимодействие со сторонними сервисами, мессенджерами и другими приложениями. Основные настройки производятся с помощью графического интерфейса, не требующего глубоких знаний языков программирования от администратора.

Источник

Что такое CI/CD? Разбираемся с непрерывной интеграцией и непрерывной поставкой

В преддверии старта курса «CI/CD на AWS, Azure и Gitlab» подготовили для вас перевод полезного материала.

Непрерывная интеграция (Continuous Integration, CI) и непрерывная поставка (Continuous Delivery, CD) представляют собой культуру, набор принципов и практик, которые позволяют разработчикам чаще и надежнее развертывать изменения программного обеспечения.

CI/CD — это одна из DevOps-практик. Она также относится и к agile-практикам: автоматизация развертывания позволяет разработчикам сосредоточиться на реализации бизнес-требований, на качестве кода и безопасности.

Определение CI/CD

Непрерывная интеграция — это методология разработки и набор практик, при которых в код вносятся небольшие изменения с частыми коммитами. И поскольку большинство современных приложений разрабатываются с использованием различных платформ и инструментов, то появляется необходимость в механизме интеграции и тестировании вносимых изменений.

С технической точки зрения, цель CI — обеспечить последовательный и автоматизированный способ сборки, упаковки и тестирования приложений. При налаженном процессе непрерывной интеграции разработчики с большей вероятностью будут делать частые коммиты, что, в свою очередь, будет способствовать улучшению коммуникации и повышению качества программного обеспечения.

Непрерывная поставка начинается там, где заканчивается непрерывная интеграция. Она автоматизирует развертывание приложений в различные окружения: большинство разработчиков работают как с продакшн-окружением, так и со средами разработки и тестирования.

Инструменты CI/CD помогают настраивать специфические параметры окружения, которые конфигурируются при развертывании. А также CI/CD-автоматизация выполняет необходимые запросы к веб-серверам, базам данных и другим сервисам, которые могут нуждаться в перезапуске или выполнении каких-то дополнительных действий при развертывании приложения.

Непрерывная интеграция и непрерывная поставка нуждаются в непрерывном тестировании, поскольку конечная цель — разработка качественных приложений. Непрерывное тестирование часто реализуется в виде набора различных автоматизированных тестов (регрессионных, производительности и других), которые выполняются в CI/CD-конвейере.

Зрелая практика CI/CD позволяет реализовать непрерывное развертывание: при успешном прохождении кода через CI/CD-конвейер, сборки автоматически развертываются в продакшн-окружении. Команды, практикующие непрерывную поставку, могут позволить себе ежедневное или даже ежечасное развертывание. Хотя здесь стоит отметить, что непрерывная поставка подходит не для всех бизнес-приложений.

Непрерывная интеграция улучшает коммуникации и качество

Непрерывная интеграция — это методология разработки, основанная на регламентированных процессах и автоматизации. При внедренной непрерывной интеграции разработчики часто коммитят свой код в репозиторий исходного кода. И большинство команд придерживается правила коммитить как минимум один раз в день. При небольших изменениях проще выявлять дефекты и различные проблемы, чем при больших изменениях, над которыми работали в течение длительного периода времени. Кроме того, работа с короткими циклами коммитов уменьшает вероятность изменения одной и той же части кода несколькими разработчиками, что может привести к конфликтам при слиянии.

Команды, внедряющие непрерывную интеграцию, часто начинают с настройки системы контроля версий и определения порядка работы. Несмотря на то что коммиты делаются часто, реализация фич и исправление багов могут выполняться довольно долго. Для контроля того, какие фичи и код готовы существует несколько подходов.

Многие используют фича-флаги (feature flag) — механизм для включения и выключения функционала в рантайме. Функционал, который еще находится в стадии разработки, оборачивается фича-флагами и развертывается из master-ветки в продакшн, но отключается до тех пор, пока не будет полностью готов к использованию. По данным недавнего исследования 63 процента команд, использующих фича-флаги, говорят об улучшении тестируемости и повышении качества программного обеспечения. Для работы с фича-флагами есть специальные инструменты, такие как CloudBees Rollout, Optimizely Rollouts и LaunchDarkly, которые интегрируются в CI/CD и позволяют выполнять конфигурацию на уровне фич.

Другой способ работы с фичами — использование веток в системе контроля версий. В этом случае надо определить модель ветвления (например, такую как Gitflow) и описать как код попадает в ветки разработки, тестирования и продакшена. Для фич с длительным циклом разработки создаются отдельные фича-ветки. После завершения работы над фичей разработчики сливают изменения из фича-ветки в основную ветку разработки. Такой подход работает хорошо, но может быть неудобен, если одновременно разрабатывается много фич.

Этап сборки заключается в автоматизации упаковки необходимого программного обеспечения, базы данных и других компонент. Например, если вы разрабатываете Java-приложение, то CI упакует все статические файлы, такие как HTML, CSS и JavaScript, вместе с Java-приложением и скриптами базы данных.

CI не только упакует все компоненты программного обеспечения и базы данных, но также автоматически выполнит модульные тесты и другие виды тестирования. Такое тестирование позволяет разработчикам получить обратную связь о том, что сделанные изменения ничего не сломали.

Большинство CI/CD-инструментов позволяет запускать сборку вручную, по коммиту или по расписанию. Командам необходимо обсудить расписание сборки, которое подходит для них в зависимости от численности команды, ожидаемого количества ежедневных коммитов и других критериев. Важно, чтобы коммиты и сборка были быстрыми, иначе долгая сборка может стать препятствием для разработчиков, пытающихся быстро и часто коммитить.

Непрерывное тестирование — это больше, чем автоматизация тестирования

Фреймворки для автоматизированного тестирования помогают QA-инженерам разрабатывать, запускать и автоматизировать различные виды тестов, которые помогают разработчикам отслеживать успешность сборки. Тестирование включает в себя функциональные тесты, разрабатываемые в конце каждого спринта и объединяемые в регрессионные тесты для всего приложения. Регрессионные тесты информируют команду: не сломали ли их изменения что-то в другой части приложения.

Лучшая практика заключается в том, чтобы требовать от разработчиков запускать все или часть регрессионных тестов в своих локальных окружениях. Это гарантирует, что разработчики будут коммитить уже проверенный код.

Регрессионные тесты — это только начало. Тестирование производительности, тестирование API, статический анализ кода, тестирование безопасности — эти и другие виды тестирования тоже можно автоматизировать. Ключевым моментом является возможность запуска этих тестов из командной строки, через веб-хук (webhook) или через веб-сервис и возврат результата выполнения: успешный был тест или нет.

Непрерывное тестирование подразумевает не только автоматизацию, но и интеграцию автоматического тестирования в конвейер CI/CD. Модульные и функциональные тесты могут быть частью CI и выявлять проблемы до или во время запуска CI-конвейера. Тесты, требующие развертывания полного окружения, такие как тестирование производительности и безопасности, часто являются частью CD и выполняются после разворачивания сборок в целевых средах.

CD-конвейер автоматизирует поставку изменений в различные окружения

Непрерывная поставка — это автоматическое развертывание приложения в целевое окружение. Обычно разработчики работают с одним или несколькими окружениями разработки и тестирования, в которых приложение развертывается для тестирования и ревью. Для этого используются такие CI/CD-инструменты как Jenkins, CircleCI, AWS CodeBuild, Azure DevOps, Atlassian Bamboo, Travis CI.

Типичный CD-конвейер состоит из этапов сборки, тестирования и развертывания. Более сложные конвейеры включают в себя следующие этапы:

В более сложном CD-конвейере могут быть дополнительные этапы, такие как синхронизация данных, архивирование информационных ресурсов, установка обновлений и патчей. CI/CD-инструменты обычно поддерживают плагины. Например, у Jenkins есть более 1500 плагинов для интеграции со сторонними платформами, для расширения пользовательского интерфейса, администрирования, управления исходным кодом и сборкой.

При использовании CI/CD-инструмента разработчики должны убедиться, что все параметры сконфигурированы вне приложения через переменные окружения. CI/CD-инструменты позволяют устанавливать значения этих переменных, маскировать пароли и ключи учетных записей, а также настраивать их во время развертывания для конкретного окружения.
Также в CD-инструментах присутствуют дашборды и отчетность. В случае сбоя сборки или поставки они оповещают об этом. При интеграции CD с системой контроля версий и agile-инструментами облегчается поиск изменений кода и пользовательских историй, вошедших в сборку.

Реализация CI/CD-конвейеров с Kubernetes и бессерверными архитектурами

Многие команды, использующие CI/CD-конвейеры в облаках используют контейнеры, такие как Docker, и системы оркестрации, такие как Kubernetes. Контейнеры позволяют стандартизировать упаковку, поставку и упростить масштабирование и уничтожение окружений с непостоянной нагрузкой.

Есть множество вариантов совместного использования контейнеров, инфраструктуры как код и CI/CD-конвейеров. Подробнее изучить это вы можете в статьях Kubernetes with Jenkins и Kubernetes with Azure DevOps.

Архитектура бессерверных вычислений представляет собой еще один способ развертывания и масштабирования приложений. В бессерверном окружении инфраструктурой полностью управляет поставщик облачных услуг, а приложение потребляет ресурсы по мере необходимости в соответствии с его настройками. Например, в AWS бессерверные приложения запускаются через функции AWS Lambda, развертывание которых может быть интегрировано в CI/CD-конвейер Jenkins с помощью плагина.

CI/CD обеспечивает более частое развертывание кода

Итак, подведем итоги. CI упаковывает, тестирует сборки и оповещает разработчиков, если что-то пошло не так. CD автоматически разворачивает приложения и выполняет дополнительные тесты.

CI/CD-конвейеры предназначены для организаций, которым необходимо часто вносить изменения в приложения с надежным процессом поставки. Помимо стандартизации сборки, разработки тестов и автоматизации развертываний мы получаем целостный производственный процесс по развертыванию изменений кода. Внедрение CI/CD позволяет разработчикам сосредоточиться на улучшении приложений и не тратить силы на его развертывание.

CI/CD является одной из DevOps-практик, поскольку направлена на борьбу с противоречиями между разработчиками, которые хотят часто вносить изменения, и эксплуатацией, требующей стабильности. Благодаря автоматизации, разработчики могут вносить изменения чаще, а команды эксплуатации, в свою очередь, получают большую стабильность, поскольку конфигурация окружений стандартизирована и в процессе поставки осуществляется непрерывное тестирование. Также настройка переменных окружения отделена от приложения и присутствуют автоматизированные процедуры отката.

Эффект от внедрения CI/CD-конвейеров можно измерить в виде ключевых показателей эффективности (KPI) DevOps. Такие KPI как частота поставки (deployment frequency), время реализации изменений (change lead time) и среднее время восстановления после инцидента (mean time to recovery) часто улучшаются при внедрении CI/CD с непрерывным тестированием. Однако CI/CD — это лишь один из процессов, который может способствовать этим улучшениям. Есть и другие условия для увеличения частоты поставки.

Для начала работы с CI/CD команде разработчиков и эксплуатации необходимо совместно определиться с технологиями, практиками и приоритетами. Команды должны выработать консенсус в отношении правильных подходов к своему бизнесу и технологиям, чтобы после внедрения CI/CD команда постоянно придерживалась выбранных практик.

Источник