Описание технических средств хранения исходного текста и объектного кода ПО
Хранение исходного кода
Исходные коды программного обеспечения разработаны и контролируются российской организацией ООО «Яндекс» и находятся в принадлежащих ООО «Яндекс» дата-центрах на территории Российской Федерации.
Услуги распределенного хостинга предоставляются ООО «Яндекс.Хостинг» по договору.
Для работы над проектом используется система контроля версий Arcadia (Arc). Команда разработчиков взаимодействует с консольным или браузерным инструментом для выгрузки кода на сервер и изменения структуры.
Arc — легковесная система контроля версий для монорепозитория, хранящая данные в облаке и использующая виртуализацию рабочей копии вместо скачивания всех данных репозитория. Это позволяет занимать место на диске только для хранения локальных изменений и для оптимизации скорости работы (дисковый кэш).
Для работы с исходными кодами единого репозитория из браузера создан веб-интерфейс Arcanum.
Особенности единого репозитория
-
Исходные коды всех проектов хранятся в одном месте. Для каждого крупного проекта заводится отдельный каталог, где расположены его исходные коды. Есть специальный каталог для хранения исходных кодов общих внутренних библиотек (library), внешних библиотек (contrib) и экспериментов (junk).
-
Trunk-based development. Весь актуальный код хранится в главной «ветке», которая называется «транк» (англ. trunk - ствол). В определенных случаях от транка могут отводиться дочерние ветки (branches). Все проекты должны отправлять свои коммиты в транк.
-
Зеленый транк (green trunk). Любые изменения перед добавлением в транк проверяются набором тестов. Изменения, для которых тесты не проходят, не добавляются в транк. В Arc добавление изменений организовано через пулл-реквесты (pull-request).
-
Герметичность. Любой из проектов, хранящихся в едином репозитории, собирается только с использованием исходных кодов из этого репозитория. Исходные коды внешних библиотек и описание процесса сборки хранятся в этом же репозитории.
Уровни использования единого репозитория
В едином репозитории предусмотрено два уровня использования tier (англ. tier - уровень):
-
Tier 0 — проекты, полностью интегрированные со всеми рекомендуемыми инструментами и технологиями разработки в едином репозитории. Сюда относится большинство проектов на C++, Java, Python и Go.
-
Tier 1 — проекты, исходные коды которых хранятся в едином репозитории, но при этом используют собственные инструменты тестирования и сборки. В первую очередь сюда относятся проекты мобильной и фронтенд-разработки.
Бэкенд-разработка ПО Форм относится к tier 0, фронтенд-разработка — к tier 1.
Компиляция исходного кода
Для компиляции сервиса из исходного кода используются внутренние инструменты Ya.make, Yandex Deploy, Runtime Cloud. Ya.make собирает проект из исходного кода, Yandex Deploy управляет релизом проекта, запуская его в контейнерах инфраструктурного контейнерного облака Runtime Cloud.
Ya.make
Система сборки Ya.make позволяет собирать и тестировать код на четырех основных языках: C++, Python, Java и go. Она имеет развитые средства работы с protobuf. Сборка может исполняться локально с локальным кэшированием, локально с удалённым кэшированием, а также на кластере распределённой сборки.
Система сборки Ya.make:
-
Полностью статическая. Все зависимости анализируются заранее и изменения фиксируются в графе команд. На основе анализа каждая команда получает уникальный идентификатор UID, который фиксирует её результат на данном состоянии входных данных и зависимостей. Неизменность UID говорит о неизменности её результата и потому служит ключом в кэше результатов, а также используется при анализе изменений для исключения команды из исполнения.
-
Универсальная и высокоуровневая. Описание системы сборки делается на уровне модулей, макросов и зависимостей между модулями.
-
Декларативная. В описании сборки большая часть конструкций фиксирует свойства модулей и команд и связи между ними. При этом часть конструкций выполняется последовательно: установка и вычисление локальных переменных, условные конструкции — порядок написан в ya.make-файле.
Все инструменты, используемые в сборке зафиксированы в бинарном виде или строятся из исходного кода в рамках сборки. Единственными допустимыми источниками входных данных являются репозиторий Аркадия и хранилище Sandbox, ссылки в которое по ID фиксируются в репозитории. Сам Sandbox гарантирует неизменность данных для ID.
Deploy и Runtime Cloud
Runtime Cloud — инфраструктурное (внутреннее) контейнерное облако из более чем сотни тысяч серверов расположенных в нескольких геолокациях и обслуживающее десятки тысяч пользовательских сервисов.
Структура сервиса в Deploy
Самый нижний уровень представляет Workload — это приложение, бинарный файл, микросервис, скрипт. В Workload указываются параметры запуска, проверки готовности и живости процесса, логи, unistat url для сбора метрик, сбор корок и локальные переменные окружения.
Workload расположен внутри Box — контейнера, файловой системы, docker образа, porto слоёв. В настройках Box указываются ограничения по ресурсам, общие для Workload переменные окружения, базовые слои вашего приложения (docker/porto), статические и динамические ресурсы. В Box определяются файлы, запуск которых настраивается в Workload'ах.
Pod (Под) — это основная и минимальная единица управления деплоя, агрегирующая сущность для Box, Workload. Для Pod доступны такие настройки как FQDN, net/mount/pid ns. Именно Pod'ы создаются и запускаются в датацентрах, настраивается их количество для распределения нагрузки, Pod'ы отображаются в UI Deploy и мониторингах, имеют свою ревизию и т.д.
Уровнем выше Box находится Deploy Unit, который управляет группами одинаковых Pod в соответствии с выбранной политикой деплоя, сколько Pod'ов с какими ресурсами в каких дата центрах запустить в какой последовательности. N одинаковых Pod'ов = Deploy Unit.
Stage — группа deploy unit, выкладка которых оркестрируется между собой. Служит, например, для разделения окружений (testing, pre-stable, stable) или объединения разных, но связанных логически Deploy unit (backend + frontend).
Проект — это сущность, предназначенная для:
- логического разделения сервисов между собой;
- группировки Stage;
- выдачи ролей на все стейджи проекта.
Адрес нахождения технических средств хранения исходного текста и объектного кода программного обеспечения, а также технические средства компиляции исходного текста в объектный код программного обеспечения
Технические средства хранения исходного текста и объектного кода программного обеспечения, а также технические средства компиляции исходного текста в объектный код программного обеспечения контролируются российской организацией ООО «Яндекс» и находятся в принадлежащих ООО «Яндекс»/ООО «Яндекс Хостинг» дата-центрах на территории Российской Федерации.
Услуги распределенного хостинга предоставляются ООО «Яндекс Хостинг» по договору.
ДЦ Сасово
Россия, Рязанская область, г. Сасово, ул. Пушкина, д.21