0

Which pipeline configuration files should we (not) commit to version control?

We are getting started with Shotgun configuration and would like to store our studio configuration in version control. Our current plan is:

  • production version is stored on network drive A
  • staging/testing version is stored on network drive B
  • we will deploy from B to A using tank
  • we will make/test changes locally and push them to B using Git
  • so every developer will have access to the production config, the staging config and their own working copies (Git branches)

 

Assuming this is a sane approach, which files should we definitely be putting into Git, and which should we definitely *not*? For example, I've noticed there are lots of binaries in the install folder. We wouldn't normally put binaries in Git, but if tank doesn't automagically update these on deployment, we probably need to.

We would like developers to be able to switch between all three stages (production, staging, working) via Shotgun Desktop. This suggests that any stage-specific files should not be in version control? Which files are these?

Thanks!

5 comments

  • 0
    Avatar
    Permanently deleted user

    Hey!

    This sounds like a great approach - the install folder is just a cache where toolkit stores the code payload. The actual configuration data is in the config subfolder in the toolkit config bundle. 

    We have some documentation explaining the basics here: https://support.shotgunsoftware.com/entries/95441337#A%20studio%20configuration%20in%20git%20source%20control

    I suggest starting to take a look there and ping us via support or forums if you have any questions!

    Thanks!

  • 0
    Avatar
    David Rix

    Thanks for the confirmation. The link makes it very clear, including the discussion in the comments.

    Since we have a combined studio-and-project pipeline configuration, with a structure of:

    • cache
    • config
    • install
    • tank.bat

    ...it sounds like we only need to keep the "config" folder in Git, not "cache" or "install", ignore config/core/install_location.yml and config/core/pipeline_configuration.yml, and run `tank cache_apps` after a Git pull.

    And for the next project, start with an empty Git folder as you and KP suggest in the linked comments.

  • 0
    Avatar
    David Rix

    Ah, except this means we can't store "manual" apps (because they live only in the "install" folder). Instead we'd have to store them externally as "git" apps (locally hosted, or hosted on GitHub).

  • 0
    Avatar
    Permanently deleted user

    Yep, this is something that advanced clients sometimes run into - you could use a dev descriptor (see https://support.shotgunsoftware.com/entries/95442678#Apps%20in%20the%20local%20file%20system) - but it's not great because you are using it for real setup, not for dev. There is a missing descriptor type here, at some point we need to add something to make it easier for advanced clients such as yourself to manage configs without using git. 

  • 0
    Avatar
    David Rix

    Actually, this suits us just fine (we'd prefer things in Git to aid development and rollout). It looks like "dev" is well-suited for pre-rollout development and testing on a dev machine.

Please sign in to leave a comment.