As we set up the EasyMorph Hub, We are trying to use best practices as outlined by your documentation. This includes each Space having its own default folder, and all of the Space's default folders having a common root folder, which will be the root for the source control. The Entra group that will have the most permissions on the Hub will be the ETL team. At the same time, we don't expect that group of people to access the VM (running the hub) directly. At this early stage, we think that will have access to the file system via the HUB. They will be promoting EasyMorph projects directly from their local computers to the VM via the EasyMorph software.
If I'm getting this all correct, I'm curious where commits/branches/merges of the source control fit into this workflow if the ETL dev doesn't access the VM (I expect a rollback to require a login to the VM). Can you get me started on how you see this being done within the best practices workflow you all have laid out?
Thanks!
I assume you are going to use git as the version control system. In this case:
- Put the common root folder under a git repository.
- ETL devs check out the repository on their local machines and have access to all public (default) folders of all spaces.
- ETL devs submit updated workflows by
git commit + git push
- Updating workflows on the Hub can be done in various ways. For instance:
- Create one more space for ETL devs with just one task that will do
git pull for the common root folder. That will update workflows in all spaces.
- Alternatively, if you need more granular updates, have separate tasks in that space that do
git pull in each space's public folder, respectively.
In this scenario, ETL devs develop workflows on their machines, push changes to git, and then trigger the Hub task to pull the changes from git. No remote access to the VM is required. ETL devs can even set up a local Launcher task to trigger the "git pull" Hub task remotely, for convenience.
If you need to roll back, you can also do it through git + git pull on the Hub.