27.02.18 - 11-12

02.08.2017 Крис Парнин, Лори Вильямс

Среди преимуществ, полученных благодаря непрерывному развертыванию, респонденты чаще всего отмечали ускорение реализации функциональности, улучшение качества ПО и повышение удовлетворенности клиента, что, в свою очередь, повысило и удовлетворенность сотрудников компаний, которые стали быстрее получать клиентские отзывы и при меньших стрессах. Правда, попадание дефектов в рабочие версии при быстром развертывании способно привести к обратному эффекту, но это компенсируется снижением страха нарушить установленный срок выпуска очередного релиза. Утверждение жестких сроков при редком выпуске способно нанести ущерб качеству [3], тогда как в условиях непрерывного развертывания решения руководства в большей степени основаны на реальных данных и быстро поступающих откликах. Разработчики, со своей стороны, признают, что достигли более высокой продуктивности и более слаженного взаимодействия. Вместе с тем, когда приоритетны темпы выпуска, могут пострадать архитектура, безопасность и согласованность. При более частом развертывании ограничивается возможность тестирования множества конфигураций, в связи с чем некоторые специальные инструменты, например для лиц с ограниченными возможностями, вообще не проверяются. Кроме того, переменам могут сопротивляться сами разработчики, особенно если им приходится брать на себя дополнительные обязанности. Не следует забывать о том, что перевод на непрерывное развертывание тестируемых вручную продуктов с монолитными архитектурами и техническим долгом происходит медленно, иногда годами, а продукты с повышенными требованиями к безопасности и более жестким регулированием вообще не всегда можно полноценно перевести на непрерывное развертывание.

Каждая функция — это эксперимент

В основе бережливого производства лежит эксперимент. Если нет данных, оправдывающих существование той или иной функции, то она долго не «проживет» и ее отбрасывают, посчитав эксперимент неудачным. Традиционно выбор функционала происходил после тщательной предварительной оценки: выбранные функции умозрительно проектировались, затем реализовывались и сдавались в эксплуатацию, при этом решения редко основывались на реальных данных. В условиях непрерывного развертывания разработчики относятся к каждой планируемой функции как к эксперименту, и некоторые уже выпущенные функции впоследствии отмирают. Например, если на сайте Netflix достаточное число пользователей не задержатся на новом элементе интерфейса, то в рамках последующих экспериментов его могут переместить в другое место экрана или вообще убрать. Как правило, в компаниях собирают статистику о всех аспектах выпускаемого программного обеспечения. В частности, регистрируются показатели производительности и стабильности работы, такие как время рендеринга страниц, частота доступа к столбцам базы данных, исключения и коды ошибок, время отклика и частота вызова методов API. Для сбора этих сведений архитектура разрабатываемого ПО должна быть изначально рассчитана на передачу телеметрии. Вместо локального хранения журналов производительности и ошибок на сервере соответствующие показатели потоком передаются в центральное хранилище и сразу обрабатываются в памяти. Кроме того, для нужд аналитики в некоторых компаниях содержат обширный штат специалистов по данным — до 30% от численности разработчиков ПО. В таких компаниях создается и применяется широкий спектр инструментов исследования данных, в том числе самостоятельно разработанные языки запросов. При этом многие организации сталкиваются с трудностями, связанными со стремительным исчерпанием возможностей инфраструктуры для хранения данных телеметрии. Так, в Netflix вначале регистрировали 1,2 млн различных показателей по службам поточной передачи видео, но уже скоро их число достигло миллиарда. Ресурсов хранилища уже не хватало, приходилось более тщательно подходить к отбору данных для экспериментов, и к тому же выросла сложность запросов, применяемых для извлечения полезных сведений о конкретных функциях. Проекты в области аналитики и телеметрии должны быть объединенными — в противном случае возможны чрезмерные затраты. Например, респонденты обсудили ситуации, когда собирались огромные объемы данных, а затем эксперимент приходилось проводить заново, так как не регистрировался какой-либо важный показатель.

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

