Руководство по DevOps. Как добиться гибкости, надежности и безопасности мирового уровня в технологических компаниях

Мы можем привязать эти записи к конкретным задачам в инструментах планирования работы (например, JIRA, Rally, LeanKit, ThoughtWorks Mingle), что позволит создать более широкий контекст изменений, к примеру соотнести их с дефектами компонентов функциональности, сбоями в эксплуатации или требованиями заказчиков. Этого можно легко добиться с помощью включения номеров тикетов из инструментов планирования в комментарии о регистрации кода в системе контроля версий[171]. Благодаря такому подходу мы сможем связать конкретное развертывание с изменениями в системе контроля версий, а они, в свою очередь, связаны с тикетами инструментов планирования.

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

Что делать с изменениями из категории нормальных

Правки, не классифицируемые как стандартные, будут считаться нормальными изменениями

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

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

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

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

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

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

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