Agile DevOps ― гибкая разработка и эксплуатация ПО: Разрушение барьеров

Почему объединенные группы крайне важны для успешных проектов DevOps

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

Пол Дюваль, технический директор, Stelligent Incorporated

Paul DuvallПол Дюваль (Paul Duvall) является техническим директором компании Stelligent Incorporated – консалтинговой фирмы, которая помогает командам разработчиков оптимизировать гибкие методологии разработки программного обеспечения. Он также соавтор книги Continuous Integration: Improving Software Quality and Reducing Risk (Addison-Wesley, 2007 г.). Он принимал участие в создании книг UML 2 Toolkit (Wiley, 2003 г.) и No Fluff Just Stuff Anthology (Pragmatic Programmers, 2007 г.).



19.03.2013

Об этом цикле статей

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

В компаниях, которые создают программные продукты и системы, меня часто спрашивают: «Как нам изменить свою организацию, фактически не меняя ее?» Конечно, они используют не эти слова (по крайней мере, не всегда), но смысл именно такой. Они хотят свести к минимуму усилия и риск, связанные с выпуском программного обеспечения, но понимают, что это потребует изменений (культурных и технических) во всей организации, на что у них часто не хватает полномочий или влияния.

Культурным препятствием, на которое они часто наталкиваются, становятся традиционные подразделения разработки и эксплуатации, привыкшие работать изолированно, что ограничивает межгрупповое взаимодействие вплоть до момента выпуска программного обеспечения. (Да и тогда оно часто ограничивается серией билетов в системе отслеживания ошибок.) Производители ПО должны встать на путь более тесного сотрудничества, иначе эти организации просто прекратят свое существование. Индустрия программного обеспечения движется именно в этом направлении — и гораздо быстрее, чем ожидалось, — благодаря облачным вычислениям, которые делают вычислительные ресурсы менее дефицитными, и под нажимом спроса. Победят те компании, которые участвуют в этом движении.

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

Рост объединенных групп

Объединенная группа состоит из специалистов по всему циклу поставки программного обеспечения ― инженеров по эксплуатации, администраторов баз данных (DBA), тестеров, разработчиков и аналитиков. Каждый член этой группы вносит свой код в репозиторий с контролем версий. Например, инженер по эксплуатации вносит код инфраструктуры и конфигурации; DBA ― код на языке определения данных (DDL), моделирования данных (DML) и наборы данных в виде кода; аналитик вносит код требований; разработчик ― код приложения и конфигурации; а тестеры ― код тестов.

Роль специалистов

Людям, привыкшим работать в организациях, где все подчинено плану, может потребоваться время, чтобы освоиться в новой объединенной группе. Квалификация отдельных членов группы зачастую оказывается слишком узкой, и ее необходимо расширить. По этой причине в первоначальных, экспериментальных проектах для консультирования членов объединенной группы можно привлечь специалистов организации (например, по безопасности). Консультанты не входят в объединенную группу и не вносят своих тестов или кода. Их задача ― расширить квалификацию членов объединенной группы. Когда они станут универсальнее, команда будет меньше полагаться на консультантов.

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

Объединённые группы состоят из представителей всех дисциплин, отвечающих за разработку и поставку систем программного обеспечения. Вместо того чтобы рассматривать каждую дисциплину как отдельную, централизованную обслуживающую организацию, ключевым организационным элементом становится группа поставки. Эти группы сотрудничают в целях согласованной поставки программного обеспечения без неувязок во времени, характерных для групп, взаимодействующих через структуру организации. В состав каждой группы должны входить (как минимум) бизнес-аналитики, представители клиента, администраторы баз данных, разработчики, руководители проектов и инженеры по контролю качества и выпуску. Объединенная группа способствует устранению синдрома «это не моя работа» и других преград, которые препятствуют взаимодействию между группами как внутри их физической территории, так и на удалении.

Мастера на все руки

