Книга: Руководство по DevOps

Создайте единый общедоступный репозиторий для всей организации

Создайте единый общедоступный репозиторий для всей организации

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

Компания Google — один из самых ярких примеров использования репозитория, доступного всей организации. К 2015 г. в нем хранилось более миллиарда файлов и свыше двух миллиардов строк кода. Это хранилище кода используется каждым из 25 000 инженеров компании и покрывает все ее сервисы, включая Google Search, Google Maps, Google Docs, Google+, Google Calendar, Gmail и YouTube[155].

Один из ценных результатов такого подхода — то, что инженеры могут использовать разнообразный опыт всех сотрудников компании. Рэйчел Потвин, технический руководитель, возглавляющий группу по организации инфраструктуры для разработчиков, в интервью для журнала Wired рассказала, что у каждого инженера Google есть доступ к огромному объёму библиотек, где «практически все уже давно сделано до них».

Кроме того, как поясняет Эран Мессери, инженер команды по организации инфраструктуры для разработчиков в Google (Google Developer Infrastructure group), одно из преимуществ использования единого хранилища в том, что все пользователи имеют доступ к самой последней версии кода и ничего не нужно координировать.

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

• конфигурационные стандарты для библиотек, инфраструктуры и сред (рецепты 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. Всех версии, кроме одной, серьезно уязвимы. Поддержка всех этих вариантов — у каждого свои особенности — создает огромную операционную нагрузку. Кроме того, такое большое количество делает обновление версий рискованным и опасным, из-за чего разработчики не горят желанием эти обновления проводить. Порочный круг.

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

Если мы не можем собирать все приложения с единого дерева исходного кода, нужно найти другой способ поддержки хороших версий библиотек и их зависимостей. Например, можно завести единое хранилище, такое как Nexus, Artifactory или репозиторий Debian или RPM. Это хранилище затем необходимо регулярно обновлять, если в репозиториях или в производственных системах будут выявлены уязвимые места.

Оглавление книги

Похожие страницы

Генерация: 1.623. Запросов К БД/Cache: 3 / 1
поделиться
Вверх Вниз