CODEWITHSUNDEEP
gitdeploymentcapistranodevelopment-environmentenvironment
kayaker243
kayaker243

Reputation: 2638

Ignoring certain files and changes in capistrano's current directory for development environment

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?

Upvotes: 2

Views: 440

Answers (1)

Szymon Jeż
Szymon Jeż

Reputation: 8459

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?

Upvotes: 2

Related Questions