При выборе любой корпоративной информационной системы организации необходимо понимать, как она будет с ней работать. Насколько хорошо система поддаётся модификациям? Смогут ли её настраивать и дорабатывать собственные программисты и администраторы компании? Не только сейчас, но и спустя годы. Слишком дорого может обойтись миграция на платформу, которая устареет через несколько лет или перестанет удовлетворять бизнес-процессы компании. Для того чтобы модифицировать систему под нужды компании, пользователям SimpleOne доступны инструменты No, Low и Pro Code. Настройки, скрипты, конфигурации — в SimpleOne всё это могут использовать специалисты на стороне компании-потребителя.
Но как вносить эти изменения? Как переносить их из среды разработки на производственный экземпляр? Как не навредить уже работающим элементам системы при переносе таких доработок?
Для этого в SimpleOne используются отдельные разделённые среды разработки и тестирования, а доработки между ними переносятся с помощью инструмента Configuration Pack. Конфигурационный пакет автоматизирует перенос доработок между экземплярами системы, делает этот процесс быстрым, безопасным и легко обратимым.
Цикл разработки и выделенные среды (инстансы, или экземпляры системы)
Окружение — это среда, которая создаётся для воспроизведения экземпляра программного продукта. Включает саму копию ПО, а также необходимые базы данных и другие элементы, которые нужны, чтобы продукт функционировал в полной мере.
Для внесения обновлений в систему SimpleOne используется от трёх до пяти окружений, в зависимости от объёма и серьёзности изменений. Каждая доработка может проходить через следующие среды.
- Среда разработки (dev)
Непосредственно разработка изменений, внесение настроек, добавление скриптов, написание кода. На этой стадии в окружении разработчик получает продукт. Код поступает сюда постоянно, происходят изменения, доработки, устраняются ошибки.
- Среда тестирования (test)
Это копия продакшен-сервера. Здесь доработки проходят множество ревью и проверок. На этой стадии тщательно просматривается доработанная функциональность. Отдельные функции, их взаимодействие, как нововведение, отражаются на остальных элементах ПО.
- Стеджинг (staging)
При необходимости проводится дополнительное тестирование на стеджинге, где уже проверенный и перепроверенный код проходит ещё одно испытание. Причёсанный продукт, который выглядит как его конечная версия, используется и тестируется заказчиком, руководством.
- Cреда пользовательского приёмочного тестирования (User Acceptance Testing, UAT)
На этой стадии можно проводить пользовательские исследования. Если члены команды разработки знают технические детали в подробностях, то сторонний человек смотрит на продукт как конечный пользователь. Насколько удобно, просто и быстро ищутся и выполняются функции, может сказать только реальный конечный пользователь, который смотрит на продукт извне. К тому же невозможно предугадать все сценарии взаимодействия пользователя с продуктом.
- Продуктивная среда (prod)
Последняя стадия. Сюда заливается конечный продукт, чтобы использоваться реальным конечным пользователем, в реальных ситуациях, с настоящими данными.
Пройдя эти стадии, ПО не заканчивает свой жизненный цикл. Происходят доработки, устранение каких-то ошибок, появляются новые версии, собирается обратная связь от пользователей. Это этап поддержки, который может длиться неопределённо долго.
Такова основа разработки/доработки той или иной функциональности на enterprise-платформах масштаба SimpleOne. Есть и различного рода вариации, когда появляются «песочницы», несколько сред тестирования или между средами тестирования и продуктивной средой возникает несколько предпродуктивных сред — всё зависит от степени чувствительности бизнеса к ошибкам в системе.
Выше мы отметили, что доработки могут делаться не только с помощью написания кода. В таких системах, как SimpleOne ITSM, большинство доработок реализуется на стороне компании-потребителя без программирования средствами визуальных инструментов.
Здесь возникает вопрос: как изменение, созданное пользователем с помощью инструментов визуальной разработки или Low Code, попадает из среды разработки в следующие среды (тестовую, промышленную)?
Процесс переноса всех типов доработок в SimpleOne автоматизируется c помощью конфигурационного пакета обновлений.
Автоматизация переноса доработок между средами
Все изменения и настройки системы, которые делают администраторы и разработчики, помещаются в конфигурационные пакеты. Такой пакет можно экспортировать, а затем импортировать в другой экземпляр системы, в другое окружение, при этом мы по факту повторим все те же самые действия, которые сделали при разработке, те настройки, которые привели к нужному результату.
Во время импорта пакета в тестовую среду автоматически проводится анализ, все ли изменения могут быть применены в этом целевом экземпляре (процедура превью). После процедуры разработчик на выходе получает набор сообщений, в котором можно увидеть, нет ли коллизий или ошибок при применении новых настроек системы. После превью и устранения всех коллизий можно применять наработки в тестовом экземпляре и начать тестирование новых доработок.
Автоматический откат изменений
Конфигурационные пакеты нужны не только для автоматизации и ускорения доставки изменений, но и для возможности откатить проделанные изменения. То есть, если даже, невзирая на все тесты и процедуры предпродсерверов, на финальную продуктивную среду попадёт доработка с ошибкой и что-то сломается, есть возможность сразу же безболезненно откатить этот local pack изменений. И закинуть его вновь на тестовые серверы воспроизводить эту проблему и решать её в безопасном окружении.
Таким образом, с помощью автоматизации процедуры отката изменения максимально снижается риск привести промышленный экземпляр в нерабочее состояние по результатам обновления.
«В подавляющем большинстве случаев мы можем абсолютно безболезненно откатиться, это достаточно редко для систем такого масштаба. Мало какие enterprise-платформы могут себе это позволить, как правило, после переноса изменений в prod с ними ещё долго приходится работать прямо в продуктивной среде, чтобы привести её в рабочее состояние, либо восстанавливаться из бэкапа, если не удаётся настроить систему в отведённое время».
Илья Радченко, Product Owner SimpleOne
Слияние доработок (merge)
Ещё один плюс конфигурационных пакетов — они так или иначе позволяют вести командную разработку. В них собираются изменения не одного, а нескольких разработчиков (с помощью процедуры merge). Благодаря этой функциональности несколько разработчиков могут параллельно, не мешая друг другу, вести доработку и собирать все сделанные изменения, а затем собрать их в один пакет, развернуть его в тестовой среде и проверить, что они стабильно работают вместе перед переносом в продуктив.
Тиражирование доработок
Механизм конфигурационных пакетов изменений важен не только для разработчиков, кастомизирующих систему SimpleOne для своих компаний. Он поддерживает одну из главных функций платформы — создание на её базе новых продуктов. Специалисты организаций, подключённых к платформе SimpleOne, имеют возможность с помощью инструментов No, Low и Pro Code разрабатывать новые приложения на её основе, интегрировать платформу со сторонними продуктами. И в том числе переносить свои наработки на другие серверы, тиражировать их для новых пользователей нажатием нескольких кнопок. Всё за пару минут или максимум часов (в случае проведения предварительных тестов).
Как пример — в рамках платформы можно интегрироваться с Telegram и другими мессенджерами, а единожды настроив эту функциональность, переносить между серверами. То есть всё, что позволяет реализовать платформа, всё, что хоть как-то отвечает за бизнес-логику, переносится через конфигурационные пакеты обновлений.
Важно отметить, что в конфигурационные пакеты попадают все нужные вложения. В пакет сохраняется не только бизнес-логика, но и нужный контент для бизнес-логики — файлы, картинки. Также переносятся скрипты и демоданные. То есть можно настраивать прямое взаимодействие между экземплярами, когда экземпляр № 1 берёт конфигурационный пакет из экземпляра № 2 полностью автоматически, по кнопке в интерфейсе.
Почему всё это важно для пользователей корпоративных систем?
Потому что необходимо обеспечивать непрерывность бизнеса. Если у нас всего одна среда и мы хотим в ней что-то изменить, у нас нет права на ошибку. Но так не бывает, люди ошибаются часто, разработчики — ещё чаще. Из-за ошибок в enterprise-системе может остановиться любой бизнес-процесс, а то и не один. Бизнес-процесс простаивает — компания несёт издержки. Когда же мы добавляем несколько сред, стеджинг, UAT, мы минимизируем риск такого рода издержек. А это самое важное для корпоративного сегмента.
При этом система не замирает во времени. Любые созданные на ней функции, настройки и доработки пакет обновлений позволяет объединять между собой, изменять, наращивать или откатывать назад. Причём делать это довольно быстро с точки зрения скорости обновления серверов. У разработчика есть возможность собрать всё на dev-сервере, и в течение часа всё будет в production. И это с прохождением всех проверок. Поэтому ещё одна большая ценность — скорость переноса данных, причём их очень большого количества. Например, на SimpleOne недавно вышло большое обновление к ITSM-продукту на платформе, которое содержит в себе около 5000 записей (отдельных изменений). Его перенос в продуктивную среду занял 7 минут.
Подробнее нюансы применения конфигурационных пакетов в ITSM-системе SimpleOne можно рассмотреть в обучающем видео.
