The list in tab “Spaces” now has buttons for reloading the list of tasks in spaces without restarting the Server. This enables promotion of tasks from one space (e.g. “dev”) to another (e.g. “prod”) using a version control system such as git or simply by copying the respective XML files from one space to another. After copying/promotion, press the “Reload tasks” button to make the Server use the updated task definitions in the space.
no plans for that. I would suggest making a Server task for copying tasks from one space to another. Such a task can be triggered from the Server UI, or using ems-cmd, or using the “EasyMorph Server command” action.
I find your suggestion of using git very interesting. I use it for my EasyMorph flows development but not for tasks on EM-server.
How can we use git for migrating the tasks between spaces ? I suppose the following workflow:
create a git repo in the easymorph server space where the task XML-files reside. Does the .git folder create problems for task execution ?
Pull the latest version in the target space to get all tasks in the target space en then press the hot-reload tasks button.
How can we also automate the overwrite of parameter values. For example we have a database parameter that we have to overwrite in the production environment. We also have a lot of other params that we have to overwrite when moving to prod. So my question: when we pull a new version of the tasks with git, it will have the param values from dev and we would like to automatically overwrite them with the prod values.
One idea that comes to my mind is that we could create 1 parameter ‘environment’ and all other parameters are calculated parameters that change as a function of the parameter ‘environment’. When we want to apply this to our current tasks, we have to change all our parameters to calculated params. So that’s quite a workload…
Any suggestions ?
That shouldn't be a problem. It if becomes a problem, we'll fix that.
If you need to specify environment-specific variables via parameters, consider using the "Shared memory" instead of task parameters. The Shared Memory is a more appropriate place to store environment-specific settings.
Thanks for the response. How should we use the shared memory exactly to change the database connection from DEV to PROD for instance ?
Do you mean something like the example below?
Here I created under a specific key “development” 3 values for db connections.
I list the keys using a parameter called “environment”.
Then I removed the first item in the key path so that it works in other environments.
Finally I use the values to pass them to the module that needs to run.
So with this approach, one could move from dev to prod by just switching 1 parameter “environment”.
For example when I change the parameter to production, I get:
Recall a value from the shared memory using the “Shared memory” action. Then use the “first column value” mode to use it in action properties.
As a general solution compatible with your current parameters, you can create a new start module that will pull values from the shared memory and then call the current start module with the “Call” action and assign its parameters with values from the shared memory.
Notice that you can put several actions “Shared memory: Recall” one after another and each of them will add a new column.
A suggestion: currently it is not possible to add a comment with each key/value pair. In parameters we can write a comment to remember ourselves what the purpose of the parameter is. Maybe a comment field for the shared memory could be handy. When we will use this as environment variables, we will need this I guess.
