Thank you for creating this guide!
I am currently working on a guide for a customer, but there is one issue with the repo I was hoping you and/or the IA team could clarify. Are the repos ok to fork (with/without attribution)? Since there is no license defined the repos are assumed proprietary by default. Adding an explicit license to the repos would also be appreciated!
Everything is free to use as you'd like. I'll add an MIT license for good measure.
Again, beginner here.
As I studied, I learned that Git is doing the version control mechanism, and Github is a repository hosting services for Git.
I understood that, Github is optional for single developer, but required for multiple developer.
As you may all knows, clients, companies, do not want to put resources on third party cloud.
Ideally, version control needs a dedicated server for repository hosting?
Do we have an option to self host this? What software similar to Github we can use?
No, hosting a git repository does not require Github, or any cloud service. It doesn't need anything more than a server with command line git and SSH installed. Git repo URLs for this look like git+ssh://user@somehost.somedomain:folderName, where the folder name is in the user's home directory. (This is what I do for my own business repos.)
Various open-source projects offer github-like web services, but that is all optional.
That make sense (as usual), since all you need is a storage and something that do the compare, which Git is already doing.
I have fundamental question, regarding setup of each developer machine's, segregation of each dev's codes, etc. but I will post it as soon as, I got the question right.
Thank you.
When using just git+ssh, the users should have SSH keys configured so that password login to the repo server is disabled. That also means the user names on the repo server do not have to correspond to actual users, though that is wise for any private repos. For shared repos, simply create a dedicated username for that repo, and set every desired user's public key in that account.
Thinking about it now.. Do you think, Git tool skills, is too much to acquire and maintain?
From experience, its very rare occasion or never, that we need to revert back to a version in the past, if necessary, we might only need to change few codes.
What we really need:
In an environment where each developer is working on its own use case.
It is a waste of time and effort (for dev and tester) if we miss to promote (to test env) the modified resources (views, named queries, project scripts).
Is there a way to detect which resource have changed?
I am thinking of a tool to compare before and after of gateway backup.
I find git to be extremely valuable. I don't revert very much, but stashing and patch splitting are often helpful. Most importantly, regular commits make a history that have really helped me when troubleshooting.
Git will be much more useful in v8.3, of course.
Loaded (& excellent) question... there is a learning curve (to developer & user alike) and might not be justifiable to a client that might be paying for it. However, after implemented & utilized, version-control always = 'worth it' in my book.
For many resources, a query of the audit log might be a quick way to see that something was modified (when and by whom).
I enrolled myself on online git courses.
The video instructor, was working on a single server. Where he do stuff like checkout and commit, and working directory (actual files use by applications lives) gets spawn and respawn.
How does this relates to a multi-machines environment, where each developer has its own machine, and we have 3 environments (Dev, Test, and Prod).
I assume there needs to be a dedicated git server?
I assume that, when a developer works on a feature, he needs to checkout from git server into his machine? In this case how does git maintain code on a different machine?
Finally, how do you deploy codes to the Dev, Test, and Prod server? Does these server has it own .git Folder?
Someone please put a light on this.
This is where CI/CD comes in -- the big q is what sort of code is generally changing and how you want to merge changes
We use this process in Sales Engineering to develop our internal applications. We have a team of developers working locally on their machines, all pointing up to a remote Github repo. This is where we handle PRs, reviews, etc. For applications that go through multiple environments, we create derived Ignition images that are pushed to a container registry. It is verified in Test before being pushed to Prod. If changes need to be made, we make them locally, merge it into the remote repo, then make another version with a new image to push to Test. This is one way to do it, but it's by no means the only way to do it.
You can also set scripts to run on any commit/push or specific tagged ones
Rather than github, use Download and install GitLab | GitLab if you want to selfhost
Thanks for the inputs..
I miss one important ingredient, that is part of the solution to my questions. - That is having a central git repository (with branches) where developers can push their code to.. and will act as main source of codes, to be deployed on ignition gateways.. - at least this is what I understand one workflow of using git.
Question:
If we replace/modify directly the files in ignition project folder. Does Ignition (including opened designer) updates on the fly? - is this a usual practice even, when using git?
The default scan rate is 5 minutes, but this can be changed in ignition.conf file. We typically update ours to 10 seconds. In the designer, you may need to merge changes by using the Update Project button.
I think I figured it out.. 
General git workflow.
Dev would update Dev's working directory and commit changes to Dev's local git repository. Push changes to Dev branch.
I would merge Dev Branch to Tst branch, only cherry picked (done) features.
Do a clone from Tst Branch to Tst working directory for testing.
If testing pass, merge Tst Branch to Prd Branch so on and so forth. else if test fail do the modification in Dev working directory-that is Dev's designer.
