Multiple ignition projects

I currently switch between three or four projects daily, dedicating time to each. My current process involves backing up my gateway and then restoring the gateway for the next project. Repeating this four times a day makes me wonder if there's a more efficient method.

I maintain separate databases for each project to simplify deployment to customers, including tags and other details. By doing this, I can easily provide them with their specific backup. Is there a simpler method to switch between projects, or is it possibly to work on them simultaneously?

Yes. Virtual machines and/or docker containers. Per client gateway and database. Spin them up or down as you need, and work simultaneously on them. Consider configuring their network environments as similar to your clients' as possible, mimicing IP addresses and/or DNS (preferably the latter) so that client gateway backups can be dropped into the designated dev gateway and "just work".

Avoid installing any gateway directly on your development machine(s).

If you dedicate some hardware as permanent hypervisors, you can leave specific kit running for extended periods. It is really convenient to pick up where you left off with no delay, just resetting trial mode as needed.

4 Likes

What if we have the tag databases for each project isolated from each other on separate tag providers and save restore different projects so that the projects tag data bases don't step on to each other when we switch between projects? What other data gets stored uniquely in the gateway backup for each project? I think each project backup stores rest of the project data such as users info, their login credential etc in the project backup. This will save significant time of switching between different VMs or docker images or loading different gateway backups. Just want a brainstorming if it's possible at all and makes sense or a stupid idea.

However if its achievable then it will darstically simplify and make switching between multiple projects in development server a breeze.

1 Like

One problem I can think of is having to replace the tag provider names from the development server and the production server for each project. Even if there is an option to do a global substitution in tag database somehow, replacing the tag provider names in the designer would be a challenge.

Or may be have same tag provider names for each project between their production servers and development server, but unique for each project. Avoid any common tag provider names such as [Default] etc.

Are you able to access the tags from the docker container? this is something else i am curious about. if no is there a way to do this i would like to be able to test my tags from within the docker container.

I can access my data base by using this

jdbc:mysql://host.docker.internal:3306/