Source control - managing Dev vs Production

I have our projects in Git and I’m trying to follow ‘best practices’ but there are a few things I’m tripped up on.

How do people handle things that are, by necessity, different in Dev vs. Production? We have some timer scripts that export data to a remote database for another system. If I disable them in Dev it will end up getting disabled in Production the next time code the dev branch is merged and promoted to production. Do you make the scripts ‘aware’ of their running environment to prevent them from sending errant data to the external target?

Another issue is selectively merging updated files from the dev branch to production. There are a number of resources, mostly resource.json files, that get changed any time a resource is opened in the designer and then a save is issued. I often open one resource just to look at it for reference and then close it. I then make a change to another resource and save the project, causing extra file changes. I’d rather not have all these unnecessary updates cluttering the commit for the feature I’m working on. Selectively merging in Git is a pain, and gets more cluttered over time. What do others do?

Thanks in advance!

I had a similar question a while back about making sure some scripts only run on production.

Yes, the gateway scripts I make have to meet some environment criteria as part of the first if condition to run. Basically the gist is you have a config.json file, or add environment variables, to both machines and read from that to see where you are running. Read through the thread to see how to do this.

I cannot help you with that second question unfortunately.

1 Like

For scripts which we need to keep in-sync on all servers, we put a line like this near the top:

ignition_gateway = system.tag.readBlocking(['[System]Gateway/SystemName'])[0].getValue()

Then, functionality can be keyed to only activate if on a specific hard-coded gateway name. This does mean you can’t change your gateway names as easily, but it’s a workable solution. Many of our scripts just log a message about what WOULD have been done when on the development server, which helps with testing while still not affecting customers.

I like some of the ideas in that thread that @bkarabinchak.psi linked to. More complicated to setup, but allows more controls than just looking at the gateway name.

As for saving/touching files you don’t want to, I have trained my muscle memory to only ever save by using Ctrl-Shift-S. This pops up a list of which things you want to save. Uncheck all the stuff you just looked at but don’t want to save, hit OK. If you reach a point where the only things left in that list are things you don’t want to save, cancel out of the save and use Ctrl-O and re-open the project and clear the leftover changes.

Incidentally, I really wish there was an option in Designer to change the Ctrl-S hotkey and save button on the menu bar to NOT be “save all” without a dialog box. I sometimes hit those by accident and have to go pick through the projects directory with git to undo things. If you’re careful, you can git checkout -- . in your projects directories to get rid of random unintended changes like that.

I like the robustness of using a local config file, but using the gateway name has the advantage of working in other places than just gateway scripts. If you execute a script in the designer or client that calls your global script for the json data it will look on your local machine, not on the gateway server. I guess if we have a consistent naming strategy the gateway name might be useful at least for the simple prod/dev check.

Actually, you could combine the two methods and setup one or more custom memory tags on all of your servers which contain the config controls for each server. Your scripts can then read those tags from any context and find out which features should be enabled/disabled. Also has the advantage of being part of the gateway backup but still not in the data directories under git.