Archived

Version Control in FME Server: Next Steps

Version Control is now in FME Server 2017.1

As of the FME 2017.1 release, we have added Version Control to FME Server as a technology preview. This means that while it’s not quite ready for prime time yet, it is available to take for a test run.

We’d like to call on anyone interested in this new feature and especially anyone who voted on any of the related ideas for this (definitely one of the more popular enhancement requests for FME with a total of 149 votes from 4 ideas!) to try this feature and let us know what you think.

Give us your feedback

We’re actively working on developing this new functionality and we want to hear from you!

What works? What doesn’t? Does it fit in with how you currently work with FME Server? Does it line up with how you would have pictured versioning in FME Server? The more context you provide, the better.

Please post your feedback as a comment back to this idea.

How do I work with this?

Simply turn on version control from the web interface. Once it’s configured, you can upload your workspaces to FME Server using the Publish to Server Wizard in Desktop. It will let you create new repositories to group your workspaces as you upload them. Once they are up there, you will be able to view and download past versions of your workspaces using FME Server’s web interface.

We’ve put together a video introduction for this new feature covering enabling versioning, viewing history, rolling back, connecting to remote git repositories, preserving history across FME Server upgrades and configuring security settings. Check it out here:

https://www.youtube.com/embed/4-XAm7_2O3c

For those who’d prefer the written word, check out the documentation:

https://docs.safe.com/fme/2017.1/html/FME_Server_Documentation/Content/WebUI/Version-Control.htm

I only have FME Desktop, can I try out Version Control too?

Yes, of course! You can download FME Server from our Trial Download Page and install it. If you’re only using FME Server for version control (and not for running workspaces), you can simply dismiss the Engine Licensing Dialog that appears when you open the web interface. Now, you can use FME Server as a central repository for your workspaces and take advantage of other benefits such as easier sharing and collaboration. You’re free to keep using FME Server like this for as long as you want for all your workspace management tasks.

Show first post

This post is closed to further activity.
It may be an old question, an answered question, an implemented idea, or a notification-only post.
Please check post dates before relying on any information in a question or answer.
For follow-up or related questions, please post a new question or idea.
If there is a genuine update to be made, please contact us and request that the post is reopened.

1
2

Forum|pagination.label 2 / 2

smol
Contributor
Forum|Forum|4 years ago
August 17, 2021

To give some feedback about this and share my ideas on this.

We have been looking at supporting release cycles with version control in the last year. For us, the above feature did not fully align with our setup. We use FME Workbenches as a service for our public-facing services, which means the workbenches are very much coupled to these consuming services. This means it is quite important for us to keep in sync with the release cycles of our applications.

Our applications use git with CI/CD to manage the release cycles, and thus makes it is quite important to let the coupled FME workbenches follow this same principle. Luckily this was possible for us by using the FME API to update the workbenches in a release pipeline. This works perfectly as we can also let all the workbenches stay within the same application repository and falls in line with our idea of "horizontal repositories" (repo containing all its dependencies) with embedded FME team members. But I can imagine this can become better out of the box.

So this works quite okay for us for the Workbenches and even the FME Transformers. There are however many more settings/entities that are not defined as code at all as they are not related to FME Desktop. Think about App Servers, Schedule definitions, Automations, etc. Many of these definitions are also dependent on a git-based release cycle and it is currently very hard to keep these in sync. A possibility is to trigger (API) FME Projects migrations through a release pipeline, but this can be improved to have a git-first approach.

The above post is an FME -> Git approach, but I would advocate to (also) have a Git -> FME approach mainly so things are explicitly peer-reviewed first and fall under the Git version control.

Upvote

1
2

Forum|pagination.label 2 / 2

Version Control in FME Server: Next Steps

Version Control is now in FME Server 2017.1

Give us your feedback

How do I work with this?

I only have FME Desktop, can I try out Version Control too?

26 replies

Community Stats

Version Control is now in FME Server 2017.1

Give us your feedback

How do I work with this?

I only have FME Desktop, can I try out Version Control too?

Community Stats

Sign up

An FME Account is required to contribute

Login to the community

An FME Account is required to contribute

Scanning file for viruses.

This file cannot be downloaded