Джин Ким - Руководство по DevOps

Мы должны убедиться, что поданные запросы на изменения — наиболее полные и точные, чтобы у комитета была вся нужная информация для верной оценки. В конце концов, если наша заявка будет неясной, ее вернут нам на доработку, что только увеличит время на введение изменений и вызовет сомнения в том, что мы понимаем цели процесса управления изменениями.

Практически всегда можно автоматизировать создание полных и точных запросов, дополняя тикеты деталями того, что именно нужно исправить. Например, можно автоматически создавать тикет изменений в ServiceNow со ссылкой на требования заказчика в системе JIRA вместе со сборкой манифеста, результатами тестов конвейера развертывания и ссылками на исполняемые скрипты Puppet/Chef.

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

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

Во многих пакетах инструментальных средств это можно сделать автоматически. Например, инструменты Mingle и Go компании ThoughtWorks могут автоматически связывать такие данные, как список исправленных дефектов или завершенные элементы функциональности, вместе и добавлять их в запрос на изменения.

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

Компания Salesforce.com была основана в 2000 г., ее целью было сделать управление взаимоотношениями с клиентами легкодоступным и легко поставляемым сервисом. Предложения организации были широко востребованы на рынке, результатом чего стало успешное IPO [172]в 2004 г. К 2007 г. у компании было более 59 000 клиентов, в день ее сервисы обрабатывали сотни миллионов транзакций, а годовой доход достиг 497 миллионов долларов.

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

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

На конференции DevOps Enterprise Summit в 2014 г. Дэйв Мангот и Рина Мэтью описали занявшую много лет DevOps-трансформацию компании, начавшуюся в 2009 г. Согласно Манготу и Мэтью, применяя принципы и методики DevOps, в 2013 г. организация сократила среднее время развертывания с шести дней до пяти минут. В результате стало легче масштабировать ресурсы, что позволило их сервисам обрабатывать более миллиарда транзакций в день.

Одной из главных тем трансформации компании Salesforce было стремление сделать качество ответственностью всех сотрудников, вне зависимости от того, работали ли они в разработке, эксплуатации или информационной безопасности. Для этого встроили автоматизированное тестирование во все стадии создания приложений и сред, а также во все процессы непрерывной интеграции и развертывания и создали инструмент с открытым кодом под названием Rouster, чтобы проводить функциональное тестирование своих модулей Puppet.