Непрерывная интеграция и развертывание ПО на примере системы BIOCAD
Выступление Колесова Александра, руководителя отдела разработки ПО Biocad, посвящено вопросу непрерывной разработки и интеграции кода. В качестве примера спикер использует систему Botanique – собственную разработку компании Biocad. Описан функционал и цели использования, а также, как именно происходило создание системы.
Кратко о системе Biocad
Система предназначена для мониторинга данных, оборудования и выявления аварийных ситуаций. Пользователи получают оповещения о нештатных происшествиях. Часть процессов автоматизирована для упрощения работы сотрудников компании.
Система состоит из веб-приложения и бота для Telegram. С ее помощью работники могут:
- фиксировать время выполнения работ;
- оповещать о выходе из строя оборудования;
- создавать задачи в таск-менеджере на ремонт техники;
- генерировать отчеты;
- подписываться на действия сотрудников и многое другое.
Это только часть функционала. Подобная система упрощает и ускоряет работу компании. Многие работники сторонней организации заинтересованы в таком продукте.
В этом материале сделали акцент на системе CI/CD. Что это такое? Если упростить, то это конвейер, который работает постоянно. Основная задача – поставка качественного продукта конечному пользователю. Важно, чтобы она была выполнена быстро.
Наглядно систему представляют в виде такого знака бесконечности. Это значит, что завершения нет, и происходящее будет идти по кругу. Только так можно получить рабочий продукт.
Появляется еще один вопрос – стоимость. Тут нельзя ответить однозначно. Зависит от программиста и его уровня навыков.
Как реализуется CI/CD?
Работу просто представить в виде четкого плана:
1. Планирование задач. Нужно понять, что именно важно сделать за определенный промежуток времени. Задачи должны быть четкими и понятно сформулированными.
2. Разработка. Работа над новым кодом в соответствии с поставленными задачами.
3. Сборка кода. Соединение частей в одно целое.
4. Тестирование. Проверка кода на ошибки и фиксация их при выявлении.
5. Релиз программного обеспечения.
6. Деплой. ПО становится доступным для всех пользователей.
7. Мониторинг. Важно отслеживать пользовательский опыт и фиксировать баги.
Немного подробнее рассмотрим каждый этап реализации системы CI/CD.
Планирование
Для планирования задач используем Jiro. Этот планировщик гибкий, с простым интерфейсом. Имеет табличную форму. В каждой строке фиксируется задача, дата начала и окончания работ, статус. Отдельно можно увидеть временную шкалу с разбивкой по месяцам. Такая визуализация упрощает работу и помогает наглядно видеть план.
В Jiro одну большую задачу можно разбить на мелкие. Для нее создается группа, и каждая строка в ней – отдельная цель. Для крупной задачи организуется работа команды. Только совместная деятельность позволяет ставить актуальные цели.
Важно делать задачи для разработчика ограниченными по времени. В среднем на каждую отводится по две недели. Если нужно больше времени, то цель лучше раздробить на несколько.
В Jiro можно смотреть:
- диаграмму Ганта (график с действиями и продолжительностью времени);
- приоритеты;
- загруженность разработчиков.
Это помогает точно понимать, что стоит выполнить в первую очередь на новом спринте.
Разработка
В ходе работы были использованы разные инструменты, и от некоторых в итоге отказались. Команда тоже претерпевала изменения. Не было девопс-инженеров, разработчиков было 2-3 человека. На этом этапе проблем с работой не было. Один программист выкладывал файл с кодом, и он сразу синхронизировался с тем, что есть на компьютерах других участников.
Следующий этап – компилирование рабочей версии при помощи скриптов. Это очень простой способ работы, но он уже дает результат. Можно ли на начальном этапе развернуть полноценную CI/CD? Да, безусловно, можно, но вот итоги будут через год. Вряд ли кто-то захочет ждать так долго.
Сейчас используется «Гитлаб». У нас в департаменте есть группа девопс-инженеров. Один из них прикреплен к нашей команде для оперативного обмена информацией.
Пока разработчиков трое, проблем с общением и планированием не будет. Сложности начнутся при увеличении команды. Так, у нас в бэкенде 10 разработчиков, во фронтеде меньше. Они не должны мешать друг другу, но и на переговоры уйдет больше времени.
Мы выбрали следующую схему работы. Есть первая версия программы, и каждый разработчик берет по одной фиче. Если специалист выполнил свою задачу, то второй учитывает актуальную версию и проверяет наличие конфликтов. Так работа идет до релиза.
Если упростить, то происходит так: пользователь видит актуальную версию, забирает ее и выкладывает уже с учетом своих доработок. Постепенно задачи выполняются, и происходит релиз.
Может произойти так, что конечный потребитель выявит ошибку. В этом случае важно сделать хотфикс, чтобы программа нормально работала. Получается, что между версиями ПО 1.0 и 2.0 команда проводит работу над фичами, устранением ошибок.
Тесты
Автотесты упрощают работу и ускоряют получение результата. В случае ошибки разработчик видит, где возникла проблема. Он уже понимает, как работать над устранением сбоя.
Итог
На любом этапе работы изучаются метрики по серверам. Это позволяет отслеживать нагрузку на технику и выявлять потенциально слабые места. Если увидеть их на этапе мониторинга, то можно избежать глобальных сбоев в работе продукта после релиза.
Проверки делаются в тестовой среде
Готовая схема CI/CD
Для внедрения системы разработали разветвленную поэтапную схему работы. Для удобства восприятия каждая ветка имеет свой цвет:
- синяя – разработчики;
- оранжевая – тестировщики;
- красная – продакшен.
Итак, начинается все с программиста, который выпустил код. Он сразу проверяется SonarQube на безопасность и потом на соответствие стандартам команды. Так код становится единообразным. Далее происходит сборка и доставка информации до дев-среды. На этом этапе проводят разные тестирования, сбор и анализ ошибок, анализ работы системы и т. п.
Если все нормально, то продукт доставляется на проверку в QA-среду. Там специалист тестирует его и при выявлении ошибок отправляет программисту на доработку. Если все нормально, код передается на продакшн.
Такая схема позволяет четко выстраивать все рабочие процессы. Обновление происходит раз в неделю. Для быстрого исправления ошибок код передается в небольшом количестве. В итоге пользователь получает стабильную работу программы с регулярными обновлениями.
Вопросы и ответы
1. В каком продукте делается регрессионное тестирование?
В схеме выделена зона Selenium. Именно в ней происходит тестирование на обнаружение ошибок в уже проверенных участках кода. Используем ручные и автоматические методы. За счет такого подхода добились стабильной работы системы.
2. Исходя из представленной схемы, на слайде среди инструментов поддержки можно выделить зарубежные коммерческие продукты. Есть идеи, на что переходить в случае проблем?
Да, мы изучали этот вопрос и разрабатывали план перехода. У нас много опенсорса – программ с открытым исходным кодом. Вряд ли их можно полностью как-то запретить или ограничить. Есть некоторые платные продукты, и с ними действительно возникают сложности из-за затруднений с оплатой. В этом вопросе ищем замены и планируем переход. В целом есть смысл переключиться на опенсорс.
3. Чем будете заменять Jira? Изучали отечественные продукты?
Пока ничем, лицензия есть и работает, ограничений нет. В будущем еще посмотрим. Мы систему CI/CD делаем не только для собственных нужд. Она используется во всех структурных подразделениях компании. Например, раньше мы применяли артефакторы, теперь постепенно переходим на Nexus – это инструмент для систематизации и управления артефактами.
4. Как в системе CI/CD работает система разработки? Она облачная или On-Premises?
У нас есть собственная система СОД, и мы не используем ни внутреннее облако, ни внешнее. Только собственные мощности.
