Книга: Руководство по DevOps

Глава 18. Создайте процессы проверки и координации для улучшения качества текущей работы

Глава 18. Создайте процессы проверки и координации для улучшения качества текущей работы

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

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

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

Скотт Чейкон, директор по информационным технологиям и один из основателей компании GitHub, писал на своем сайте, что запросы на внесение изменений — механизм, позволяющий инженерам сообщать об изменениях, отправляемых в репозиторий GitHub. Когда запрос отправлен, заинтересованные лица могут оставить отзыв о предлагаемых правках, обсудить потенциальные модификации и даже, если потребуется, предложить расширение кода на основе предлагаемых изменений. Программисты, отправляющие запрос, часто запрашивают «+1», «+2» и так далее в зависимости от того, сколько отзывов нужно.

На GitHub запросы на внесение изменений — также механизм для развертывания кода в производственную среду через набор практик, называемых пользователями «потоком GitHub». Так программисты запрашивают рецензии, собирают обратную связь, на ее основе вносят изменения в код и сообщают о развертывании кода в производственной среде (то есть в ветку master).

Рис. 40. Комментарии и предложения к запросу внесение изменений, GitHub (источник: Скотт Чикон, “GitHub Flow”, сайт ScottChacon.com, 31 августа 2011 г., http://scottchacon.com/2011/08/31/github-flow.html)

Поток GitHub состоит из пяти этапов.

1. Чтобы начать работать над чем-то новым, инженер создает соответствующую именованную ветку от «master» (например, «new-oauth2-scopes»).

2. Инженер работает только с этой веткой, регулярно отправляя свой код на сервер.

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

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

5. Когда правки внесены и отправлены в главную ветку, инженер развертывает их в производственную среду.

Эти практики, встраивающие рецензирование и координацию в процесс ежедневной работы, позволили компании GitHub быстро и надежно поставлять на рынок продукты высокого качества и высокой надежности. Например, в 2012 г. сотрудники провели 12 062 развертывания — потрясающее количество. В частности, 23 августа на общекорпоративной конференции придумали и обсудили много новых замечательных идей, и это был самый загруженный день этого года: сотрудники и пользователи провели 563 сборки и 175 успешных развертываний. Все благодаря механизму запросов на внесение изменений.

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

Оглавление книги