问题
In a project I am working on, we have an ongoing discussion amongst the dev team - should the production environment be deployed as a checkout from the SVN repository or as an export?
The development environment is obviously a checkout, since it is constantly updated. For the production, I'm personally for checking out the main trunk, since it makes future updates easier (just run svn update). However some of the devs are against it, as svn creates files with the group/owner and permissions of the svn process (this is on a linux OS, so those things matter), and also having the .svn directories on the production seem to them to be somewhat dirty.
Also, if it is a checkout - how do you push individual features to the production without including in-development code? do you use tags or branch out for each feature? any alternatives?
EDIT: I might not have been clear - one of the requirement is to be able to constantly be able to push fixes to the production environment. We want to avoid a complete build (which takes much longer than a simple update) just for pushing critical fixes.
回答1:
The Subversion FAQ seems to advocate deployment as a checkout, autoupdated with post-commit hook scripts. They prevent Apache from exporting .svn folders (probably a good idea) by adding the following in httpd.conf:
# Disallow browsing of Subversion working copy administrative dirs.
<DirectoryMatch "^/.*/\.svn/">
Order deny,allow
Deny from all
</DirectoryMatch>
I'm extremely new to svn myself, but maybe you could trigger a hook script when you create a new tag. That way, when you're ready to update the live site, you just commit your last changes to the trunk, create the new tag, and the script updates your live site with svn update.
回答2:
I've been struggling with this, and I think I finally decided on checkout. Yes, there is extra junk there, but...
- Export doesn't account for deleted files (unless your solution is to delete everything in the dir and THEN export, which I think is way worse). Checkout will remove deleted files.
- Checkout is faster. Period. Fewer files being updated means less down/transition time, and an export pulls down and overwrites EVERYTHING, not just files needing an update.
Not saying it'll work for everyone, but these two things influenced my decision. Best of luck with your decision.
回答3:
IMHO you should create a branch/tag where you have the (desired) subset of the dev env which you use for production. Someone should either maintain this manually or automatically using scripts. Then, you should export (rather than checkout). Incremental updates are a non-issue, unless you're changing files on your production environment and you don't want those files to be overwritten.
Just my $0.02
回答4:
No question - export.
You would not be making updates, so no reason to have a checkout. You would just be deploying junk out.
I would say any environment should be only an export; you only use checkout locally when you are developing. Of course we are also using build scripts, so updating the deployment is as simple as running the script.
As far as the in development code, create branches for any work being done. Only commit to the trunk when ready for deployment to the development environment.
回答5:
I would look into some deployment software like Capistrano (it's a ruby program)
I would personally use exporting a tagged copy of trunk instead of just exporting trunk if you are going to use be rolling your own solution or manually.
回答6:
I deploy it as a copy. Not manual, of course.
I use 'make' and 'checkinstall'. I create a small Makefile which uses the system command 'install' to copy all the needed files to the appropriate directories on the web server, and I have preinstall and postinstall shell scripts that will be run on the server.
When time for deployment comes, I just run 'checkinstall' which creates a package (RPM, DEB or TGZ, depending on which Linux distribution I target). I install it using regular tools provided by a Linux distribution package manager (rpm, dpkg, pkgtool). Of course, if you want to track dependencies as well, you can use yum, apt-get, etc.
It makes it really easy if you want to distribute a new version of your web app. to multiple target servers. And stuff like uninstall, reverting to an older version, etc. are very easy because you have a ready to use package for each version you deployed.
This might not fit your 'push often' strategy though if you use some stuff that needs compiling. However, for scripting stuff (like PHP that I do), creating a package (of about 300+ PHP files) takes about 20 seconds on my machine. And about as much to install it on any target system.
To separate the code 'for release' from the 'in-development' code, I use branching. With Git, it's really easy, since branching is cheap and fast.
回答7:
Personally I'm always in doubt about the solution of this problem, I prefer having no ".svn" directories around my production environment, it's very dirty but at the same time, export is very tedious with large web applications (especially if using some 3rd parties "components" like Extjs,FCKeditor etc..).
I think there are not "killer solutions" at this moment.
回答8:
let me see..... ln -s ? what can that be used for?
/var/www/www.my-prod-site.com/public/
/var/www/www.my-prod-site.com/builds/Rev 1/
/var/www/www.my-prod-site.com/builds/Rev 2/
/var/www/www.my-prod-site.com/builds/Rev 3/
/var/www/www.my-prod-site.com/builds/Rev 99/
svn export to your builds directorys...... copy any config files over from /public that is your symbolic link to your former release build, and then just shift the symbolic link from public to point to your new build directory. it takes less time offline than any of the things i have seen posted here, and it also makes going back WAY FASTER unless you fckp your db everytime by altering tables.
回答9:
Here are some opinions -
.svn files on production are dirty? If the .svn directories are intact and not corrupt, they are far from dirty, they are actually a lifesaver. For security, you can tell apache to prevent browsing them.
Checkout or export? my approach... I definitely use tags and branches - it is dangerous to attach a production server to trunk and pray that no one runs svn up just after someone commits faulty code into trunk to see what it does on DEV. I have a reusable tag (say _production and _staging) and at the beginning of my setup I checkout each one to the matching server. I then lockout all access to modify the contents of the live and staging server. Thereafter, the DEV server is tied to the trunk head. When code is stable enough for QA/staging, we create a tag and rename it to _staging to allow the staging server to sync to it (script runs 'svn up') whenever it sees changes to that tag. Once we are happy with _staging, we rename it to _production and that makes the code deploy to the live server. Alternatively, you can create tags/branches with different names and use 'svn switch URL' to point the server to a new tag/branch (fixed point). All the above make it very easy to deploy without downtime and if rollback is necessary, you can quickly rename the archived former tag or use 'svn switch OLD_URL' to immediately undo the new changes without worrying about each small file and line-changes.
Permissions & ownership If you understand and know what the permissions should be for the files, you can have your script run after each deployment to set the CHOWN and CHMOD to what you want it to be.
Fear vs Knowledge I have heard of many afraid people ruling out the presence of SVN on the production server. The opposite is actually very scary. How do you assure your product team and customers that the application will not collapse into a big pile or error messages without the ability to do dry-runs or 'svn status -u' to ensure that the deployment will modify just those files that need to change? checking the status allows me even know if anyone forced their way it and made a 'quick change' directly on the server - you know people tend to bypass rules for things that look quick to them.
Imaging there is an error on the live server? with .svn, you can identify the exact version it is sync'd to (svn info) and then check if it is true to that url (sv status -u). Then you can build an honest replica of that setup by checking-out the same tag/version to a sandbox server where you can safely troubleshoot.
回答10:
EXPORT
that's it. You don't have any good reason to put extra junk into production system.- You'll expose your source code
- If this is web application it's even worse, your visitors can download your source code, how cool is that! very open :)
来源：https://stackoverflow.com/questions/175056/svn-checkout-or-export-for-production-environment