Через некоторое время вы обнаружите, что люди трансформируются, становясь универсальными инженерами-аналитиками, которые начинают заниматься не только своей составляющей процесса поставки программного обеспечения. Например, программист может писать сценарии DDL и DML. А бизнес-аналитики ― определять свои требования в форме сценариев приемочных испытаний (таких как Cucumber), чтобы все изменения проходили автоматизированное тестирование на основании требований заказчика. Каждый член группы знает, что он должен писать тесты, сценарии, версии (см. Agile DevOps ― гибкая разработка и эксплуатация ПО: все под контролем версий ) и делать все, что от них требуется, в рамках непрерывной системы (см. Agile DevOps ― гибкая разработка и эксплуатация ПО: непрерывная поставка программного обеспечения в облаке). Это справедливо для всех исходных артефактов: кода приложения, конфигурации, инфраструктуры и данных. Когда члены группы становятся более универсальными, барьеры рушатся, взаимодействие улучшается, и узкие места, характерные для старых организаций по разработке ПО, исчезают.

Процесс

Все, что составляет полную систему программного обеспечения, это либо сценарий (то есть программа), либо автоматический тест. Все, что составляет систему программного обеспечения, находится под контролем версией и включено в конвейер непрерывной поставки. Когда все, что вносит любой член группы, проверяется в хранилище с контролем версий, создается полная система программного обеспечения — включая среды, базы данных и прикладное ПО/службы с использованием версированных конфигураций. Версируются все без исключения компоненты системы. Члены объединенной группы на 100% отдают себя проекту и не связаны ни с какими другими проектами. Этот подход способствует взаимодействию и исключает любые узкие места.


Как это работает?

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

Пилотные проекты

Попытки изменить большую организацию целиком почти всегда обречены на провал. Рекомендуется начать с небольшого экспериментального проекта, который приведет к созданию чего-то полезного в течение относительно короткого времени — в идеале, не более 90 дней. Экспериментальный проект должен быть чем-то стратегическим — не таким приложением, которое редко обновляется и приносит незначительный эффект. Эта новая группа должна быть объединенной, и каждый член должен заниматься только этим проектом. (Они не должны работать над другими проектами.) В этой объединенной группе должны присутствовать все специалисты, необходимые для разработки системы программного обеспечения (операторы, программисты, администраторы баз данных, тестеры и т.п.).

Сервис-ориентированные архитектуры

Для работы небольших групп, которые эффективно общаются, необходимо демонтировать монолитные архитектуры. Архитектуры со многими тесно связанными взаимозависимыми системами хрупки и очень трудно поддаются изменениям. Это не означает, что не нужно строить больших систем; но эти системы должны быть слабо связанными ― как службы, взаимодействующие посредством простого протокола.

Продемонстрировав успех одного проекта, его можно распространять на другие. В эти проекты войдут члены группы первого экспериментального проекта, которые будут делиться своими знаниями, и каждый должен быть членом новой группы на все 100%. Когда и эти проекты окажутся успешными, можно удвоить или утроить число экспериментальных групп, пока все стратегические проекты не будут переведены на новую модель.

Централизованные функции

Итак, все рабочие группы малы (не более 10 человек) и независимы. Тогда какие же организационные функции остаются централизованными? У всех организаций свои особенности, но там где группы используют принципы DevOps и непрерывной поставки, централизованные функции ― это либо разработка платформы, используемой остальными группами разработки ПО, либо контроль за системой (приложение, сеть, безопасность и т.п.). Это могут быть координаторы выпусков и руководители, но ни одна из этих централизованных групп не должна делать ничего, что удлиняло бы время ожидания для объединенных групп (другими словами, услуги централизованных групп предоставляются только в форме самообслуживания). Часто в таких организациях группы обслуживания (состоящие из программистов, специалистов по эксплуатации, администраторов баз данных, тестеров и т.п.) строятся по принципу дежурства (обычно в порядке очереди) и отвечают за решение производственных вопросов.

Системы самообслуживания

Сам построил ― сам запусти!

Когда системы поставки программного обеспечения строятся таким образом, что поставляемое программное обеспечение создается только путем автоматических изменений, любой член группы (в которой не более 8-10 членов) способен развернуть изменения в производственной или любой другой среде. Как разработчик (кода инфраструктуры, кода приложения, аналитических сценариев или чего-то еще) вы имеете дело непосредственно с пользователем — а не с традиционным отделом эксплуатации, — что способствует очень быстрой обратной связи.

