Question

Our deploy strategy: We have environment-scoped db config and .htaccess files (think prod.htaccess, dev.htaccess and local.htaccess). Deploys are done using capistrano, which starts with a checkout of the branch to be deployed, then deletes Capfile and out-of-scope .htaccess files and renames the in-scope htaccess from [env].htaccess to .htaccess. This complete, the repository/public_html directory is transferred via non-deleting rsync to the apache webroot.

Background: The company I work for is an online publication that’s
been around since 1998 and the deploy strategy is convoluted because
the folder structure is a mess: version-controlled files live next to
generated files and user-uploaded files. This being the case, we can’t
just symlink the entire apache webroot folder to the corresponding
folder in /current. Generated files would be wiped out on each time
a new deploy is made, the user uploaded files scattered about the
directories would have to be symlinked in from other places, etc. Thus
the non-deleting rsync operation.

The current insanity alluded to above is a question for another day, though.

What I want is a solution that doesn’t require the deleting and renaming of htaccess and db config files in the repo upon deploy. The reason is so that we can work in and commit from /deploy/current without having to contend with the tangle of local changes from the deploy.

What are the typical solutions for deployment of environment-scoped files like this? Should I move them to a /config folder above /public_html and symlink from apache webroot to the relevant files in /config depending on environment?

Answer 1

I would recommend you to approach this in the following way:

• Still keep all your [env].htaccess files in the repository.
• After deploy:update symlink all of your [env].htaccess files to .htaccess
  symlinks (ln --symbolic [env].htaccess .htaccess)
• Do not delete the *.htaccess files.
• Let the developers / sysops edit the *.htaccess files (they will have access to the in scope files via the .htaccess symlink and to all of the out of scope [env].htaccess files to.
• Let the developers / sysops commit right from the deploy/current folder (but be sure that it is valid repository from which you can commit.).
• Use this process for other types of files you work with.

I think this might solve the problem you described or at least ease it. I would personally start doing this like that and see how it will work out.

BTW Why do you delete the Capfile after deploy:update?