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

Помимо исходного кода в едином репозитории можно хранить и другие вещи, фиксирующие знания и опыт компании, например:


• конфигурационные стандарты для библиотек, инфраструктуры и сред (рецепты Chef, декларации Puppet и так далее);

• инструменты развертывания;

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

• инструменты конвейера развертывания;

• инструменты мониторинга и анализа;

• руководства и стандарты.


Сохранение опыта и создание общего доступа через такое хранилище — один из самых мощных механизмов распространения знаний. Как пишет Рэнди Шуп, «самый мощный механизм для предотвращения сбоев в Google — это единый репозиторий. Когда кто-то отправляет туда свой код, новая сборка всегда будет использовать последние версии всего. Все собирается напрямую из исходников вместо того, чтобы динамически подключать во время выполнения необходимые компоненты. В каждый момент времени существует лишь одна версия библиотеки, она и подключается во время сборки приложения».

Том Лимончелли — соавтор книги The Practice of Cloud System Administration: Designing and Operating Large Distributed Systems и бывший инженер SRE Google. В своей книге он утверждает, что ценность единого репозитория настолько высока, что это сложно выразить словами.

«Вы можете написать какой-нибудь инструмент всего один раз, и он будет использоваться во всех проектах. У вас есть стопроцентно точное знание о том, кто зависит от этой библиотеки; поэтому вы можете провести рефакторинг и быть полностью уверенным в том, кого затронут изменения и кому нужно провести дополнительные тесты. Наверное, я мог бы привести еще сотню примеров. Я не могу выразить словами, насколько это важное конкурентное преимущество для Google».

В Google у каждой библиотеки (например, libc, OpenSSL, а также библиотеки, разработанные самой компанией, например для поддержания многопоточности в Java) есть свой хранитель, ответственный за то, чтобы она не только компилировалась, но и успешно проходила тесты для всех зависящих от нее проектов, совсем как настоящий библиотекарь. Хранитель также отвечает за перевод каждого проекта со старой версии на новую.

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