I see there’s already an Idea for providing the option for versioning Automations in FME Flow but the Idea was created 5 years ago and there doesn’t seem to have been any traction on it.
So, in the absence of any official support from Safe, what are people doing with regard to creating and saving versions of Automations?
Currently, if I make a change to an Automation but then need to revert that change there’s no way of doing it once it’s been saved.
The only workaround for this I can think of is to make a Project containing the Automation and then manually exporting the project (and saving it to a version control system) before making any changes to the Automation. The obvious problem with this is that it relies on:
remembering to export a Project before making any Automation changes
making sure the Project name is consistent (hard to do with multiple people editing)
There does not seem to be any System Event that is triggered on Automation change and no API call available for downloading an Automation (without using a Project), so automating this whole process seems challenging…
Best answer by virtualcitymatt
For me I have two (or maybe three) levels of version control, and in fact I use Projects to do it. But it’s 100% not practical and it’s certainly not fully automated.
For projects/products which need to be stable (e.g., priority 1) - I will only update an automation in production if it has gone through git. I make all the changes on a dev/test server (usually a local docker instance) - export the Project, extract (unzip) the components and then update/merge the components in my git repo where there have been changes.
I’ve tried to split up the components/dependencies as best as possible into their own projects but it does get a bit messy, especially when components are shared across multiple projects 🙈.
I use a gitlab build pipeline to do testing, handle versioning and to compile the fmeserver project(s) and then (optionally) update the production server.
I like the git option because you can review the changes made by others in a merge request. The down side is that the process takes time and FME Server projects are pretty sensitive/easy to break.
The 2nd level is much more lazy - just make changes (again on dev server), export the project and commit the fsproject to git directly and then manually deploy to production. This is for projects which are simple but we still need some place to keep track of changes of what were made.
The 3rd level is just a free for all and I hate it. But sometimes it’s just how it is.
I guess if I wanted to automate the automation version control I would probably be a via scheduled change detection process with the response automation from the API - then if a change was detected leverage the FME Server project to export it. It definitely has it’s pros and cons.
For me I have two (or maybe three) levels of version control, and in fact I use Projects to do it. But it’s 100% not practical and it’s certainly not fully automated.
For projects/products which need to be stable (e.g., priority 1) - I will only update an automation in production if it has gone through git. I make all the changes on a dev/test server (usually a local docker instance) - export the Project, extract (unzip) the components and then update/merge the components in my git repo where there have been changes.
I’ve tried to split up the components/dependencies as best as possible into their own projects but it does get a bit messy, especially when components are shared across multiple projects 🙈.
I use a gitlab build pipeline to do testing, handle versioning and to compile the fmeserver project(s) and then (optionally) update the production server.
I like the git option because you can review the changes made by others in a merge request. The down side is that the process takes time and FME Server projects are pretty sensitive/easy to break.
The 2nd level is much more lazy - just make changes (again on dev server), export the project and commit the fsproject to git directly and then manually deploy to production. This is for projects which are simple but we still need some place to keep track of changes of what were made.
The 3rd level is just a free for all and I hate it. But sometimes it’s just how it is.
I guess if I wanted to automate the automation version control I would probably be a via scheduled change detection process with the response automation from the API - then if a change was detected leverage the FME Server project to export it. It definitely has it’s pros and cons.
I guess what it boils down to is there is no simple solution with current versions of FME Flow. It would be great if Safe could take a look at this and provide some feedback, even better if this could receive some attention for a possible solution.
We use 3 different kinds of cookies. You can choose which cookies you want to accept. We need basic cookies to make this site work, therefore these are the minimum you can select. Learn more about our cookies.