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

• сборка среды из набора виртуальных образов или контейнеров (например, Vagrant, Docker);

• сборка новой среды в общедоступной среде облачных вычислений (например, Amazon Web Services, Google App Engine, Microsoft Azure), частном облаке или в других PaaS (таких, как OpenStack или Cloud Foundry и так далее).

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

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

Предоставляя разработчикам полностью управляемую среду, мы даем им возможность быстро воспроизводить, диагностировать и устранять дефекты, причем их работа надежно изолирована от производственных серверов и других общих ресурсов. Разработчики могут экспериментировать с изменениями в средах, а также с кодом инфраструктуры, который их создает (например, сценариями Configuration Management), продолжая создавать новые знания, общие для разработки и IT-отдела [64].

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

Десятилетиями всеобъемлющее использование контроля версий все активнее становилось обязательной практикой как индивидуальных разработчиков, так и команд [65]. Система контроля версий записывает изменения в файлах или наборах файлов, хранящихся внутри системы. Это может быть исходный код, другие активы или любые документы как часть проекта создания программного обеспечения. Мы вносим изменения в группы, называемые коммитами, или редакциями. Каждый коммит вместе с метаданными (кто внес изменения и когда) сохраняется в системе тем или иным способом, что позволяет нам сохранять, сравнивать, выполнять слияния и восстанавливать предыдущие версии объектов в репозитории. Это решение также минимизирует риски, поскольку предоставляет способ откатить объекты, измененные в производственной среде, к предыдущим версиям (в дальнейшем следующие термины будут использоваться как равнозначные: загрузить в систему контроля версий, зафиксировать в системе контроля версий, зафиксировать код, зафиксировать изменения, фиксация, коммит).

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

Чтобы мы могли восстановить производственные сервисы с повторяемостью и предсказуемо (и в идеале быстро) даже при катастрофических событиях, мы должны проверить, хранятся ли в репозитории системы хранения версий следующие активы:

• весь код приложения и все зависимости (например, библиотеки, статическое содержимое и так далее);

• все сценарии, использующиеся для создания схем баз данных, справочные данные приложений и так далее;

• все инструменты для создания среды и артефактов, описанных на предыдущем шаге (например, образы VMware или AMI, рецепты Puppet или Chef и так далее);