Настройка CI/CD для деплоя смарт-контрактов
Деплой смарт-контракта вручную через hardhat deploy --network mainnet — это одноразовое действие, которое превращается в проблему при регулярных обновлениях протокола. Без автоматизации: тесты прогоняются выборочно, деплой идёт с локальной машины разработчика (не всегда актуальной), верификация забывается, адреса контрактов хранятся в Notion и часто теряются. Настроенный CI/CD pipeline закрывает все эти вопросы.
Анатомия pipeline для смарт-контрактов
В отличие от backend CI/CD, смарт-контракт pipeline имеет специфический этап: деплой в mainnet необратим, и откат невозможен. Это означает, что gate-ы перед production-деплоем должны быть жёсткими.
Типичная структура GitHub Actions workflow:
PR открыт → lint + compile → unit tests → coverage check → merge в main
Merge в main → staging deploy (testnet) → integration tests → manual approval → mainnet deploy → verification → monitoring setup
Lint и компиляция — самый дешёвый шаг. npx hardhat compile + solhint (или forge build + forge fmt --check). Failing compile в PR — мгновенный feedback.
Unit tests с coverage — coverage check через hardhat-coverage или forge coverage. Устанавливаем минимальный порог: 85% line coverage, 100% для critical функций (withdraw, mint, admin). Pull request не мержится если порог не достигнут — это enforced через required status checks в GitHub.
Staging deploy — деплой на Sepolia/Polygon Amoy/BSC Testnet автоматически при каждом merge в main. Addresses сохраняются в артефакты GitHub Actions и/или в отдельный репозиторий deployments/.
Integration tests — тесты против реального задеплоенного контракта на testnet. Проверяем интеграции: оракулы, DEX-роутеры, bridge-интерфейсы. Иногда это выявляет проблемы, которые unit-тесты с моками пропустили.
Manual approval — обязательный gate перед mainnet. GitHub Environments с required reviewers. Никакой автодеплой в mainnet без человеческого подтверждения.
Управление приватными ключами в CI
Mainnet-деплой требует приватник или mnemonic. Хранить их в GitHub Secrets — минимальный стандарт. Лучше — AWS Secrets Manager или HashiCorp Vault с short-lived credentials через OIDC.
Паттерн, который мы используем для production: деплоер — это отдельный EOA с минимальным балансом (только на газ), без прав администратора. Ownership контракта сразу transferится на multisig (Safe) после деплоя. Скомпрометированный деплоер-ключ не даёт атакующему контроль над контрактом.
В GitHub Actions:
- name: Deploy to mainnet
env:
PRIVATE_KEY: ${{ secrets.DEPLOYER_PRIVATE_KEY }}
ETHERSCAN_API_KEY: ${{ secrets.ETHERSCAN_API_KEY }}
run: |
npx hardhat run scripts/deploy.ts --network mainnet
npx hardhat verify --network mainnet $CONTRACT_ADDRESS
Артефакты деплоя и адресный реестр
После каждого деплоя сохраняем артефакты: адрес контракта, block number деплоя, transaction hash, ABI. Используем hardhat-deploy плагин — он автоматически сохраняет deployments в deployments/{networkName}/ директорию. Эти файлы коммитятся в репозиторий — это source of truth для адресов контрактов.
Для мультичейн-протоколов настраиваем матрицу деплоя:
strategy:
matrix:
network: [mainnet, polygon, arbitrum, optimism]
Каждая сеть — отдельный Job с соответствующими RPC endpoints и API keys.
Мониторинг после деплоя
Деплой — не финал. Настраиваем Tenderly Alerts или OpenZeppelin Defender Sentinels на критические события: необычный объём транзакций, вызовы admin-функций, эмиссия паузирующих событий. Alert уходит в Telegram/Slack.
Для контрактов с upgradeability — мониторинг через The Graph или Ponder: индексируем события Upgraded, AdminChanged и триггерим alert при любом изменении.
Сроки
Базовый pipeline (lint + test + testnet deploy + verify): 1 день настройки. Полный pipeline с mainnet approval gate, matrix deploys и post-deploy мониторингом: 2-3 дня.