3

We are using dotCloud, a virtual host, to run some of our apps. dotCloud deploys apps directly from a git repo, and reads a configuration file called dotcloud.yml from that repo to configure and run the stack.

We have two branches (one production, one staging) that are part of the same repo, and these push to separate dotCloud instances. There is a minor difference in the dotcloud.yml file to run each of these instances.

What is the best way to manage this dotcloud.yml file? Currently we simply make sure we're making sure the dotcloud.yml is correct on each branch, but it constantly gets overwritten as we merge changes from staging to master.

CharlesB
  • 86,532
  • 28
  • 194
  • 218
Newy
  • 38,977
  • 9
  • 43
  • 59

2 Answers2

1

You could:

  • version a dotcloud.yml.template
  • version a dotcloud.yml.value.prod and a dotcloud.yml.value.staging with the pertinent values for each environment.
  • version a smudge script in charge of building the right dotcloud.yml file (which wouldn't be versioned anymore) depending on dotCloud instance.

You would declare that smudge script as a filter content driver in a (also versioned) .gitattribute file:

filter driver

On any git checkout, the smudge script will be called and, if it recognized the dotcloud.yml.template content, will build the right dotcloud.yml file.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
1

You could:

  • add dotcloud.yml to .gitignore, have two separate files for staging and production (e.g. dotcloud.yml.staging and dotcloud.yml.production), both present in your git repository, setup a symlink dotcloud.yml → dotcloud.yml.production, and push with dotcloud push --rsync (the --rsync flag will override the push mechanism detection, and the rsync mechanism will kick in, instead of the git mechanism);
  • use the same dotcloud.yml file, but rely on a different mechanism (e.g. dotcloud var or a postinstall script) to switch between the production and staging behaviors.
jpetazzo
  • 14,874
  • 3
  • 43
  • 45