Hi, We have a more complicated deployment process. Our requirements: - One svn server: S-SVN - One sync server: SVN-SYNC - dozens of web servers
* We have for every project a seperat checked out (and "installed") project on S-SVN. * This checkout is updated on every release * This fresh code is rsynced to our SVN-SYNC * SVN-SYNC does another rsync to the web servers * Every web server has fresh code now DB migrations aren't automated yet in our process. Am 09.07.2009 um 16:35 schrieb Jonathan Wage: > My deployment process is simple. Here is a sample deployment of some > changes. > > Note: This all assumes you are working on a production svn export > which is in sync with the tag 1.0.1. We will make some changes and > tag it as 1.0.2 and upgrade. > > * Open up file and make some changes > vi index.php > > * Commit those changes > svn commit index.php > > * Make a copy of your working branch to a new tag > svn copy http://domain.com/svn/branch/1.0 http://domain.com/svn/tags/1.0.2 > > * Diff the old tag with the new tag and save it as a patch > svn diff http://domain.com/svn/tags/1.0.1 http://domain.com/svn/tags/1.0.2 > > 1.0.1-1.0.2.diff > > * SCP the patch to production or where you need it > scp 1.0.1-1.0.2.diff jw...@domain.com:/var/www/domain.com/patches > > * SSH to production > ssh jw...@domain.com > > * Change directory to where code and patches are > cd /var/www/domain.com/symfony > > * Apply a dry run with the patch to make sure it applies > patch -p0 --dry-run < ../patches/1.0.1-1.0.2.diff > > * Apply patch > patch -p0 < ../patches/1.0.1-1.0.2.diff > > * Run doctrine migrations if any new ones exist > php symfony doctrine:migrate > > Now the above commands are all done manually but a lot of times I > just have simple capistrano scripts that do all this the same each > time with one command and a set of arguments. > > - Jon > > On Thu, Jul 9, 2009 at 9:09 AM, Gareth McCumskey > <gmccums...@gmail.com> wrote: > If you don't checkout the entire project into the web root directory > it doesn't matter if you leave the config files such as > databases.yml in the project directory as users have no access there > anyways. > > i.e. checkout like we have to /usr/local/project_name and not /var/ > www/. Then use Apache's VirtualHost settings to point to the correct > location. > > > On Thu, Jul 9, 2009 at 3:23 PM, cleve <cleve...@gmail.com> wrote: > > We're still using the symfony project sync, but an svn solution does > sound interesting. Few thoughts though... > > When you do an svn checkuot to the production server how do you leave > out the files you don't want like databases.yml etc > > Also what are advantages of using a checkout rather than export? > > Also do you tag every deployment in SVN then checkout from there or > just CO from the trunk and note the revision number - I could imagine > copying the whole project to a tag every time could be a bit over the > top when you're deploying daily. > > > John > > On Jul 9, 11:10 am, Gareth McCumskey <gmccums...@gmail.com> wrote: > > Well we are currently in Beta of a symfony development app and we > originally > > used the symfony deploy command as it seemed (at the time) the > easiest to > > use and allowed us to control when we update but it suffered from > a few > > drawbacks where we had to push our local copies to the remote > server and we > > could then be right in the middle of a fix for something else and > hence have > > "broken" features. > > > > We switched to doing an SVN checkout. THis allowed us to control > exactly > > what revision of our application was posted onto the Beta testing > server > > (which some select clients have access to) and the Beta testers > could also > > exactly define then which revision they were testing on making > diagnosing > > bugs easier. > > > > Not to mention that ssh'ing onto the Beta test server and doing an > svn up > > command was a lot easier than trying to rely on an rsync deploy... > at least > > for us. > > > > In addition, we keep a frozen copy of the project in SVN. This > means, > > obviously, we keep the application out of the web root directory > and rather > > use Apache VirtualHost support to point to our symfony web/ > directory. This > > means that we also have, at our disposal, the symfony command line > tool on > > the remote box if we need it, but securely kept away from end users. > > > > On Thu, Jul 9, 2009 at 11:53 AM, Bernhard Schussek > <bschus...@gmail.com>wrote: > > > > > > > > > > > > > Hi, > > > > > After an interesting discussion with Jon and Russ > > > (http://trac.symfony-project.org/ticket/6708) I would like to > open a > > > follow-up thread. > > > > > What are your strategies for initial application deployment and > for > > > delivering updates? Do you do a SVN checkout on the server or > use the > > > project:deploy task? If you are using Doctrine, do you always > write > > > migrations manually when making changes to the schema? What are > the > > > reasons why you chose your deployment strategy? > > > > > I'm hoping for interesting reads :-) > > > > > Bernhard > > > > -- > > Gareth McCumskeyhttp://garethmccumskey.blogspot.com > > twitter: @garethmcc > > > > > -- > Gareth McCumskey > > http://garethmccumskey.blogspot.com > twitter: @garethmcc > > > > > > -- > Jonathan H. Wage (+1 415 992 5468) > Open Source Software Developer & Evangelist > sensiolabs.com | jwage.com | doctrine-project.org | symfony- > project.org > > You can contact Jonathan about Doctrine, Symfony and Open-Source or > for training, consulting, application development, or business > related questions at jonathan.w...@sensio.com > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "symfony users" group. To post to this group, send email to symfony-users@googlegroups.com To unsubscribe from this group, send email to symfony-users+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/symfony-users?hl=en -~----------~----~----~----~------~----~------~--~---
