I read here that source control can be used in Ignition 8.
All resources can now be tracked with industry standard source control tools, such as Git. Resources can be tracked individually, and changes to disk caused by source control operations (checkout, pull, etc) will be applied automatically to the running system.
I havent found any tutorials or documentation pages for setting this up. Are there currently any resources I can turn to for this?
Alternatively, I know that if I had access to the files I could set up source control myself. Where can I find the root folder for scripts?
Im certain this is a hot topic and has been answered already, but I've done searches and I cant find an answer to my question.
All project resources are located in the gateway installation directory (if you're on, say, Windows, this defaults to Program Files/Inductive Automation/Ignition/. From there, project resources are in /data/projects/. Each project will have a folder there, and all resources within that project are then separated into modules. Below each module is a folder structure representing the path that you see in the designer.
An individual resource is itself a folder, containing at minimum two files: a resource.json file that defines meta-information about the resource, and a data.bin file, which contains the direct Java serialization of the actual resource. Some resource types, but not all, have different representations; for instance, project scripts are directly encoded as code.py files, which are plain text, while Perspective views are their direct JSON representation.
As of right now, in Ignition 8.0.X, that's basically all the "source control" integration you get. Triggering commits, reverting, etc, is all an exercise for the user. In fact, you would probably need to write a custom module if you wanted to do on-demand "commits" every time a save was pushed from the gateway. But, if you just want to rely on a system like git to perform periodic commits (and safe resource rollback), you're set.
Future plans include, at minimum, scripting hooks to allow you to directly run commits and various other actions once you've configured a git or other VCS repository.
Thanks for this help - I added my entire projects folder to a repo to capture any project changes, I know the .resource folder gets recreated if it’s missing - any issues with one repo for all projects? so far seems to be working fine for me
No, the main thing is keeping track of things. Also, since my original post, we've added a project update scripting hook; it's pretty barebones at the moment, but you could use system.util.execute() to trigger a git commit on project update (theoretically).
I know this is a bit stale (~1 year), but I would love to know your workflow.
I have installed Git on our test/dev Gateway, and have initialized a repo in the C:\Program Files\Inductive Automation\Ignition\data\projects directory, which works as expected - on the server.
However, this is where I have questions. When thinking about developer experience, I would like for them to be able to access the repo from their machine, over a mapped drive perhaps, via Git Bash or whatever client they’d like to use. While this concept works, it is slow. How do you handle this?
Hi Scott - Actually never solved that, my workflow isn’t currently great, but we only have two people working on the project, and I solely handle the development pushes. I have git running on the projects directory and while I develop ‘locally’ I log into our server and commit changes to a development project, and then a production environment.
Thanks Tyler. We’re small as well, with 2-3 folks building projects.
I was hoping that we could use a share/mapping to access the server repo. While that is certainly doable, it is (understandably) slow. A simple ‘git status’ takes 20-30 seconds (20 projects, ~1300 files).
It would seem that there are a few options:
Connect to the server and handle the Git tasks manually (as you are)
Automate commits, as mentioned earlier in the thread, using the ‘project updated’ hook in conjunction with ‘system.util.execute()’. I could see doing something like ‘git add .’, ‘git commit -am “my comment”’, ‘git push’. However, I’m not sure how you would be able to provide a meaningful comment upon each save.
Access the repo ‘remotely’, as I was attempting to do, understanding that it might be slow.
Ssh into the target Gateway server. This seems to work well in concept.
IMO, #4 is the best option at this point (OpenSsh as we are on Windows), and is probably how I will proceed.
I was for your workflow are you running EAM? I am trying to work through this workflow also and I have one central EAM and then 20~ agents that are deployed with the MQTT transmission and local HMI’s for those sites. Right now all of our Twincat work and application work are done in Github already with great success.
We found that one repo did not work for our situation. However we have dozens of projects being worked on, so the one repo approach did not work. EAM started breaking down for deployment as our team got bigger as we did not have great visibility as to WHAT was deployed, only the when.
What we have just started implementing is discontinuing EAM and using Git and Azure DevOps to control deployment. We have a DEV/TEST/PROD environments for all projects. Ignition developers have access to a “toolbox” page with git status, and commit functions. Perspective then calls the git commands on the GW in the respective project folders. This triggers commits to Azure DevOps.
From there Azure DevOps takes over and we have dozens of options on how to process the commit. Some projects the commit forces a project push to other servers via a DevOps release, other project require a pull request and when the PR is opens and/or closed a release is created which is picked up by a DevOps release pipeline and pushed to the appropriate Ignition Gateway.
So far this works for projects, then we need to tackle a similar approach for tag and db schema deployments.
Thanks for the information, I guess the one thing that differs a little bit is that all of our agents are all running the same solution so its really more larger team working on one solution. I think as long as we have EAM updating the current folder for Prod/Dev/QA we should be fine as its only one main project then its dependencies should push down if they are inheriting. Maybe I am wrong…
Can someone please share any docs or video tutorials to start with the Azure DevOps in ignition? I checked one video, and I’m still not understanding how we can add the ignition to DevOps, and how to create the pipeline/ Architecture for this. Considering I would like to learn this from scratch, where do I start on this?
Some instructions might vary a bit, but its similar to this. Outside of setting up the scripts to export some of the gateway items, you just configure a repo on your projects folder in program files. We chose not to do the commit on save route though since when we are debugging there would be quite a few commits. We either do manual commits or just schedule it at an appropriate interval.
Thank you @grietveld . I looked into the same, my doubt which how to use it in a proper hierarchical way, it has been mentioned to do it in a manual method for images and gw-config, I want to learn this from scratch, any other sample videos or any sample structure you have for this.
because when I'm checking only limited info is available. Can you please help me with this?
Can u please provide a little more information on the same, how you have done it successfully and where do I need to start to have a good hierarchy and best ways to implement the same.
Have been doing some work on setting up a DevOps workflow for my companies projects, and it looks like there is an opensource Git Module now that also does the job of your perspective view in the Designer.
Figured I would add it to this thread as it is adjacently relevant for anyone else that finds their way here in the future.
