We have a customer that does quite allot in Ignition.
There is a dev-test-production setup and we have multiple departments using Ignition, using different projects, much focussed on showing data in dashboards.
Apart from that there are allot of smaller sub-projects that are managing production-critical processes and machines, so we keep those projects separated from the bigger ones, so they don't get influenced by parent-projects or anything.
I will elaborate what our painpoints are.
In the big projects, we try to keep things generic an reusable, resulting in a general lib-project. This lib-project is quite annoying at times, because when we want to deploy, all parallel projects must be ready to work with the updated version of the lib project. So it basically feels like one monolithic application on this part.
In the small standalone projects, the code is more manageable, even though there is allot of duplicate code across projects, but the annoying thing about allot of projects is that when navigating in Perspective across projects, the screen reloads like it's a new login, so the navigation is way less convenient.
I'm looking for some best practises in managing this structure and deploying projects. Does anyone has some good advice on this topic?
The key is to push well-tested resources towards the root of the hierarchy so they can be shared.
It can also be helpful to duplicate projects for development work, and then send the updated resources (via export...send to project) in a batch back to the original project. Similar to making git branches, but can be done with or without git. (Delete the duplicate project immediately after its resources are merged where intended.)
Those examples looks allot like the architecture we have right now, apart from all the ui being in one place at the most bottom project, that would actually improve one issue we have.
So handling UI, you would suggest having every Perspective view in 1 project? Right now we have our 'Library' containing as well scripts as low-level views containing charts and pid-elements.
Most of them. The well-tested ones. In an inheritable project. Have separate leaf projects (permanent ones) only to accommodate separate authentication requirements. Such leaf UI projects would have their own nav/dock views and scripts to limit their users to the desired content.
Note that a project duplicated for development can override inheritable resources as needed, and, after appropriate testing, send those resource back to the inheritable project.
Ok, thanks for your feedback. How do you handle small subprojects, where you want to move very fast and not be dependant on your big project? Do you like the approach of small standalone projects?
If anyone else has input on how they organise their projects, more input is always welcome!
Sounds like a maintenance nightmare. But maybe useful in niche cases. Most every project will have potentially re-usable material, and common material should end up in common.