You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Based on how the BDJuno repository is currently organized, when a new projects needs to have official BigDipper support we have to perform the following operations:
Fork either v2/cosmos/stargate or v2/cosmos/v0.44.x to create a custom BDJuno branch for the new project
Apply the custom changes to the new fork
Deploy BDJuno inside a server
Build and setup Hasura to work with the custom-made tables
Also, each time something is fixed inside either one of the two main branches (v2/cosmos/stargate or v2/cosmos/v0.44.x) we have to:
update all the other branches;
update all the running instances of BDJuno;
(potentially) update the Hasura metadata to include new tables/fields.
This has become an incredibly complicated work to be done, since it requires the knowledge of many different things such as where are the BDJuno instance deployed?, should I also updated Hasura?, etc. For this reason, onboarding new projects inside BDJuno has become increasingly harder to do and it will become the main blocking problem in the future.
Fortunately, as it might be easy to understand, all these tasks can be automated using a Continuous Deployment (CD) setup. Particularly, I think that we should now focus on creating an environment that performs the following tasks for us based on a configuration that we provide it (and we should design):
Each time there is a new project
Create a fork based on either one of the two main branches
Perform the proper setup that should be done inside BDJuno (add dependencies and simple code editing)
Each time one of the two main branches are updated:
Update each fork by pulling the new changes inside
Deploy the updated versions to the proper server
...and everything else that might be automated (please help me identify these things!)
I believe that by doing so we can have a better working environment that allows us to onboard new projects faster and more safely making sure that no regression bugs are introduced.
Please help me figure out if this makes sense and how this idea can be improved anyhow!
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
Based on how the BDJuno repository is currently organized, when a new projects needs to have official BigDipper support we have to perform the following operations:
v2/cosmos/stargate
orv2/cosmos/v0.44.x
to create a custom BDJuno branch for the new projectAlso, each time something is fixed inside either one of the two main branches (
v2/cosmos/stargate
orv2/cosmos/v0.44.x
) we have to:This has become an incredibly complicated work to be done, since it requires the knowledge of many different things such as where are the BDJuno instance deployed?, should I also updated Hasura?, etc. For this reason, onboarding new projects inside BDJuno has become increasingly harder to do and it will become the main blocking problem in the future.
Fortunately, as it might be easy to understand, all these tasks can be automated using a Continuous Deployment (CD) setup. Particularly, I think that we should now focus on creating an environment that performs the following tasks for us based on a configuration that we provide it (and we should design):
I believe that by doing so we can have a better working environment that allows us to onboard new projects faster and more safely making sure that no regression bugs are introduced.
Please help me figure out if this makes sense and how this idea can be improved anyhow!
Beta Was this translation helpful? Give feedback.
All reactions