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

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

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

Наша цель — обеспечить, чтобы разработчики и тестировщики регулярно интегрировали код в среду, близкой к производственной, с интервалами, постепенно сокращающимися по мере выполнения проекта [72]. Мы делаем это путем расширения определения «выполнено» за границы правильного функционирования кода: в конце каждого интервала разработки мы должны иметь интегрированный, протестированный, работающий и потенциально готовый к поставке код, указанные характеристики которого продемонстрированы в среде, близкой к производственной.

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

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

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

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

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

Быстрый поток работы от разработчиков к группе эксплуатации подразумевает: любой работник по первому требованию может получить среду, приближенную к производственной. Дав разработчикам возможность использовать ее уже на самых ранних этапах проекта создания программного обеспечения, мы значительно снижаем риск появления производственных проблем впоследствии. Это один из многих методов, демонстрирующих, как отдел эксплуатации может сделать труд разработчиков гораздо более продуктивным. Мы закрепляем у разработчиков практику запускать код в условиях, близких к производственным, включая это условие в определение состояния «Закончено».

Более того, передавая производственные артефакты под управление системы контроля версий, мы получаем «единственный источник истины», что позволяет пересоздавать производственную среду быстро, повторяемо и документируемо, применяя к отделу управления те же методы работы, что и к разработчикам. А поскольку создать производственную структуру заново оказывается более легким делом, чем восстанавливать ее, решать проблемы удается быстрее и проще. Увеличивать мощность сервиса также становится легче.

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

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

Автоматизированное тестирование решает еще одну серьезную и тревожащую проблему. Гэри Грувер отмечает: «Если нет автоматизированного тестирования, то чем больше кода мы пишем, тем больше времени и средств требуется для проверки, и в большинстве случаев это абсолютно немасштабируемая бизнес-модель для любой технологической организации».

Сейчас компания Google, несомненно, является примером внутренней производственной культуры, должным образом ценящей автоматизированное тестирование. Но такой подход соблюдался не всегда. В 2005 г., когда Майк Блэнд пришел на работу в компанию, развертывание обновлений сайта Google.comзачастую сопровождалось серьезными проблемами, особенно для команды Google Web Server (GWS).