Skip to main content

Hello,

I’m interested in starting a conversation regarding how version control in ETM is/has been approached by both IFS and customers using assystETM.

My intention is to broaden our understanding of how this issue has been approached by different users of assystETM, promote the sharing of community knowledge to use in our own organizations, and uncover or highlight areas where the tool is causing issues, thus promoting better ideas to IFS for improvement.

To help start the conversation and identify different viewpoints, I’ve prepared some questions to establish common ground.

General Questions:

  1. What needs does your organization have regarding version control of ETM channels and data mappers?
  2. How have you gone about implementing a solution that works for you?
  3. Did you find a way to implement the solution you envisioned?
  4. Were there specific features that you felt were missing?
  5. During or after implementation, did you identify any issues you were unable to work around?
  6. Did you uncover pitfalls or wish to share a cautionary tale specific to this attempted implementation?
  7. Using your implemented solution, did you end up feeling satisfied with the version control solution?

Using a Version Control System (VCS):

  1. Has anyone had any success implementing a version control system when working with assystETM?
    • Git (GitHub, GitLab, other git based solution?)
    • Apache Subversion (SVN)
    • Other VCS systems?
  2. Does your setup use automation, or are there manual export steps required to reflect changes?
  3. How do you support best practices such as:
    • Atomic commits and clear commit messages?
    • Code reviews (when developing new or making changes to existing integrations)?
    • Branching strategies (when re-using data mappers)?
    • Single source of truth (ETM portal or versioning system)?
    • Handling password and API-key management in data mappers?

These questions are by no means necessary to answer but are meant to prompt ideas and help establish common ground.

If there are questions that should be added, I welcome them all.

 

Thank you very much for your time, and I look forward to hearing from you all.

Best Regards, 

Richard

To start off this conversation, I would like to begin with our experience in this field.

 

Our need regarding version control is to have a shared repository where our main developer can keep a record of all the active channels and datamappers used in our production integrations. Ideally, this version control would be automatic, reflecting saved progress in a development ETM installation, while also serving as a library of commonly used code snippets during the development of datamappers.

 

Our attempt was to implement a version control solution using our local GitLab installation.
Unable to efficiently extract the saved progress, we resorted to manually exporting and uploading assystETM datamappers.

 

This solution, however, did not work as intended. We do not currently have a working version control system, as the attempted solution became too cumbersome to use (manual exports using ….net/assystETM/#/configimport → Export Configurations → Channels (with associated datamappers and message formats)).
The time and work between each commit did not provide the desired atomic commits with clear commit messages that we had hoped to achieve. The solution in its current form did not bring any worthwhile benefits due to the extra work required to manually export configurations.

 

There does not seem to be any functionality to automatically store a datamapper and/or channel configuration as a file that can then be synced using Git. There are also no version-specific fields in the Channel or datamapper that would allow for tracking the version in other ways than using a naming convention and/or remarks. Handling secrets in plain text when exported from datamappers is also an issue that we have yet to find a way around.

 

We encountered some problems due to certain REST APIs needing a custom header (http source, header 1) where API keys had to be stored, causing security issues, as our GitLab installation is open to more than just our team. This further decreased the usage of the version control system as manual sanitation became too burdensome.

 

While we are currently not actively working on this version control solution, we do wish to return to this issue once we have more experience with assystETM.

As our team grows and other users are permitted to use the ETM portal, such version control is something we see as a critical success factor if we are to succeed in developing maintainable integrations for our users.

 

I look forward to hearing from you all

 

Best regards,

Richard

Reply


Terms & ConditionsCookie settings