Я работаю над проектом dapp , который включает в себя основной смарт-контракт с некоторыми зависимостями от интерфейса и хранилища контрактов (короче говоря: основной контракт реализует стандарт ER C и использует стратегию сегрегацию данных для рендеринга) мой контракт обновляемый
Контракты и фронт -end исходные коды находятся под контролем версий в том же репозитории git. Я использую truffle для модульного тестирования (с ganache-cli) и компиляции.
У меня есть CI / CD (Gitlab), который запускает:
- линтеры
- построение контрактов
- пакет веб-приложения (с использованием
parceljs) - тестирование контрактов с использованием средства запуска тестов трюфеля
- тестирование веб-приложения с использованием Jest
- (отчеты istanbul о покрытии кода с использованием
solidity-coverage и Jest)
До сих пор мне нужно было только протестировать все dapp локально, и, следовательно, все, что мне нужно сделать заключается в развертывании на локальном ganache devchain, а затем import .json встроенного контракта в JS коде внешнего интерфейса, например:
import { abi, networks } from "../build/contracts/myContract.json";
...
, тогда я могу создать экземпляр контракта, используя abi и развернутый адрес, и передать chainId в сборщик parceljs с dot.env следующим образом:
...
var myContract = new web3.eth.Contract(abi, networks[process.env.CHAIN_ID].address);
...
Затем я могу протестировать все dapp локально со встроенным веб-сервером parcel.
Теперь я хочу реализовать стратегию непрерывного развертывания , fo ra, а затем и производственную среду с использованием моего экземпляра gitlab.
У меня есть хорошее представление о том, как автоматизировать развертывание контрактов, используя конфигурацию truffle, @truffle/hdwallet-provider указывает на работающий узел ethereum и сохранение начальной фразы в скрытой переменной gitlab.
Но я столкнулся с двумя проблемами:
1. Отслеживание развернутых экземпляров
Truffle отслеживает развернутые экземпляры контракта, используя тот же файл, что и тот, который содержит скомпилированный байт-код. Насколько я понимаю, трюфель делает что-то вроде сравнения bytecode с deployedBytecode, и, возможно, также, если адрес развертывателя генерирует новый экземпляр или если производный адрес нового контракта будет таким же, как уже развернутый (не уверен в этом ...).
В конце сценария развертывания контракта я должен иметь возможность сохранить адрес контракта в переменной среды и передать его сценарию, который будет транспилировать, связывать и затем развертывать (в IPFS) интерфейс dapp.
Таким образом, первый вопрос: должен ли я управлять версиями файла .json, созданного truffle compile, чтобы быть уверенным, что репозиторий проекта действует как источник правды для развернутых версий?
2. Невозможность обновления этого версионного файла при развертывании новых версий контракта
Но, если я развертываю новую версию контракта из сценария CI / CD (с использованием сценария миграции, который передает постоянный отдельный контракт хранения данных в новый основной экземпляр контракта), очевидно, что сценарий CI / CD сам себе не сможет выполнить sh a git фиксацию файла .json с обновленными значениями (новый адрес контракта, транзакция ha sh и т. 1097 *.) ...
Я думал о других решениях, включая использование npm скриптов, которые будут управлять миграциями / развертываниями (с зашифрованной исходной фразой GPG, чтобы гарантировать, что только Сопровождающие проекта смогут выполнить развертывание со связанными ethereum учетными записями), а затем обновить другой специальный файл c .json, чтобы отслеживать развернутые экземпляры, и тот же сценарий, анализирующий этот файл и изменяющий трюфель .json перед запуском скрипта миграции ... Но здесь есть еще одно серьезное неудобство t: менее скрупулезный специалист по сопровождению может обойти тесты и принудительно выполнить развертывание даже в случае сбоя модульного или интеграционного теста ...
Итак, реальный вопрос здесь:
Какова лучшая стратегия CI / CD для непрерывного развертывания смарт-контрактов с использованием миграций truffle и CI / CD Gitlab (локально) с docker исполнителями?