Руководство по DevOps (Ким, Уиллис) - страница 201

Скотт Чейкон, директор по информационным технологиям и один из основателей компании 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-эксплуатация и служба информационной безопасности перешли к модели постоянного сотрудничества, чтобы вносимые в наши системы изменения работали надежно, безопасно и так, как было запланировано.