OneDev делает всё сам: git, CI, доска задач — и где тут подвох

MAATRIX

Вы поднимаете GitLab CE, потом отдельно Jenkins для сложных пайплайнов, потом Nexus под артефакты, потом Confluence или вики-плагин — и через месяц у вас четыре сервиса, четыре системы логина и четыре точки, которые могут упасть по отдельности. OneDev решает это радикально: один Java-процесс, который сам является git-сервером, CI/CD-движком, issue-трекером с канбан-досками, вики и реестром пакетов. Разберём, что в этом «всё в одном» реально удобно, а что стоит проверить до того, как переносить туда рабочие процессы всей команды.

Что такое OneDev и почему это «всё в одном»

OneDev — open-source платформа, которая позиционирует себя не как «ещё один git-хостинг», а как замена связки из нескольких инструментов сразу. Технически это одно Java-приложение (запускается на JVM), которое из коробки закрывает:

• git-репозитории с полноценным веб-интерфейсом просмотра кода и поиском по символам;
• pull request'ы с построчными комментариями и настраиваемыми правилами обязательного ревью;
• CI/CD — сборочные джобы описываются в .onedev-buildspec.yml и выполняются встроенным движком, без отдельного Jenkins или GitLab Runner;
• issue-трекер с произвольными полями, канбан-досками и итерациями (аналог milestones/спринтов);
• вики на каждый проект в markdown;
• реестры пакетов — Maven, npm, NuGet, generic-файлы и Docker/container registry по протоколу Docker Registry v2.

Для хранения метаданных (issues, настройки, история сборок) OneDev по умолчанию использует встроенную HSQLDB — работает без внешней СУБД сразу после распаковки, а для продакшена можно подключить внешний PostgreSQL или MySQL. Сами git-репозитории при этом лежат как обычные bare-репозитории на диске — это важно для раздела про подвохи ниже.

Ключевое архитектурное отличие от GitLab CE: там даже community-редакция — это мини-стек из PostgreSQL, Redis, Gitaly, Sidekiq и ещё десятка служб под omnibus-упаковкой. В OneDev это один процесс с одним конфигом и одним логом — меньше того, что может рассинхронизироваться между собой после падения сервера или неудачного обновления.

Установка: Docker и первый запуск

Официальный образ — 1dev/server. Минимальный запуск в Docker:

docker run -d --name onedev \
  -v /opt/onedev:/opt/onedev \
  -p 6610:6610 \
  -p 6611:6611 \
  --restart unless-stopped \
  1dev/server

Порт 6610 — веб-интерфейс (HTTP), 6611 — git по SSH. Volume /opt/onedev — это вся persistence: репозитории, встроенная база, конфиги, логи. Если контейнер потерялся, а том цел — сервис поднимается заново без потерь.

Первый запуск инициализирует базу и занимает не одну секунду — контейнер стоит понаблюдать через docker logs -f onedev, пока не появится сообщение о готовности сервера. После этого веб-мастер на порту 6610 попросит задать пароль администратора и базовые настройки — домен, часовой пояс.

Для продакшена сразу заводите reverse-proxy с HTTPS перед портом 6610 — точно так же, как для любого другого self-hosted сервиса, процесс подробно разобран в статье про настройку Nginx как реверс-прокси. Нюанс, который не сразу очевиден: порт 6611 (git по SSH) через обычный HTTP-реверс-прокси не проксируется — это отдельный TCP-порт, который нужно либо пробрасывать напрямую на 22/2222 наружу, либо явно открывать в файрволе рядом с 443. Если забыть об этом, git clone по HTTPS будет работать, а git clone по SSH — молча зависать на рукопожатии.