Стоимость изменения не растет

Затраты на изменение кода ПО, находящегося в промышленной эксплуатации, могут быть на удивление низкими, хотя прогнозировалось, что цена изменений с каждой стадией разработки будет увеличиваться на порядок. Например, если коррекция на этапе первичного кодирования стоит 100 долл., то исправление на стадии тестирования обойдется уже в 1 тыс., а после ввода в эксплуатацию — в 10 тыс. При непрерывном развертывании период между разработкой и обнаружением дефектов рабочей версии системы обычно краток: часы или дни. Если уже на следующий день пользователь жалуется на дефект, то его исправление с большей вероятностью будет эффективным, поскольку разработчик только что закончил работу и хорошо помнит свои действия. При непрерывном развертывании все стадии разработки протекают за один день, осуществляются одним и тем же специалистом или одной группой, поэтому экспоненциального увеличения затрат нет — кривая роста стоимости изменения сглаживается. Иначе говоря, если на этапе разработки изменение обходится в 100 долл., то оно будет стоить столько же и для рабочей версии.

В Google выяснили, что объем изменений, подлежащих проверке на этапе устранения дефектов, невелик, поэтому проще обнаружить виновников. К тому же, когда изменения вносятся в рабочую среду, разработчики, руководствуясь отзывами, сами быстрее выявляют недостатки. Например, в Facebook программист должен засвидетельствовать во внутренней чат-системе, что его изменение находится в «ждущем режиме», то есть попадет в рабочую версию только через день-два. Таким образом, у разработчиков, вносящих изменения, есть возможность оперативно реагировать на ошибки. Проблема цены изменения в ходе опроса даже не обсуждалась — если рост и есть, то весьма незначительный по сравнению с другими затратами.

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

Торопитесь с развертыванием, а не с выпуском

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

Допустим, в Instagram решили реализовать новшество — ветвление дискуссий в комментариях к постам. Можно внести соответствующий код в рабочую систему, но предоставить доступ к новой функции лишь узкой группе пользователей для тестирования и оценки. Это называют «темным запуском» (dark launch), который позволяет разработчику неторопливо развертывать и дорабатывать небольшие фрагменты кода в рабочей среде, не оказывая влияния на обслуживание пользователей. После стабилизации кода можно уже активировать функцию и выпустить ее в промышленную эксплуатацию.

В Instagram «темный запуск» применяется довольно часто, причем функции перед официальным релизом могут дорабатывать до полугода. В Microsoft регулярно развертывают крупные архитектурные изменения, прибегая к «темному запуску» в сочетании с флажками функций (feature flag). Флажки позволяют развертывать функции в рабочей системе, но отключать их до тех пор, пока они не будут готовы к выпуску; отключение и включение выполняются через сервер конфигурации. Пользуясь этими приемами, в Microsoft избегают проблем, связанных с интеграцией и долгосрочным сопровождением функциональных ветвей. Раннее и частое развертывание изменений в рабочей среде в целом позволяет снизить уровень сложности соответствующих процедур.

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

Существует ряд методов, позволяющих контролировать сроки раскрытия очередных изменений для клиентов; есть также возможность сохранять неторопливый темп выпуска, развертывая при этом ПО на ежедневной основе. В любом случае компаниям необходимо тратить дополнительные усилия на то, чтобы исключить негативное влияние тестирования в рабочем режиме и отложенного выпуска на обслуживание пользователей.

Вкладывайтесь в выживание

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

В компаниях с более зрелыми процессами непрерывного развертывания, например в Instagram и Netflix, признают, что опора на соответствующие инструменты приносит колоссальные дивиденды. В Facebook, например, сил небольшой группы специалистов, отвечающих за оснастку и автоматизацию выпуска, достаточно, чтобы обеспечивать всем необходимым гораздо более крупную команду разработчиков, занимающихся функционалом. В Instagram автоматизирован контроль соблюдения последовательности выполнения операций. С помощью соответствующих инструментов стандартные потоки работ и задачи оформляются в виде воспроизводимых операций, выполняемых автоматизированными системами или разработчиками. Если процесс реализован с использованием инструментальной цепочки, то подобно коду его можно отлаживать, подвергая версионному контролю и контролю качества.

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

