Skip to main content
  • Home
  • Ideas
  • Version Control in FME Server: Next Steps
Archived

Version Control in FME Server: Next Steps

Related products:FME Flow
Show first post
This post is closed to further activity.
It may be a question with a best answer, an implemented idea, or just a post needing no comment.
If you have a follow-up or related question, 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.

26 replies

smol
Contributor
  • smolContributor
  • Contributor
  • 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.

Most helpful members this week

Community Stats

30,839
Posts
116,904
Replies
38,660
Members
Terms & ConditionsCookie settings

Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie settings
A product of
Safe Software respectfully acknowledges that we live, learn and work on the traditional and unceded territories of the Kwantlen, Katzie, and Semiahmoo First Nations.