# Project Structure Management: Best practises **URL:** \ **Category:** Ignition\ **Tags:** ignition81, perspective\ **Created:** [January 26, 2024, 8:59am UTC](https://forum.inductiveautomation.com/t/project-structure-management-best-practises/84802 "2024-01-26T08:59:16Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![louagejasper](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/louagejasper/32/86311_2.png) [@louagejasper](https://forum.inductiveautomation.com/u/louagejasper)\ **Post date:** [January 26, 2024, 8:59am UTC](https://forum.inductiveautomation.com/t/project-structure-management-best-practises/84802/1 "2024-01-26T08:59:16Z")
Hi all, 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? ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [January 26, 2024, 1:57pm UTC](https://forum.inductiveautomation.com/t/project-structure-management-best-practises/84802/2 "2024-01-26T13:57:23Z")
An architecture to consider: > [@Where do/should Gateway Scripts live with respect to an inherited project structure?](https://forum.inductiveautomation.com/t/where-do-should-gateway-scripts-live-with-respect-to-an-inherited-project-structure/83460/3): > > Put all of the logic in project library scripts, in the "universe" project at the root of your hierarchy, if you must. Then, in leaf projects, use one-line calls to the appropriate logic from event scripts and message handlers. (I don't agree with your desire, but this is what you must do to achieve it.) I recommend you not put all your scripts (eggs) in one inheritable project (basket). I recommend a hierarchy something like this: universe ├bg\_common │├gsp │├background1 │├background2 │└we… Possibly expanded as described here: > [@Switching between Ignition Perspective projects](https://forum.inductiveautomation.com/t/switching-between-ignition-perspective-projects/83795/3): > > This strikes me as a really bad idea. Consider a chain of inheritable projects instead, if you must. Just make sure the projects closest to the root need no resources from projects further from the root. Consider the project hierarchy from this comment: For your case, replace perspective\_common with two or three resource projects in a chain, where the UI leaf projects inherit from the last one. Something like this, perhaps: └ui\_common ├perspective\_scripts │└perspective\_embeds │ └pers… 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.) ---
**Author:** ![louagejasper](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/louagejasper/32/86311_2.png) [@louagejasper](https://forum.inductiveautomation.com/u/louagejasper)\ **Post date:** [January 26, 2024, 3:31pm UTC](https://forum.inductiveautomation.com/t/project-structure-management-best-practises/84802/3 "2024-01-26T15:31:09Z")
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. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [January 26, 2024, 3:46pm UTC](https://forum.inductiveautomation.com/t/project-structure-management-best-practises/84802/4 "2024-01-26T15:46:53Z")
> [@louagejasper](#): > > having every Perspective view in 1 project? 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. ---
**Author:** ![louagejasper](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/louagejasper/32/86311_2.png) [@louagejasper](https://forum.inductiveautomation.com/u/louagejasper)\ **Post date:** [January 26, 2024, 4:09pm UTC](https://forum.inductiveautomation.com/t/project-structure-management-best-practises/84802/5 "2024-01-26T16:09:39Z")
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! ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [January 26, 2024, 4:16pm UTC](https://forum.inductiveautomation.com/t/project-structure-management-best-practises/84802/6 "2024-01-26T16:16:04Z")
> [@louagejasper](#): > > Do you like the approach of small standalone projects? 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.