За поддержку отвечает сам разработчик

При непрерывном развертывании разработчики имеют возможность и право вносить изменения в рабочую систему, однако больше власти означает и больше ответственности. Если код в рабочем режиме даст сбой, кто за это отвечает — разработчики или специалисты по эксплуатации? Традиционные методы разработки ПО не позволяют навести порядок в распределении ответственности: разработчики «перебрасывают код через стену» в отдел контроля качества, а там, в свою очередь, могут «перекидывать» его дальше специалистам по эксплуатации. Ряд участников опроса пожаловались на разработчиков, которые не утруждают себя тем, чтобы внимательно ознакомиться с требованиями к создаваемому ПО, откликами пользователей и с возможностями рабочей среды.

Когда разработчик является владельцем функции или изменения кода на всем цикле от реализации до развертывания, на нем лежит и весь груз ответственности. Это означает, что при неполадках именно он получает запрос о поддержке и обязан устранить проблему независимо от времени суток. В этом случае традиционная структура рабочего коллектива становится уже неактуальной. В Netflix, например, вообще нет специальных групп, отвечающих за эксплуатацию. Функциональные роли, такие как контроль качества и эксплуатация, по-прежнему есть, но за их выполнение отвечают сами разработчики: формируются сотни слабо связанных, но жестко координируемых команд. Отдельных структур, занимающихся контролем качества, эксплуатацией и разработкой, нет, но в каждой группе есть специалисты всех соответствующих профилей. В Instagram пришли к выводу, что оптимальны группы, участники которых специализируются в разных областях, но при этом являются владельцами определенных функций системы на протяжении всего их жизненного цикла. В Instagram и Red Hat практикуют ротацию обязанностей, когда каждый участник группы часть своего времени тратит на техническую поддержку, что позволяет равномерно распределять соответствующую нагрузку.

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

Как перейти на новые принципы организации деятельности? В LexisNexis, например, пришли к выводу, что в случае традиционной организации, когда разные группы отчитываются перед разными структурами, имеющими различные цели, интеграция происходит гораздо сложнее. Кроме того, проблемы командного взаимодействия и разделения ответственности могут усугубляться, например, из-за ресурсных ограничений, практики ручного тестирования и т. п. В новых условиях обязанности разработчика становятся более многообразными: с одной стороны, увеличивается область его ответственности, а с другой, он лучше понимает влияние вносимых им изменений.

Конфигурация — это код

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

Изменения нередко вносятся без прерывания работы систем, на скорую руку, что может приводить к «дрейфу конфигурации» (расхождениям в настройках систем). Например, инженер, экспериментируя с оптимизацией скорости выполнения запросов к базе данных, меняет настройки одного из серверов СУБД, а это изменение необходимо тиражировать на четыре других сервера баз данных. Если для обслуживания одного и того же приложения используются несколько серверов и хотя бы в одном из них произошел дрейф конфигурации, это может привести к сложным в отладке сбоям.

Современные средства конфигурационного управления, такие как Ansible, Puppet, Chef и Salt, позволяют автоматизировать соответствующие задачи и обеспечивать их оркестровку на всех серверах с помощью скриптов.

Сегодня нормой стали процессы конфигурационного управления, аналогичные управлению функциями и кодом. В Netflix, к примеру, при каждой фиксации кода в процессе сборки создается пакет Debian, в котором указаны все необходимые зависимости, а затем все они устанавливаются на новый образ виртуальной машины Amazon Web Services. Участники опроса из Facebook и Netflix отметили, что даже при наличии необходимой оснастки изменения конфигурации могут вызвать трудные в отладке ошибки. В Netflix вносят порядка 60 тыс. изменений в день, но системы отслеживания и контроля изменений у компании нет. Как следствие, компания нередко «сама стреляет себе в ногу». В Red Hat, в свою очередь, выяснили, что, как и в случае с обширными кодовыми базами, обширные конфигурационные базы могут выходить из-под контроля.

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

