CI/CD традиционно ассоциируется с серверами, контейнерами и облачными платформами. Однако на практике часто возникает задача: быстро автоматизировать сборку, запуск тестов, статический анализ и деплой, используя компактное и доступное устройство. Termux в этом смысле выступает удобной «легковесной лабораторией»: он позволяет собрать окружение, задать последовательность шагов и выполнять их повторяемо.
В этой статье мы покажем практический подход к построению пайплайна CI/CD на Termux без привязки к конкретной экосистеме: вы сможете запускать тесты, линтинг, форматирование, а затем деплоить артефакты на удалённые серверы по SSH. Материал ориентирован на использование в рамках легальных и безопасных процессов разработки (без обхода ограничений и без эксплуатации уязвимостей).
1. Архитектура пайплайна CI/CD на Termux
Пайплайн можно представить как набор этапов:
- Подготовка окружения (зависимости, переменные окружения).
- Код (получить исходники: Git pull/checkout).
- Тесты (unit/integration, статический анализ до/после тестов).
- Качество (линтеры, форматирование, проверка типов — по языку).
- Сборка/упаковка (артефакт, сборка пакета).
- Деплой на удалённый сервер (обычно по SSH: копирование и перезапуск сервиса).
На Termux это удобно реализовать в виде сценариев (bash), которые исполняются вручную или по расписанию (например, через задачи Termux/cron-подобный механизм в зависимости от ваших условий).
2. Подготовка Termux и базовые зависимости
Начните с установки основных пакетов. В Termux откройте терминал и выполните:
pkg update -y
pkg upgrade -y
pkg install -y git openssh-client bash curlЕсли планируете деплой через сборку/языковые инструменты — дополнительно установите соответствующие пакеты (в примерах ниже будут показаны команды для популярных экосистем).
3. Безопасный деплой на удалённый сервер по SSH
Ключевой элемент CI/CD на Termux — возможность подключаться к удалённым серверам. На практике это делается через SSH-ключи (а не через логин/пароль в сценариях).
3.1. Сгенерируйте SSH-ключ (один раз) и добавьте публичный ключ на сервер
ssh-keygen -t ed25519 -a 64 -f ~/.ssh/id_ed25519_ci -N "" -C "termux-ci"Далее скопируйте публичный ключ на сервер (способ зависит от вашей инфраструктуры; здесь логика такая: добавить содержимое файла ~/.ssh/id_ed25519_ci.pub в ~/.ssh/authorized_keys нужного пользователя на сервере).
3.2. Проверьте доступ
ssh -i ~/.ssh/id_ed25519_ci -p 22 user@your-server.example.com "hostname"Если вам нужно временно работать в локальной сети через VPN для организации доступа (не для обхода ограничений), убедитесь, что в такой схеме корректно настраивается маршрутизация к серверу. В сценариях CI/CD по-прежнему используйте SSH и ключи.
4. Универсальный сценарий пайплайна: тесты → анализ → деплой
Ниже приведён шаблон bash-сценария. Он рассчитан на то, что вы заранее подготовите переменные окружения (адрес сервера, путь назначения, название приложения и т.п.).
4.1. Структура
- Сначала выполняем checkout/обновление репозитория.
- Далее запускаем тесты.
- Затем — статический анализ/линтинг.
- Если всё успешно — упаковываем артефакты и делаем деплой по SSH.
4.2. Пример сценария
#!/data/data/com.termux/files/usr/bin/bash
set -euo pipefail
REPO_DIR="$HOME/project"
BRANCH="main"
# Настройки деплоя
SERVER_HOST="your-server.example.com"
SERVER_PORT="22"
SERVER_USER="user"
SERVER_PATH="/opt/myapp"
SSH_KEY="$HOME/.ssh/id_ed25519_ci"
echo "==> Preparing workspace"
mkdir -p "$REPO_DIR"
cd "$REPO_DIR"
if [ -d .git ]; then
git fetch --all
git checkout "$BRANCH"
git pull --ff-only
else
# Вставьте ваш URL репозитория
git clone --branch "$BRANCH" "https://example.com/your/repo.git" .
fi
echo "==> Running tests"
# Замените на команды вашей экосистемы
# например: npm test / pytest / go test / mvn test
echo "==> Static analysis / linting"
# Замените на команды вашей экосистемы
echo "==> Build / package"
# Замените на команды вашей экосистемы
echo "==> Deploy"
# Пример: копирование артефакта и перезапуск сервиса
# Предположим, что артефакт лежит в $REPO_DIR/dist/app.tar.gz
ARTIFACT="$REPO_DIR/dist/app.tar.gz"
scp -i "$SSH_KEY" -P "$SERVER_PORT" "$ARTIFACT" "$SERVER_USER@$SERVER_HOST:/tmp/app.tar.gz"
ssh -i "$SSH_KEY" -p "$SERVER_PORT" "$SERVER_USER@$SERVER_HOST" "set -e
mkdir -p '$SERVER_PATH'
tar -xzf /tmp/app.tar.gz -C '$SERVER_PATH'
rm -f /tmp/app.tar.gz
# Перезапуск сервиса: команда зависит от вашей системы
# например: systemctl restart myapp
true"
echo "==> Done"Важно: команды тестов/линтинга/сборки нужно заменить на реальные для вашего языка и проекта.
5. Практика: Node.js (npm) — тесты, линтер и деплой
Если ваш проект на Node.js, базовый набор выглядит так: зависимости ставятся через npm ci, тесты — через npm test, линтер/форматирование — через eslint и/или prettier.
5.1. Установка окружения в Termux
Пакеты Node.js в Termux зависят от текущих репозиториев и вашего способа установки. Если Node.js уже установлен — пропустите. Для примера используем стандартную проверку:
node -v
npm -v5.2. Команды в пайплайне
# в корне проекта
npm ci
npm test
# статический анализ / качество
npm run lint
# или если есть форматирование
npm run format:check5.3. Деплой (пример с артефактом)
Типовой подход: собрать артефакт в dist и затем развернуть на сервере. В сценарии это выглядит примерно так:
npm run build
tar -czf dist/app.tar.gz -C dist .Дальше артефакт отправляется на сервер через scp, а команда на сервере распаковывает и перезапускает сервис (например, через systemctl).
6. Практика: Python (pytest, ruff/flake8, mypy) — тесты и статический анализ
Для Python в Termux обычно используются виртуальные окружения и стандартный стек инструментов качества.
6.1. Создание venv и установка зависимостей
pkg install -y python
python -m venv .venv
. .venv/bin/activate
pip install -U pip
pip install -r requirements.txt
# опционально: зависимости для тестов/линтинга
pip install pytest ruff mypy6.2. Тесты
pytest -q6.3. Статический анализ и линтинг
Вариант с Ruff:
ruff check .
ruff format --check .Вариант с mypy (типизация):
mypy .6.4. Деплой
Варианты зависят от того, как вы запускаете приложение на сервере (systemd service, контейнер, uWSGI и т.д.). Один из практичных CI-подходов: формировать пакет/собранные файлы и копировать на сервер.
Например, если у вас есть готовый сборочный артефакт или вы копируете исходники:
# Упаковка исходников (упрощённо)
tar -czf app.tar.gz .
scp -i ~/.ssh/id_ed25519_ci -P 22 app.tar.gz user@your-server.example.com:/tmp/app.tar.gz
ssh -i ~/.ssh/id_ed25519_ci -p 22 user@your-server.example.com "set -e
rm -rf /opt/myapp
mkdir -p /opt/myapp
tar -xzf /tmp/app.tar.gz -C /opt/myapp
rm -f /tmp/app.tar.gz
# Перезапуск: пример
true"7. Статический анализ как обязательный gate в CI
Суть CI/CD — раннее обнаружение проблем. На Termux это особенно удобно, потому что вы можете быстро прогонять:
- линг (потенциальные ошибки, стиль, потенциально опасные практики),
- проверку форматирования,
- типы (если применимо),
- тесты.
Практическое правило: сначала статический анализ (часто быстрее), затем тесты. Но порядок можно менять в зависимости от стоимости каждого этапа и вашей модели качества. Главное — сделать так, чтобы деплой выполнялся только при успешном прохождении всех обязательных шагов.
8. Как запускать пайплайны на Termux регулярно
Варианты зависят от ваших требований и условий запуска. На практике чаще всего используют:
- ручной запуск сценария командой (быстро и прозрачно);
- запуск по расписанию средствами самого Termux (если применимо в вашем окружении);
- обёртку через внешний триггер (например, если у вас есть сервер, который уведомляет об изменениях).
Независимо от способа запуска, сценарий должен быть идемпотентным: повторный запуск не должен приводить к повреждению окружения. Используйте чистые каталоги сборки или сбрасывайте их перед сборкой.
9. Рекомендации по надёжности и безопасности
- Не храните пароли в сценариях. Используйте SSH-ключи.
- Фиксируйте версии зависимостей (например,
package-lock.jsonдля npm иrequirements.txtс зафиксированными версиями для Python). - Ограничивайте права пользователя на сервере, под которым выполняется деплой.
- Проверяйте целостность артефактов (хотя бы по хешам/структуре) перед развертыванием.
- Логируйте ход выполнения (вывод в консоль и/или в файл в каталоге проекта).
Заключение
Termux можно использовать как полноценную «домашнюю» платформу для CI/CD: запускать тесты, прогонять статический анализ и выполнять деплой на удалённые серверы по SSH. Такой подход особенно удобен, когда важна мобильность, быстрые проверки качества и экономия времени на развертывание сложной инфраструктуры.
Если вы хотите внедрить CI/CD-процессы в вашем проекте (под конкретный язык, с нужными этапами и безопасным деплоем), обратитесь в РыбинскЛАБ — поможем спроектировать пайплайн, настроить инструменты качества и автоматизировать доставку изменений до продакшена.