После первого входа в Administration → System Setting указывается внешний URL сервера (https://git.example.com) — без этого ссылки в уведомлениях и webhook'ах будут генерироваться с адресом контейнера, а не с реальным доменом.

Git, review и CI/CD в одном приложении

Репозитории создаются через UI или импортируются мастером из GitHub, GitLab, Bitbucket или Gitea — мастер переносит и код, и issues, что снимает часть боли при переезде с другой платформы. Pull request'ы поддерживают построчные комментарии, требование определённого числа апрувов, обязательные проверки (status checks) перед merge и защиту веток по ролям.

CI/CD описывается в .onedev-buildspec.yml в корне репозитория — либо руками, либо через визуальный конструктор джоб в UI (перетаскиваете шаги, система сама формирует YAML). Пример простого пайплайна:

version: 30
jobs:
- name: build-and-test
  steps:
  - !CheckoutStep
    name: checkout
  - !CommandStep
    name: build
    runInContainer: true
    image: maven:3.9-eclipse-temurin-21
    interpreter: !DefaultInterpreter
      commands:
      - mvn -B clean verify
  triggers:
  - !BranchUpdateTrigger
    branches: main

Выполняют джобы «исполнители» (job executors), которых можно завести несколько под разные сценарии: Server Shell Executor запускает команды прямо на хосте OneDev, Server Docker Executor поднимает контейнер на том же сервере, Remote Docker Executor выносит выполнение на отдельную docker-машину, Kubernetes Executor — на кластер. Для небольшой команды хватает Server Docker Executor на том же VPS, где крутится сам OneDev — но тогда закладывайте отдельный запас RAM под параллельные сборки, точно как с раннером GitLab: сколько RAM реально нужно под GitLab CE — логика с запасом под CI-джобы поверх базового сервиса переносится и сюда.

Issue-трекер и канбан-доска живут в том же проекте, что и код: issue можно привязать к pull request'у, а pull request — автоматически закрывает issue по ключевому слову в описании коммита (fixes #42), без настройки отдельной интеграции между трекером и git-хостингом, как это часто бывает при связке разных инструментов.

Доска задач, вики и пакеты — без отдельных сервисов

Канбан-доска строится по любому пользовательскому полю issue (обычно по статусу), с фильтрами и групповыми операциями. Итерации (iterations) закрывают роль спринтов/milestones — issue привязывается к итерации, прогресс виден в burndown-подобной сводке на странице проекта.

Вики — обычные markdown-страницы с историей правок внутри самого проекта, без отдельного сервиса вроде Confluence или BookStack: правишь прямо в браузере, версии сохраняются автоматически.

Реестры пакетов включены из коробки под самые частые форматы:

Публикация пакета из джобы CI выглядит как обычный mvn deploy или docker push, указывающий на URL самого OneDev вместо внешнего Nexus — токен доступа берётся из настроек проекта. Практический эффект: сборка, публикация артефакта и хранение issue про баг в этом артефакте — всё в одном месте, без синхронизации прав доступа между разными системами.

Что реально удобно от единой платформы

Главный выигрыш — не в отдельных фичах (у GitLab CE их объективно больше), а в отсутствии интеграционного клея между сервисами. Несколько конкретных последствий:

• Один логин, одна модель прав. Пользователь и его роль в проекте настраиваются один раз, а не синхронизируются между GitLab, Jenkins (со своим plugin для авторизации) и Nexus (со своей независимой учёткой).
• Один backup вместо трёх-четырёх. Бэкапите каталог /opt/onedev (плюс внешнюю БД, если вынесли её из встроенной HSQLDB) — и внутри уже код, issues, CI-история и пакеты. Не нужно согласовывать бэкап GitLab, отдельный дамп Jenkins-джоб и снепшот Nexus-хранилища по отдельным расписаниям.
• Меньше точек отказа и меньше патчить. Один процесс для мониторинга, один лог для разбора инцидента, одно место для security-обновлений — не четыре независимых сервиса с разным циклом релизов, где нужно помнить про каждый.
• Дешевле по железу, чем полноценный стек GitLab CE + Jenkins + Nexus. Три-четыре сервиса с их собственными JVM/БД суммарно требуют заметно больше RAM, чем один процесс OneDev с общей встроенной базой — конкретные цифры зависят от нагрузки, но порядок экономии ощутим уже на команде в 5-10 человек. Общий разбор того, что вообще выгодно держать на своём сервере, а что проще не тащить в self-hosted, — в статье экономика self-hosted: что выгодно держать.
• Согласованный UX. Issue, PR, вики-страница и CI-лог выглядят как части одного приложения, а не как четыре разных интерфейса с разной логикой поиска и разными горячими клавишами.

Это ровно тот сценарий, где связка «CI отдельно от git-хостинга» проигрывает по количеству мест, куда нужно смотреть при инциденте — контраст с классической парой git-сервер + отдельный CI неплохо виден на примере Jenkins против Drone CI, где сама постановка вопроса — «какой CI прикрутить к уже существующему git-хостингу» — в OneDev просто не возникает.

Где тут подвох: экосистема, интеграции и vendor lock-in

Честная часть. Единое приложение не бесплатно с точки зрения выбора — за консолидацию платите тремя вещами.

Экосистема плагинов и интеграций заметно уже. У Jenkins — тысячи плагинов под что угодно, от экзотических систем оповещений до нишевых облачных провайдеров. У GitLab — десятки готовых интеграций «в один клик» (Jira, Slack, PagerDuty, Datadog, security-сканеры, шаблоны CI под конкретные стеки) и огромная база готовых решений на форумах и Stack Overflow под любую нестандартную ситуацию. У OneDev готовых коннекторов заметно меньше: базовые webhook'и, уведомления по email и в Slack/Discord через generic webhook — но, например, нативной интеграции с Jira или PagerDuty из коробки нет, и придётся собирать её самому поверх REST API OneDev.

Комьюнити и документация меньше по объёму. Это не значит, что проект заброшен или плохо документирован — официальная документация вполне подробная. Но объективно проект моложе и нишевее, чем GitLab или даже Gitea/Forgejo: меньше людей уже сталкивались с вашей конкретной проблемой и написали ответ на форуме, меньше готовых Ansible-ролей и Terraform-модулей под инфраструктуру, меньше администраторов на рынке труда, которые уже знают продукт и не будут разбираться с нуля.

Данные вашего трекера и CI-истории живут в схеме, специфичной для OneDev. Сам git-репозиторий — это обычный bare-git, его в любой момент можно git clone --mirror на любую другую платформу без потерь. А вот issues, история pull request'ов, вики-страницы и логи сборок хранятся во внутренней базе (встроенной HSQLDB или подключённой внешней СУБД) в собственной схеме продукта. У GitLab и GitHub есть развитая экосистема сторонних инструментов миграции именно потому, что они массовые — под OneDev таких готовых конвертеров практически нет, и перенос issues/вики при уходе на другую платформу почти всегда означает писать скрипт самому поверх REST API OneDev, вычитывая данные постранично. Это и есть тот самый vendor lock-in внутри нишевого продукта: технически данные не заперты (API открыт, экспорт возможен), но практически — готового пути «выйти» так же просто, как «зайти» через мастер импорта, не существует.

Отсюда практический вывод: прежде чем заводить в OneDev полугодовую историю issues и вики на пятьдесят страниц, стоит явно спросить себя — насколько вероятно, что через год-два понадобится мигрировать обратно на более распространённую платформу, и готовы ли вы к этому написать разовый скрипт-экспортёр. Для сравнения, обратная логика миграции (перенос кода и части истории на свой git-хостинг с чужой площадки) разобрана на примере GitLab CE в статье перенос репозиториев с GitHub на свой GitLab — общий принцип «код переносится легко, метаданные — с трудом» применим и здесь, только в обратную сторону.

Частые вопросы