Успокаивайте заказчиков, взаимодействуя с ними

Переходя на непрерывное развертывание, в компаниях стараются снять беспокойство заказчиков относительно изменения темпов выпуска. При этом в современном мире у потребителей нередко просто нет выбора, кроме как принимать непрерывно поступающие обновления сервисов и устройств, а представители новых поколений даже рассчитывают на это. Если мобильные устройства приучают людей принимать постоянные изменения и если автомобили и телевизоры обновляются сами собой, то почему не ждать того же от корпоративного ПО? Заказчиков, готовых ждать очередных обновлений год или два, со временем будет все меньше. Однако еще не все заказчики и компании готовы к таким переменам. В пример можно привести опыт Microsoft с Windows 10. Корпорация перешла от масштабных редких обновлений своей ОС к регулярным инкрементальным улучшениям. Пользователей настойчиво подталкивали к переходу на Windows 10: инсталляционные файлы загружались заранее, постоянно поступали напоминания о необходимости обновить систему, возможности отказаться от обновления ограничивались. Кому-то эти перемены нравятся, но они создают сложности для корпоративных клиентов, у которых нет желания или возможности часто устанавливать обновления, например, из-за ограничений, связанных с внутренними процессами интеграционного тестирования и нормативными требованиями.

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

Зачастую главным источником дискомфорта заказчика является падение производительности после обновления системы. В IBM, например, раньше тратили месяц на то, чтобы осуществить перевод действующей у заказчика системы на новую версию. Основная трудность состояла в том, чтобы обеспечить координацию изменений кода и базы данных с локальными экземплярами. В конечном счете процесс модернизации удалось сократить до часа. Аналогично в SAS наибольшая помеха при развертываниях состояла в том, что этот процесс приводил к длительным периодам простоев у заказчиков и приходилось поддерживать одновременно много версий срезов данных и развернутых систем. При ускорении темпов развертывания необходимо следить за тем, чтобы они не были выше, чем могут себе позволить пользователи. В любом случае лучший способ успокоить заказчика — обеспечить гарантию возможности внести изменение сразу же, как тот будет к этому готов.

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

Непрерывное развертывание требует постоянного ретроспективного анализа процесса выпуска — практически все участники опроса рассказывали, как в результате случайных ошибок при изменении конфигурации полностью останавливалась работа систем. В Netflix, например, из-за неверных настроек, переданных в формате JSON, однажды целиком отключился модуль обнаружения.

Для анализа подобных сбоев во всех компаниях проводят ретроспективные собрания («вскрытия»), на которых участники группы обсуждают причины и последствия непредвиденных простоев и неудачных развертываний, а также изменения процессов. Ряд респондентов рассказали о собственном опыте участия в ретроспективных собраниях. В Netflix разработчик сообщает о перебоях в системе учета проблем, ставя оценку уровня их серьезности. Регистрируя перебои, разработчики затем могут выполнять метаанализ накопленных данных, что позволяет обнаруживать тенденции и систематические недочеты в организации процесса разработки. Серьезные перебои обсуждаются на еженедельных ретроспективных собраниях с участием представителей множества групп.

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

Ретроспективные собрания также могут помочь в изменении принципов работы. На заре существования Facebook от разработчиков требовали придерживаться принципа «двигайтесь быстро, не боясь ломать», но в какой-то момент, когда этим слишком увлеклись, появился новый девиз — «задержись и исправь то, что испортил».

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

Безопасность и конфиденциальность — часть общего процесса

