Дипломная работа: Автоматизация доставки программного обеспечения при помощи DevOps практик и инструментов в облаке AWS в компании ООО "Команда Лабс"

Скачать файл

Заказать новую работу

Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам

Рисунок 14. Схема бизнес-процессов разработки

1.2.2 Определение места проектируемой задачи в комплексе задач и ее

описание

Во многих IT-компаниях есть конфликт между отделом разработки и

эксплуатации, который заключается в том, что девелоперам необходимо

доставлять код тактически, тогда как эксплуатация работает, скорее

стратегически, она заинтересована в том, чтобы в рабочем окружении было

минимальное количество ошибок, а постоянные изменения в производственном

окружении могут накапливать проблемы и могут возникать пожары, которые

необходимо постоянно тушить. Соответственно, с обеих сторон растёт

технический долг — термин, предложенный Уордом Каннингемом.

Технический долг — решения, необходимые для ликвидации проблем, с

течением времени становящихся все более трудно разрешимыми при

постоянном уменьшении будущих возможностей для маневра.

Дело в том, что приходится пытаться одновременно достигать сразу двух

целей:

1. Реагировать на быстро меняющийся конкурентный ландшафт, который

связан с постоянно меняющимися требованиями бизнеса.

2. Необходимо производить стабильный, надёжный и, что самое сложное,

безопасный сервис для клиентов.

В нашем случае разработчики берут на себя реагирование на изменения

на рынке и потребности клиентов в короткие сроки. Они работают по спринтам,

которые длятся 2 недели для исправления ошибок и добавления нового

функционала. От них также ожидается, что критические ошибки будут

исправляться немедленно. Эксплуатация при этом заинтересована в том, чтобы

обеспечить предоставление заказчикам стабильной инфраструктуры (пункт 2).

Получается, разработчики и эксплуатация преследуют разные цели.

Элияху Голдратт, который создал методологию управления

производством под названием «Теория ограничений», назвал эту ситуацию

корневым хроническим конфликтом. Этот конфликт провоцирует

возникновение нисходящей спирали, которая приводит к созданию

некачественного ПО, а также к поиску большого количества обходных путей для

решения проблем, что также приводит к росту Технического долга и разнице в

производственной и тестовых средах.

Итак, в отделе эксплуатации цель — сохранение работоспособности

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

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

работоспособного состояния, зачастую очень сложные, их сложно

документировать, и они весьма хрупкие. И именно такие хрупкие системы

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

наносит удар финансам, безопасности данных пользователей, точности отчётов

и т.д. И правки, которые вносятся в инфраструктуру, когда необходимо срочно

что-то починить руками, затем очень сложно воспроизводимы.

Затем необходимо компенсировать невыполненные обязательства, и

всегда появляются новые обещания со стороны руководства по созданию нового

функционала, который зачастую несовместим с хрупкой системой. Поэтому

технический долг неуклонно растёт.

При обилии ручной работы для деплоймента программного обеспечения

это может занимать невероятно длинное количество времени, поэтому доставку

ПО необходимо автоматизировать. И, в связи с вышеописанным, необходимо

сделать так, чтобы результат развёрнутой инфраструктуры всегда был

идемпотентным, а также сделать так, чтобы девелоперская, тестовая и

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

похожие результаты при одинаковых условиях.

1.2.3 Обоснование необходимости использования вычислительной

техники для решения задачи

Основной скоуп задач, связан с тем, чтобы уменьшить Время Выхода на

рынок продукта (Time to Market) и внедрение DevOps практик и инструментов

[11] для улучшения коллаборации, передачи информации между людьми и

машинами и автоматизации работ по деплойменту и тестирования приложений.

Для того, чтобы тестирование было максимально эффективным,

необходимо, чтобы тестовая и производственной среды были максимально

приближены друг к другу по составу и характеристикам. Для этого необходимо

использовать подход Инфраструктура как Код (Infrastructure as Code) [3], чтобы

избежать разницы между средами. Изначально регрессивное тестирование

проводилось вручную и занимало продолжительное количество времени,

поэтому запуск тестов сделали по расписанию в автоматическом режиме, это

позволило уменьшить время с 2 недель до часа. Также все этапы деплоймента

были полностью автоматизированы, что позволило значительно ускорить

доставку ПО, избежать ручных операций, и, как следствие, человеческих

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

сократилось, и клиенты могут видеть новый функционал каждые две недели – в

соответствии со временем одного спринта в рамках подхода гибкой разработки

Agile

Рисунок 15. Схема итеративной разработки в рамках Agile подхода

Чем короче цикл поставки программного обеспечения конечному

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

исправлять ошибки в производственном окружении. Также такой подход

позволяет непрерывно тестировать, собирать телеметрию и другие метрики для

более глубокого понимания состояния системы, её анализа, анализа реакции

рынка и влияния продукта на рынок и наоборот влияния рынка на продукт во

времени. Также очень важно понимать состояние самой системы на каждом

этапе её разработки: на этапе разработки, во время тестирования и в

производственной среде. Это один из важных факторов внедрения DevOps

практик.

Рисунок 16. Второй путь DevOps – непрерывная обратная связь

Кроме того, во многих IT-компаниях есть конфликт между отделом

разработки и эксплуатации, который заключается в том, что девелоперам

необходимо доставлять код тактически, тогда как эксплуатация работает, скорее