AzureDevops - Azure Project Ignition Project/Repo Structure

General Discussion
21

In your setup, did you setup remote gateway connections between dev/test/prod at all, or are they each their own without knowledge of the other?

Each on their own. The active files on each server are the respective branch of the repo, and each project repo. So only working in Dev on my computer, the test server only pulls the test branch, the production environment only pulls Prod

When importing your tags for dev, do you change them all to memory or read-only so that if writes occur, they don’t affect the PLC?

yeah if connecting to a PLC I set them all read only and most of them disabled except for what I'm working on. I've made judicious use of UDTs which I think makes it easier. I can have a Dev UDT with everything disabled and then switch the type after.

Does your dev connect to same db as test?

yes, that might not be kosher to some but for us I don't see a problem with it and I would rather work with a copy of our real tables & data than some kind of pantomime.

To sync prod to dev pc, is it a gateway backup that you import?

Yep exactly - there's a nice option in the gateway settings to disable all connections on restore.

1 Like
22

now that we have 8.3 :raising_hands: - any suggestions for maintaining a ‘clean’ worktree at the gateway ‘root’ directory?

this is with a pretty heavily tweaked .gitignore:

image
image974×598 69.1 KB

pretty sure ignoring/purging some of these will break things/cause less-than-desirable behavior

haven’t tried redirecting wrapper to syslog yet.

also - why is config.idb still changing? haven’t diffed the contents yet, but curious.

[core]
	filemode = false
23

We’re actively working on updated guidance for version control with Ignition 8.3.. That will include some .gitignore resources that should be helpful in filtering out things that you don’t/shouldn’t need to track. However, I don’t think that keeping the entire data folder tracked is going to be necessary in most cases. I’d focus on more granular tracking of config resource collections (i.e. data/config/resources) and projects (data/projects).

1 Like
24

Thanks. FWIW my current use-case is for a non-containerized developer env repo (single clone) - intended to be as user-friendly/as few clicks as possible (on Windows)

Previously made use of recursively-cloned submodules (under the root repo - inclusive of data, etc) for ‘base’ projects. Suppose we could do that again but it muddied the water a bit.

comments/critiques are welcome

Would be nice if ignition would just create missing resources (like log/metrics.idb) instead of bailing