This thread holds interest to me too.
I’m interested in switching over to GIT based management of our pipeline configuration, but in all honesty I’ve found the documentation on the topic somewhat confusing.
I’d really appreciate a few specific pointers from you, based on our current setup;
- We have a ‘dummy’ project on our server; sgtk_dev
- It is a centralized project.
- We have pipeline configurations attached to this project (we do our dev under those configurations).
- Once dev is ready to push; we push_configuration back to the primary pipeline configuration on sgtk_dev.
- At this point, the only thing updated is our dummy (sgtk_dev) development project.
- The next step is bespoke;
- We run a windows batch file, per-project; literally copy+paste the pipeline config from our dummy project to the chosen production project.
- The above process makes date-stamped backups of all files prior to the copy. It is robust.
- All of our projects are created with the centralized setup method.
While this approach has worked really well, I wanted to see if there’s merit in shifting over to something different. For the long-term foreseeable future, only 2 people will touch the configuration, which is why I’ve settled on a bespoke, hand-crafted roll-out approach. I’m happy with the process generally speaking, as it is very quick to iterate code changes.
Also, by pushing per-project, it mitigates a system wide bug being introduced. Still, version control in the traditional sense has benefits that I’ve not leveraged in this workflow. I see a primary benefit in granular detail on code changes (which I simply don’t have).
If you can spare some thoughts it’d be great!