Большинство опрошенных отметили, что обеспечение конфиденциальности и безопасности остается в зоне ответственности специальной группы, а не всех разработчиков, участвующих в проекте. Непрерывное развертывание может увеличить риски, если специалисты по безопасности не успевают контролировать очередные изменения, а в рамках спринтов не предусмотрено решение проблем безопасности. Как уже упоминалось, при разработке по принципу водопада или спиральной модели программисты «перебрасывают» код через стену тестировщикам, чтобы те искали дефекты. В рамках скорых методологий тестировщиков «приглашают к общему столу», чтобы с самого начала итерации они участвовали в процессе на правах партнеров. Затем разработчики и тест-инженеры передают протестированные продукты специалистам по эксплуатации для развертывания. При непрерывном развертывании к «столу» приглашаются и специалисты по эксплуатации: они участвуют в итерации, контролируя влияние очередной функции на эксплуатацию. Отвечающих за безопасность, однако, «к столу» не зовут, но с 2012 года ведутся дискуссии по организации взаимодействия разработчиков, безопасников и специалистов по эксплуатации — с тех пор развивается концепция DevSecOps.

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

В Facebook изменения кода, способные повлиять на конфиденциальность, проходят более длительный процесс выпуска, чем стандартный, занимающий обычно день. Кроме того, отдельная группа инженеров занимается разработкой слоя доступа ко всем данным и средствам управления, на котором выполняется контроль соблюдения нормативных требований и конфиденциальности. В Google применяют меры контроля безопасности развертывания: ввели обязательную авторизацию пользователей, передающих код для развертывания, проводят строгий контроль доступа и проверку контрольных сумм двоичных файлов. Кроме того, в компании обеспечивают надежную изоляцию рабочей сети от корпоративной; в частности, рабочая сеть состоит только из серверов — отсутствие рабочих станций снижает вероятность злонамеренного вмешательства в уже развернутый код.

Новая эпоха наступает независимо от вашей готовности

Ваши конкуренты постоянно совершенствуют свои продукты. А вы? Все участники исследования признали, что сегодня для сохранения конкурентоспособности необходимо обеспечить быстрый выпуск все новой функциональности. Опрос, проведенный компанией CA Technologies еще в 2015 году, показал, что 88% респондентов уже внедрили концепцию DevOps, имеющую схожие методы с непрерывным развертыванием, а некоторые даже неформально приравнивают их. В Puppet Labs провели анкетирование с участием 4976 респондентов, согласно результатам которого, в ИТ-службах, взявших на вооружение DevOps, было в 60 раз меньше сбоев, а частота развертываний оказалась в 30 раз выше. В пятерку областей, где DevOps используется шире всего, входят ИТ, разработка веб-приложений, финансы и связь. Росту популярности DevOps способствует включение в число ключевых показателей производительности таких факторов, как рост клиентуры, взаимодействие между отделами, улучшение качества и функциональности ПО, а также ускорение технического обслуживания.

***

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

Литература

• T. Savor et al. Continuous Deployment at Facebook and OANDA, Proc. 38th Int’l Conf. Software Eng. Companion. — 2016. P. 21–30.
• M. Marschall. Transforming a Six Month Release Cycle to Continuous Flow, Proc. 2007 Agile Conf. (Agile 07). — 2007. P. 395–400.
• R. Torkar, P. Minoves, J. Garrigos. Adopting Free/Libre/Open Source Software Practices, Techniques and Methods for Industrial Use // J. Assoc. for Information Systems. — 2011. Vol. 12, N. 1, article 1.

Крис Парнин (cjparnin@ncsu.edu), Лори Вильямс (lawilli3@ncsu.edu) — сотрудники Университета штата Северная Каролина, возглавляющие коллектив авторов статьи из компаний IBM, Red Hat, Cisco Systems, Mozilla, Netflix, SAS, Google, LexisNexis, Microsoft, Facebook.

Chris Parnin, Laurie Williams, et al, The Top 10 Adages in Continuous Deployment. IEEE Software, May/June 2017, IEEE Computer Society. All rights reserved. Reprinted with permission.

https://www.osp.ru/os/2017/03/13052657/