Существует несколько шагов между приложениями и веб-сайтами, которые создаются и наконец выпускаются — дизайн, программирование, контроль качества и развертывание. Давайте сократим разрыв между циклом разработки и эксплуатации и рассмотрим некоторые практики движения DevOps.
Разработка обычного программного обеспечения: Dev vs Ops
Традиционно, существуют различные команды и процессы для разных состояний проекта, от начальных состояний анализа и проектирования (когда задумывается продукт или идея), до фактической разработки и тестирования (например, когда пишется код или продукт разрабатывается), чтобы окончательно развернуть и поддержать (например, когда веб-сайт, приложение или продукт будут запущены).
Есть веская причина для такого различия: все они требуют разного набора навыков. Однако строгое (а порой даже бюрократическое) разделение обязанностей может привести к большому количеству ненужных задержек, и опыт показывает, что размытие некоторых из этих линий может быть выгодным для всех участвующих сторон и для процесса в целом.
Это верно не только для разработки программного обеспечения, но и для многих отраслей. Подумайте, например, о Toyota, японском автопроизводителе, который на протяжении многих лет твердо стремился сократить то, что они называют «отходами» производственной цепочки, чтобы они могли ускорить процесс перехода от разработки к производству. Более того, практика Toyota в действительности сильно повлияла на ИТ-индустрию как в разработке программного обеспечения (см. « Бережливая разработка программного обеспечения »), так и в DevOps (см. « Канбан: от Toyota к DevOps? » И « Использование производственной системы Toyota для объяснения DevOps»). «).
DevOps: культурные перемены для победы
DevOps как пересечение разработки, эксплуатации и обеспечения качества. Изображение из Викимедиа , через Гари Стивенса из HostingCanada.org .
Как и в случае с гибкой разработкой , DevOps — это не конкретный инструмент или метод, который вы можете реализовать, и все готово. Скорее, это культура — даже образ мышления — который может принять ваша команда и организация, и это сделает процессы более плавными.
Но что именно? Представьте себе, что разработчики могут выполнять некоторые задачи, которые обычно назначаются системным администраторам, например создавать новые серверы, обновлять производственные сайты, развертывать приложения. Также подумайте о том, чтобы системные администраторы разделяли некоторые обязанности с разработчиками и могли одновременно управлять несколькими серверами.
Преимущества
Компании, использующие культуру DevOps, сообщают о значительных улучшениях, и различные опросы, проведенные среди некоторых из них, как представляется, подтверждают эти утверждения (см. « Непрерывная поставка: огромные преимущества, но слишком сложные »).
Некоторые из этих улучшений включают в себя:
- Ускоренное время выхода на рынок : сократите время, затрачиваемое с момента создания идеи до ее продажи или производства.
- Создание правильного продукта : разработчики получают более быструю обратную связь от пользователей с более частыми выпусками и живым тестированием идей (подробнее об этом позже в разделе «A / B-тестирование»).
- Снижение затрат : в среднем на 20%.
- Повышение производительности : благодаря непрерывной доставке разработчики и тестировщики экономят время на настройку и исправление своей рабочей среды. Кроме того, развертывания значительно быстрее (подробнее об этом позже в разделе «Непрерывная интеграция с Jenkins»).
- Надежные выпуски : с меньшими и более частыми выпусками изменения в коде — и поэтому внесенные ошибки и их влияние — также меньше.
- Улучшение качества продукции : компании сообщают об очень значительном снижении количества открытых ошибок и других проблем (в некоторых случаях более чем на 90%).
- Повышение удовлетворенности клиентов : неудивительно, что это побочный продукт всех предыдущих улучшений.
Примеры
Та же среда производства и разработки с Docker
Общепринятое мнение гласит, что не следует смешивать производство со средами разработки — что эти два следует тщательно разделять, чтобы избежать катастроф. И хотя правда, что внесение изменений в работающую платформу без механизмов тестирования и отката является формулой аварийной ситуации, наличие нескольких сред сопряжено с высокими эксплуатационными затратами.
Автоматизация создания сред является ключевым моментом в DevOps, и одной из технологий, которая позволяет это, является Docker . Здесь мы не будем вдаваться в подробности, но принцип в том, что с помощью Docker вы можете создать хорошо протестированную и функциональную среду (называемую образом ), которую разработчики и инженеры в области эксплуатации смогут запускать как программное обеспечение. контейнеры . Всякий раз, когда требуется обновление или исправление, команда QA просто исправит образ, и изменения будут реплицированы в каждом новом запущенном контейнере.
Это дает программистам и дизайнерам независимость при запуске сред, которые постоянно обновляются и работают как известно (и столько, сколько им нужно), и даже вносят изменения в живые платформы, потому что специалисты по обеспечению качества поддерживают эти среды и уже установили соответствующие тесты. Он также обеспечивает канал связи с администраторами серверов, потому что все они в основном работают вместе, имея рабочую среду, подходящую как для производства, так и для разработки.
Обратите внимание, что это также справедливо, если разработка и развертывание выполняются одними и теми же людьми — как и одним разработчиком-фрилансером — потому что эти проблемы при тестировании и реализации живого приложения в различных средах по-прежнему актуальны независимо от того, кто отвечает за это.
Для получения дополнительной информации о том, что вы можете сделать с помощью Docker, см. Общие сведения о Docker, Контейнеры и Безопасная доставка программного обеспечения .
A / B Тестирование
Википедия описывает A / B-тестирование следующим образом:
В маркетинге и бизнес-аналитике A / B-тестирование — это термин для рандомизированного эксперимента с двумя вариантами, A и B, которые являются контролем и изменением в контролируемом эксперименте.
Принцип заключается в том, что вы можете тестировать варианты идеи в реальных условиях, чтобы улучшить удобство использования и другие области, основываясь на популярности или отзывах пользователей. Безрассудным моментом является то, что вы проводите эти тесты со своей реальной аудиторией — кто в любом случае лучше всего подходит для обратной связи — что, к примеру, Facebook, в частности, делает в больших масштабах для проведения социальных экспериментов. В области веб-разработки подумайте об экспериментах по тестированию целевых страниц с помощью Google Analytics .
Как все это связано с DevOps? Что ж, с помощью автоматизированных процессов развертывания вы предоставляете вовлеченным сторонам — будь то дизайнеры, разработчики или даже ученые, не имеющие никакого опыта в программировании или проектировании, — автономность, в которой они нуждаются для проведения экспериментов, — опять же, с защитными механизмами для тестирования, изменения вытягивания или отката.
Непрерывная интеграция с Jenkins
Логотип Дженкинс ( Викимедиа )
Jenkins — это программное обеспечение для непрерывной интеграции (CI) и непрерывной доставки (CD) — система оркестровки с сотнями плагинов для автоматизации всего, от создания приложения и его тестирования до окончательного развертывания. Эти плагины могут интегрировать программное обеспечение для сборки из платформ исходного кода, таких как Git или Mercurial, в облачные сервисы, такие как Amazon Web Services (AWS) или Google Cloud Platform (GCP), проходя все запланированные тесты. По сути, это конвейер от источника к доставке, который становится двигателем DevOps .
Опять же, мы видим, как все участники (разработчики, QA и системные администраторы) работают вместе над эффективным и автоматизированным рабочим процессом:
- Нужна ли разработчикам новая рабочая среда ? Дженкинс запустит Докер, чтобы запустить его.
- Нужны ли системным администраторам новый тест QA для прохождения обновления до его запуска ? Они просто добавляют его в трубопровод Дженкинса.
- Хотите ли разработчики вносить изменения в рабочий сайт и запускать на нем новые серверы ? Нет проблем: системные администраторы уже проинструктировали Дженкинса, какие тесты нужно запустить, и, если все пойдет хорошо, как запустить серверы.
Как вы можете видеть, в этом процессе много автоматизации и достаточно доверия между сторонами — все это требует большой работы по настройке, но которое, будучи на месте, также дает всем много места действовать самостоятельно.
Проблемы и неудачи
Переход на культуру DevOps может принести ряд преимуществ, но он также сопряжен с определенными проблемами, которые необходимо преодолеть.
Первый на уровне организации . По мере того как ограничения на разработку и развертывание устраняются, а программисты и системные администраторы получают большую независимость, вовлеченные люди должны будут принять другое мышление, и необходимо будет установить соответствующие механизмы для цикла обратной связи от ops до dev — такие как средства отслеживания проблем. доски обсуждений (подумайте о Slack ) и тому подобное.
Вторая ключевая проблема касается процессов . Вы больше не хотите, чтобы разработчики и сами администраторы сервера использовали свое время для индивидуального тестирования после изменений. Вам нужно автоматизировать процессы тестирования, чтобы позволить различным командам вносить изменения и быстро проверять, все ли еще на месте, и отменять эти изменения в случае возникновения проблем.
Наконец, есть технологическая проблема. Как уже упоминалось, после того, как ваша организация тщательно проверила процессы от начала до конца, вам может потребоваться либо принять, либо создать технологию, которая бы соответствовала виду цикла автоматизации и обратной связи, который лучше подходит вашим процессам и организации.
Это не тривиально: вы не можете просто скопировать / вставить процессы и технологии, которые используют другие. Эти вопросы необходимо решать индивидуально, и между вовлеченными сторонами должен быть справедливый уровень доверия.
Как комментирует Дейв Робертс в статье « Почему корпоративные разработки не имеют смысла »:
Главное — понять, что просто развертывать инструмент или даже широкое решение, не продумывая вашу уникальную ситуацию, текущее состояние потока создания ценности и его текущие ограничения, глупо.
резюмировать
Это не о приложениях . Вы можете использовать такие инструменты, как Docker, Jenkins, Kanban и, тем не менее, никогда не делать никаких реальных DevOps, если не можете положиться на людей с другой стороны вашей цепочки.
Напротив, вы можете обойтись без этих инструментов и вместо этого реализовать свои собственные решения и установить цепочку обеспечения качества, которая подходит вам или вашей организации. И если вы свободно общаетесь с коллегами из разных команд и даже временно выполняете некоторые из их задач самостоятельно, когда вам необходимо — полагая, что они могут сделать то же самое, потому что у вас уже есть все необходимое для отмены изменений — тогда Вы делаете культурный сдвиг, который очень похож на DevOps.
Выгоды впереди вполне могут стоить усилий.