Немного ранее между разработчиками и поддержкой был барьер. Как бы там ни было, но были у них разные цели и KPI, хотя занимались они общим делом. Целью разработки была скорейшая реализация бизнес-требований, а также их добавление в работающий продукт. Поддержка в свою очередь отвечала за то, чтобы приложение отличались стабильной работой. И, как мы понимаем, любые изменения, вносимые в уже работающий продукт, несли опасность именно стабильности работы. Именно из-за конфликтов интересов двух стон и возник DevOps для их решения.
Содержание
DevOps объединяет в себе технологии, процессы и культуру взаимодействия внутри команды. Это объединение нацелено на непрерывную доставку ценностей конечным пользователям.
ДевОпс представляет собой единый алгоритм работы, который объединяет в себе разных специалистов: разработчики пишут код, тестировщики его проверяют, а администраторы устанавливают финальный продукт на производственное окружение.
Стоит понимать, что ответственность за итоговый результат продукта лежит на каждом из участников команды. В культуре и деятельности DevOps самое сложное – это понять, что каждый человек не просто отвечает за часть своей работы, но и несет ответственность за то, как в итоге будет работать приложение. Проблема лежит не на чьей-то стороне – она общая, и каждый член команды помогает ее решить.
DevOps-практики покрывают все этапы жизненного цикла ПО.
Начинать использовать DevOps-практики необходимо еще на моменте инициации проекта. Совместно с архитекторами надо планировать, какой у приложения будет архитектурный ландшафт, где оно будет располагаться и как масштабироваться, надо выбрать платформу.
Далее необходимо перейти, собственно, на этап разработки. Здесь одна из крупных практик – построение CI/CD: нужно помочь разработчикам интегрировать изменения в продукт быстро. CI/CD покрывает и проверку кода, и заливку мастера в кодовую базу, и разворачивание приложения на тестовых и продуктивных средах. На данном этапе код проходит через quality gates. Здесь добавляется юнит- и UI-тестирование.
DevOps-практикам также есть место на стадии поддержки уже готового продукта. Данные практики применяются для мониторинга, безопасности, обратной связи, внедрения изменений. На все эти задачи DevOps смотрит с точки зрения постоянных улучшений.
Практики полезны для автоматизации, ускорения релиза, быстрой обратной связи от пользователей.
Обычно разработчики вручную обновляли свой код, а затем вручную же его тестировали.
При непрерывной интеграции разработчики часто заливают изменения кода в центральный репозиторий. После внесения изменений происходит автоматическая сборка и для неё запускаются автоматизированные тесты.
Эта практика помогает быстрее выявлять ошибки и повышает качество ПО.
Это продолжение непрерывной интеграции. После сборки все изменения кода автоматически развёртываются в тестовой среде. После этого развёрнутый код прогоняют через автоматические тесты, и запускается развёртывание в производственной среде. И только неудачный тест может предотвратить запуск обновления сборки. Так разработчики могут быстрее обнаруживать и исправлять ошибки.
Все эти задачи помогают выполнять Jenkins, Bamboo, Travis, TeamCity и другие CI- и CD-утилиты.
Практика непрерывного тестирования помогает как можно раньше выявлять возможные риски на всех стадиях разработки ПО, чтобы ошибки не повлияли на конечных пользователей.
Таким образом, код будет развёрнут в среде контроля качества (QA environment) для функционального тестирования, только если успешно пройдёт все модульные тесты.
Предполагается, что приложение, инфраструктура, промежуточное ПО и сети постоянно мониторятся на предмет производительности, ошибок, безопасности и соответствия требованиям.
Большинство компаний следят за такими показателями:
Применяя непрерывный мониторинг, вы всегда будете в курсе любых проблем на контурах: от тестирования до продакшена. Это поможет вам обеспечить высокую доступность продукта.
Популярные инструменты непрерывного мониторинга: Nagios, Sensu, Prometheus.
Инфраструктура как код (Infrastructure as Code, IaC) — это модель, при которой инфраструктура — виртуальные машины, балансировщики нагрузки, сети — настраивается и управляется программно, а не вручную. Такая инфраструктура стала необходимым компонентом DevOps в организациях, которые специально перешли на облачные платформы.
Например, Amazon Web Services (AWS) предоставляет API для программного взаимодействия со своей облачной инфраструктурой. Использование программного кода для определения конфигурации помогает сделать процесс стандартным и быстро развёртывать ресурсы в облаке.
В отличие от традиционного монолита, приложение в микросервисной архитектуре состоит из множества маленьких сервисов или компонентов. Каждый сервис отвечает за свою функциональность, а взаимодействуют они через легковесный интерфейс или API.
Микросервисная архитектура — распространённое решение в DevOps-культуре. Она:
DevOps-инженеры соединяют в одно целое все части, из которых состоит проект. Они ознакомлены со спецификой работы программистов, тестировщиков, системных администраторов. ДевОпс инженеры помогают упростить работу, так как понимают потребности и требования бизнеса, его роль в процессе разработки, а, значит, и строят процесс с учетом всех интересов заказчика.
Стоит отметить, что у DevOps-инженера должны быть фундаментальные знания из разных областей: программирование, работа с операционными системами, базами данных, системами сборки и конфигураций. К ним добавляется умение работать с облачной инфраструктурой, системами оркестрации, мониторинга.
DevOps-инженеры знают несколько базовых языков для автоматизации. Исходя из этого, они могут давать некоторые рекомендации программистам при написании кода.
DevOps-инженер может выучить один или несколько из этих языков: Python, Groovy, Bash, Powershell, Ruby, Go. Знать их на глубинном уровне не требуется – достаточно основ синтаксиса, принципов ООП, умения писать несложные скрипты для автоматизации.
DevOps-инженер должен понимать, на каком сервере будет установлен продукт, в какой среде будет запускаться, с какими сервисами будет взаимодействовать. Можно выбрать специализацию на Windows или Linux-семействе.
Без знаний системы контроля версий DevOps-инженеру никуда. Git – одна из самых популярных систем в настоящий момент.
Системы оркестрации: Docker и Kubernetes. Виртуальные сервера разделены на контейнеры, в каждом из которых можно установить приложении. Когда контейнеров становится много, ими нужно уметь управлять и делать это вовремя: один включить, другой выключить, где-то сделать бэкап. Это может быть сложной процедурой для реализации, поэтому и нужна система оркестрации.
Когда есть необходимость в обслуживании целого парка серверов, приходится делать много однотипных действий. Это не просто долго, но это также и сложно, плюс из-за ручного труда высок риск опущения ошибки. Здесь на смену и приходит система конфигурации — Chef, Ansible, Puppet.
При их помощи создаются скрипты, которые удобно читать как программистам, так и DevOps-инженерами, и системными администраторами. Этот скрипт помогает проводить одинаковые операции на серверах автоматически.
Оставьте заявку и наш менеджер свяжется с Вами в течение 15 минут
evm_service
+7 (499) 380-82-90
sales@evmservice.ru
г. Москва, м. Окружная,Локомотивный