A client has directed us to create separate projects for different sections of a facility. The Gateway’s projects are managed using a Git repo. So now we will start having two independent projects on the same Gateway and in the branches on the repo.
My concern was and is how we manage merging, testing, & deploying this and NOT causing issues (old revisions, missing code, etc.) in one project while deploying the other. The architecture decision is water under the bridge now. We just need a path forward on managing this.
Has anyone had experience doing this?
Any tips on handling the desperate projects in the various phases leading up to a deploy of one project or the other?
At what directory level is the root of your git repo(s)?
You can change this without losing existing history if you have a git guru handy, but it’s not for the faint of heart. Alternatively, you can change it and lose prior history if you just abandon the old git repo(s) and start new ones.
The repo is at the projects folder level. So all projects on the Gateway are part of the repo.
We’re not going to be allowed to change the structure based on the customer’s directives.
That would have been my choice, but unfortunately it was shot down.
I don’t think this should be too much of a headache. As far as commits go, Git won’t care about merging commits on different projects - they’ll safely apply over each other. The biggest problem will be testing & deploying at specific revisions. I’d recommend good discipline about tagging, so you can ‘know’ that a certain hash you’re using for testing/deployment is up to X version. If you’re using a Github et al, you can assign PRs to milestones, and keep those versions in sync with tag “versions” - that’s essentially what we do for Ignition itself.