Closed ales-tsurko closed 3 months ago
I totally agree. External repo for deployment simplifies a lot of things. In current repo we can keep build scripts and artifacts for releases. New deploy repo uses these artifacts (or build from tag) to deploy the network. It also can contain chain specs and even docker related things.
I concur that establishing a separate repository for deployment can streamline our workflow significantly. By isolating deployment, we can maintain a cleaner development environment in the main repository, focusing purely on node development and artifact creation. The new deployment repository would then handle these artifacts, whether pulling directly from releases or building from specific tags. This not only simplifies our version control by avoiding the need to manage multiple network-related branches in a single repository but also enhances our deployment flexibility. Including chain specifications and Docker configurations in this dedicated repository would further centralize our deployment processes, making them more straightforward and manageable.
Ok, moving it to Todo then. Thanks guys!
I found that sometimes we want to reveal devnet secrets to the dev team. In the new deploy repo we can works with secrets with all sort of paranoia. Then we can share secrets in this repo as it should keep only devnet related stuff. To be discussed.. as it requires high-level design of new workflow.
Link of repo: https://github.com/Atleta-network/atleta-network-deploy
Deploy becomes too complex and would be easier to work with in isolation, having it's own git log. In this repo we could concentrate on the nodes itself and configure it to release artefacts on Github Releases and Docker. The artifacts could be used by workflows in the deploy repo either automaticall (CD-fashion) or manually. Also, in case of a dedicated-to-deploy repo we don't need a workflow which separates branches related to different networks.
@hrls @DmitriVT what do you think?