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

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

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

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

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

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

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

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

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

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

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