3. Исследовательская задача T3. Обзор отечественных CI/CD-сервисов и статических хостингов¶

3.1. Постановка¶

Сравнить не менее трёх платформ CI/CD (GitVerse, SourceCraft, GitFlic) и не менее трёх вариантов размещения статического сайта (Helios ИТМО, Yandex Object Storage, Timeweb Cloud / Selectel). Отдельно оценить трудозатраты на перенос уже написанного workflow GitHub Actions.

3.2. Метод и ограничения¶

Сведения взяты из официальной документации платформ (ссылки в конце раздела) на момент подготовки отчёта. Раздел отмечает, что именно подтверждено документацией, а что не удалось проверить: в таблицах такие ячейки помечены словами «не проверено». Платформы я не тестировала запуском одного и того же пайплайна, поэтому сравнение документальное, а оценка миграции — экспертная.

3.3. Платформы CI/CD¶

Критерий	GitVerse	SourceCraft	GitFlic
Файл пайплайна	`.gitverse/workflows/*.yml`	`.sourcecraft/ci.yaml`	`.gitflic-ci.yaml`
Модель описания	jobs / steps, `runs-on`, `uses`, `run`	events (`on`) → workflows → tasks → cubes	stages / jobs
Совместимость	документация заявляет совместимость с синтаксисом GitHub Actions, `actions/checkout@v4` указан в примере	собственный синтаксис; есть интеграция с GitHub Actions и совместимость с GitLab-пайплайнами (по документации)	собственный синтаксис, файл назван не как у GitLab
Раннеры	облачные, self-hosted (на репозиторий), организационные; выбор по меткам `runs-on`	воркеры (workers) платформы; есть self-hosted worker	self-hosted агенты (Shell, PowerShell, Docker) и облачные агенты в Docker или Kubernetes
Секреты	секреты и переменные на уровне репозитория и организации	отдельная система секретов; переменные на уровнях global / workflow / task / cube	Vault для секретов, переменные окружения
Артефакты и кэш	артефакты и кэш поддерживаются; лимиты ниже	не проверено	артефакты и кэш документированы отдельными разделами
Каталог готовых действий	стартовый репозиторий workflow-примеров; действия в стиле GitHub (`uses:`)	кубы и подключение GitHub Actions	шаблоны конфигураций и примеры
Лимиты бесплатного тарифа	500 мин. (приватные) и 1000 мин. (публичные) на пользователя или организацию; для верифицированных организаций вдвое больше; задача на облачном раннере — до 30 мин.; артефакты — 500 МБ на все репозитории, хранение 30 дней	не проверено	не проверено
Собственный домен и HTTPS	не относится к CI/CD (зависит от хостинга)	не относится к CI/CD	не относится к CI/CD

Важное изменение в GitVerse

Документация GitVerse предупреждает, что адрес https://gitverse.ru/sc перестанет поддерживать локальные раннеры в сентябре 2026 года; раннеры, зарегистрированные по старому адресу, нужно перерегистрировать на https://gitverse.ru.

3.4. Варианты размещения¶

Критерий	Helios ИТМО	Yandex Object Storage (хостинг сайта)	Timeweb Cloud S3	Selectel (облачное хранилище S3)
Способ доставки	SSH / rsync (по формулировке задания P4)	S3 API, совместимые клиенты	S3 API, CLI, Cyberduck, браузер	S3 API и Swift API, FTP, rclone, AWS CLI, s3cmd
Адрес сайта	подкаталог на сервере университета	`https://<бакет>.website.yandexcloud.net`	через публичный доступ к бакету	не проверено
HTTPS	не проверено	включён автоматически на `website.yandexcloud.net`, HTTP перенаправляется на HTTPS	доступ по HTTP и HTTPS	не проверено
Собственный домен	не проверено	возможен, но имя домена должно совпадать с именем бакета	поддерживается привязка домена	не проверено
Особенности	сайт живёт в подкаталоге: нужны корректные относительные ссылки	бакет должен быть публичным, иначе ответ 403; TLS 1.0 и 1.1 отключены с 1 августа 2025	документация прямо называет хранилище вариантом для статических сайтов	в изученном разделе документации хостинг сайтов не описан
Стоимость	для студентов — в рамках ресурсов университета (уточнять)	оплата по тарифам хранения и трафика	оплата по тарифам	оплата по тарифам

Про Helios публичной документации найти не удалось: условия доступа, HTTPS и поддерживаемые способы загрузки нужно уточнять в материалах курса и у преподавателя.

3.5. Оценка миграции workflow с GitHub Actions¶

Мой workflow выполняет четыре действия: сборка сайта, публикация на GitHub Pages, выкладка на Cloudflare Pages командой wrangler pages deploy и проверка опубликованной страницы. Оценка для переноса на GitVerse как на платформу, декларирующую совместимость:

Часть workflow	Что с ней происходит
Структура `on` / `jobs` / `steps`, `runs-on`, `run`	переносится практически без изменений; файл переезжает из `.github/workflows/` в `.gitverse/workflows/`
`actions/checkout`, `actions/setup-python`	первое подтверждено документацией, второе нужно проверить; при отсутствии заменяется шагом `run: pip install ...` на образе с Python
`actions/cache`	нужно проверить; кэш платформы описан в её документации и может иметь другой синтаксис
Секреты `${{ secrets.NAME }}`	синтаксис тот же, но секреты заводятся заново в настройках платформы
Контекст `github.*` и `GITHUB_TOKEN`	заменяется на контекст GitVerse; логику, завязанную на токен GitHub, придётся переписать
`upload-pages-artifact` + `deploy-pages`, `permissions: pages/id-token`	принципиально не переносится: это публикация через API GitHub Pages и OIDC-токен GitHub
`environment: github-pages`	не переносится
Выкладка `wrangler pages deploy` и проверка `curl`	переносятся без изменений, потому что это обычные shell-команды; меняется только способ хранения токена

Итог: структура пайплайна и shell-часть переезжают почти даром, а публикацию на GitHub Pages нужно заменить на доставку по SSH или S3. Для SourceCraft и GitFlic работа больше: оба используют собственную структуру описания, и пайплайн придётся переписывать целиком, перенося только содержимое run-шагов.

3.6. Вывод по T3¶

Для проекта, где пайплайн — это «установить зависимости, собрать сайт, выложить файлы», наименьшие затраты на перенос у GitVerse из-за заявленной совместимости с GitHub Actions. Доставку лучше строить на shell-командах (wrangler, rsync, curl), а не на специфичных для платформы действиях: тогда смена платформы затрагивает только обвязку.