I think this deployment strategy is no longer appropriate. Rather than copying over from dev all files that may be .gitignored or otherwise uncommitted files, or files in the dev branch not yet pulled in to master, we should be downloading the git repo.
I say we either git rid of this deployment altogether, or we replace it with one where we deploy copy the first half of DEPLOY_SITE_UPDATES which downloads the latest version of the master github repo, copies over the auth files, and then replaces the production voteview server. This is going to be just as fast, basically, since we just replace rsync with wget (but that happens before the server goes down) and then the replacements are of equal size.
Therefore this should not increase server down time and should decrease the number of ways we do deployment by removing one that is bad form anyways because it deploys uncommitted, .gitignored files.
Unless anyone says otherwise, I'll implement this within a couple days.
I think this deployment strategy is no longer appropriate. Rather than copying over from dev all files that may be .gitignored or otherwise uncommitted files, or files in the dev branch not yet pulled in to master, we should be downloading the git repo.
I say we either git rid of this deployment altogether, or we replace it with one where we deploy copy the first half of DEPLOY_SITE_UPDATES which downloads the latest version of the master github repo, copies over the auth files, and then replaces the production voteview server. This is going to be just as fast, basically, since we just replace rsync with wget (but that happens before the server goes down) and then the replacements are of equal size.
Therefore this should not increase server down time and should decrease the number of ways we do deployment by removing one that is bad form anyways because it deploys uncommitted, .gitignored files.
Unless anyone says otherwise, I'll implement this within a couple days.