Одна из главных особенностей DevOps заключается в том, что для осуществления своей деятельность в рамках процесса поставки член группы никогда не нуждается в услугах членов других групп вне его объединенной группы. Все должно работать на принципах самообслуживания. Любой член группы должен быть способен выпускать программное обеспечение в производство (см. врезку Сам построил ― сам запусти!). Когда члены группы сами разрабатывают все компоненты системы поставки программного обеспечения, они будут думать о том, как сделать это так, чтобы можно было работать без ожидания в конвейере поставки с предъявлением билетов, обменом электронными сообщениями или с использованием других механизмов связи. (Часто группы, освоившие DevOps и непрерывную поставку, продолжают пользоваться этими инструментами. Однако они автоматизированы в контексте конвейера поставки.)

Модели

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

Таблица 1. Модели, поддерживающие работу DevOps
МодельОписание
Большие, наглядные информационные панелиГруппы по всей организации своевременно получают информацию о состоянии системы программного обеспечения, включая состояние сборок, потребительские характеристики и степень готовности.
Локальное размещениеДля улучшения взаимодействия члены группы физически находятся поблизости друг от друга.
Непрерывная интеграцияПрограммное обеспечение строится с каждым изменением (среды, приложения и т.п.).
Объединенные группыГруппы поставки программного обеспечения состоят из специалистов по различным дисциплинам, включая программистов, тестеров, аналитиков и операторов.
Специалисты широкого профиляУменьшите разграничение ответственности между специалистами, расширяя профиль объединенных групп.
Развертывание по сценариямРазвертывание программного обеспечения в среде полностью описано сценариями, которые можно запустить одной командой.
Среда, описываемая сценариемПроцесс создания среды целиком описан сценарием, который можно запустить одной командой.
Выпуски на принципах самообслуживания (сам построил ― сам запусти!)Любое уполномоченное лицо в группе может выполнить развертывание в производственной среде и делает это.
Остановка конвейераКаждый может и должен остановить систему непрерывной интеграции, когда это необходимо.
Все основано на тестированииДля всего создаются автоматические тесты: приложений, инфраструктуры, всего на свете. Это могут быть тесты написания модулей, приемки, нагрузки и производительности.
Все версированоВсе артефакты версионируются: код приложений, конфигурация, инфраструктура и данные.

Долой старую модель разработки программного обеспечения!

Присоединяйтесь

Раздел developerWorks Гибкая трансформация (EN) сдержит новости, обсуждения и пособия, которые помогут вам и вашей организации построить фундамент для гибкой разработки.

Эта статья учит, что одно из условий эффективной реализации модели DevOps ― это разрушение барьеров и создание объединенных групп, способных внедрить свое программное обеспечение в производство. Организациям с длительным циклом подготовки и поставки придется измениться или уйти из бизнеса. В крупных организациях процесс модернизации потребует времени и изменений в организационной культуре.

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

Ресурсы

  • Оригинал статьи: Agile DevOps: Breaking down silos.
  • How Netflix gets out of the way of innovation (Adrian Cockcroft's Blog, декабрь 2011 г.): Адриан Кокрофт рассуждает о том, как культура Netflix влияет на инновации.
  • There's No Such Thing as a 'Devops Team' (Jez Humble, continuousdelivery.com, октябрь 2012 г.): Джес Гамбл объясняет, в чем проблема функциональных барьеров и разделения обязанностей.
  • Andon: об использовании кнопки andon в процессе гибкого производства. Группы по разработке программного обеспечения могут применять ту же концепцию «аварийной остановки».
  • Continuous Delivery: Patterns and Antipatterns in the Software Lifecycle (Paul Duvall, DZone, июнь 2011 г.): 40 моделей и антимоделей непрерывной поставки.
  • Amazon's CTO: 'Amazon is a technology company. We just happen to do retail': (Brad McCarty, The Next Web, октябрь 2011 г.): в видеопрезентации, прилагаемой к этой статье, технический директор Amazon Вернер Фогельс говорит о принятом в его компании подходе к системе программного обеспечения «сам построил ― сам запусти».

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Технология Java, Open source
ArticleID=861814
ArticleTitle=Agile DevOps ― гибкая разработка и эксплуатация ПО: Разрушение барьеров
publish-date=03192013