Методология DevOps: отличия от классического подхода к разработке

18.02.2021

Александр Казённов, руководитель корпоративной практики ДКИС ALP Group

Александр Казённов, руководитель корпоративной практики ДКИС ALP Group:

Мне часто задают один и тот же вопрос: «Что такое методология DevOps? В чем ее ключевые отличия от классического подхода к разработке?»

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

Благодаря этой методологии, разработчик гораздо быстрее получает обратную связь от заказчика, быстрее реагирует на неё и, соответственно, выпускает изменения. Верх совершенства – это доставка изменения по требованию заказчика в момент её реализации в среде разработки без рисков для бизнес-процессов заказчика. Достигается это за счёт создания «сборочной линии»: заказчик формирует потребность, разработчик её исполняет в среде программирования, автоматически проходят тестирования в средах разработки, среде тестирования и, в случае успеха, обновления устанавливаются в продуктив. На каждом из участков такой сборочной линии работают инструменты-доставщики изменений и автоматизированные тесты. При этом речь здесь не только о сценарных тестах, но и о технических проверках (таких, как качество и оптимальность кода, работоспособность форм и обменов, информационная безопасность подключений и используемых процедур). Такой подход очень хорошо сочетается с Agile-технологиями управления изменениями, но не ограничивается ими.

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

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

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

Во-первых, автоматизированный контроль качества, безопасности и оптимальности кода помогает свести на «нет» ошибки и опечатки в логических процедурах и переменных, организации только защищенных подключений и т. п., что вручную делать достаточно тяжело. Во-вторых, сокращаются сроки реализации изменений, сборки релизов, их доставки до контуров, проверки технических гипотез на жизнеспособность. Далее, упрощается контроль за качеством, сроками и результатами работ команд разработки. Наконец, упрощается коммуникация с бизнесом, появляется возможность проактивного решения потенциальных проблем в продуктиве – часть из них можно выявить и решить еще до того, как о них станет известно бизнесу.

Основные шаги, по которым происходит разработка по методологии DevOps (описание схемы для корпоративного сектора):

1. Получение задачи от бизнеса, попытка автоматически разложить её на блоки и потенциально затрагиваемые участки системы.

2. Поиск и анализ связанных задач из других обращений для формирования более комплексного решения.

3. Описание способа решения задачи для разработчика.

4. Выполнение разработки, помещение изменения в хранилище.

5. Автоматический контроль качества помещённого кода, технические проверки, проверка инструментами информационной безопасности (иногда этот этап выполняется только перед установкой в тестовый или продуктивный контур заказчика). Если есть проблемы – возврат разработчику на исправление.

6. Автоматическое обновление тестовой базы аналитиков команды разработки, автоматическое проведение полного комплекса «дымовых» и сценарных тестов. Если есть проблемы – возврат на исправление разработчику. Если всё в порядке – ручное тестирование аналитиком (при необходимости; зависит от задачи и определяется на этапе описания способа решения задачи).

7. Автоматическая выгрузка версии релиза и установка её в тестовый контур заказчика, автоматическое проведение полного комплекса дымовых и сценарных тестов. Если есть проблемы – возврат на исправление разработчику и возврат к предыдущей принятой версии релиза. Если всё в порядке – ручное тестирование назначенными бизнес-пользователями и/или специалистами первой линии поддержки. В случае замечаний – возврат разработчику, в случае отсутствия замечаний – планирование установки в продуктив (иногда в силу непрерывности процессов бизнеса нельзя устанавливать обновления по мере их готовности).

8. Установка обновления в продуктив.

Какие инструменты нужны на каждом шаге разработки?

Для коммуникации разработчиков с заказчиками и службой поддержки используются различные трекинг-системы. В нашей компании преимущественно применяется собственная разработка – SMS. Иногда, по требованию заказчика, на проектах используются сторонние системы, такие как Jira. Разработка на 1С осуществляется в хранилищах 1С или в Git-хранилищах, в зависимости от ситуации и требований информационной безопасности заказчика. Чаще всего для технического контроля изменений, помещаемых в хранилище, применяется Sonar Cube. Jenkins – это уже практически стандарт по автоматической доставке изменений между контурами и старта служебных задач. Для запуска различного рода тестов, как правило, задействуется Vanessa ADD и Тест-центр 1С. Для контейнеризации сред очень часто используется Docker в связке с Kubernetes.

Тема:О том, о сём