Good practice on versionning App Resources, Preferences, Queries?

Hi there,

I’d be happy to hear from other SI manager:

  • whether you do version Specify-7 resource files? what do you put under versioning?
  • how do you organize your git repository?
  • what is your workflow for commiting changes?

By resource files, I mean App Resources, Global/remote preferences, docker compose file, queries, etc.

Thanks for sharing your good practice! :nerd_face:
Philippe V.

1 Like

When I started, I thought about managing all the resources through git, but it was one of those moments where it was more hassle than it is worth (especially since the introduction of the visual editor). To version control with git, I would have to do a lot of copying and pasting between the text editor on my machine, and the web interface. This is coming from someone who uses git for almost everything else, so I think there are 2 reasons why git never stuck in this case:

  1. There isn’t a lot of thought that needs to go into the xml forms, it’s not like coding where you could have a moment of brilliance but never be able to replicate it again another day. If the whole xml was to disappear, could probably recreate in half a day. Tedious and boring, but not complex.
  2. The collaboration naturally happens through a mechanism not git related. As opposed to contributors all pushing to a repo, the software builds from the xml entered in the web gui, not a repo. Sure, everyone could be asked to first push their changes to the repo, but since that is a manual and unnecessary process, people (including myself) would forget to do it one time, and then the whole thing is out of sync anyways.

The current workflow is to copy the current xml to a text file somewhere while making changes. Once I’ve hit save and verified that everything is working properly, that’s it. The only reason the text file is there is so that if something is wrong, can “restore from backup” in about 10 seconds. Most changes are marginal, adding or subtracting a field, not large.

Maybe this will change down the line. In my head the risks of not using git are:

  1. Loss of xml data. If the database is losing data then I think there are bigger problems to worry about, and would likely be restoring from backup anyways. The only case in which git would save you is if only the xml files were affected by the data loss.

Not sure if this counts as good practice, but it is a practice that saves some time, and maybe that counts for something!


Docker compose files are the one exception to the above, because those would be part of a codebase.

EDIT: Perhaps there is a world in which you could use the APIs to manage all these resource and thus have the application reflect changes to a repo and never use the web gui at all. Sounds very cool but also a whole lot of added complexity.

3 Likes

I suggest a folder structure like shown here:

Notice that it addresses different form views based on the user type.

If you are starting from an existing database, then you will want to export the OOTB [out-of-the-box] version of the form and commit that to the git repository first. Then you can overwrite that version of the OOTB form with your custom form which you need to export out of the database. Then a good git tool will show the differences. You may have different form views based on managers, full access, guests, etc…

I also like to export picklists and schemas and maintain them in the git repo.

I think it is a good practice to pull these things into GIT, however the users of the system have the ability to edit the schema and the forms right within S7, so I think Specify probably should integrate versioning into their software or mandate that the changes get pulled in via GIT. Otherwise as a system admin it is going to be very hard to keep the forms current between git and what the admin users do.

Git is really helpful for if you, as a developer, do custom form enhancements for the database and release them to your customers. At that point in time you would be pulling down their “current” version, committing it into your repo, and then building on it.

Putting detailed notes into the schema fields when they get allocated for use is also helpful. I like to put: Date / Name + Email of editor / Name + email of customer that approved the change / Purpose of field.

2 Likes