Interesting approach Jonathan - that sounds excellent will have to
give it a try.
At the moment. The method we use relies on symbolic links for rollback
for each app we have a symbolic link pointing to app_version/web. For
example:
/current - ./1.1/web
/1.1/web
/1.1/xyz
Where current is
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
Dont send me this mail
On Fri, Jul 10, 2009 at 12:34 PM, Frank Stelzer d...@bleedingmoon.de wrote:
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
hi guys!
I think it was a related thread back to February ...
http://groups.google.com/group/symfony-users/browse_thread/thread/9afe54ecbe901d2b/3df1d10481538ff3?hl=enlnk=gstq=deploy#3df1d10481538ff3
Alecs
On Fri, Jul 10, 2009 at 10:22 AM, swapana pawar pawarswap...@gmail.comwrote:
Dont send
To unsubscribe from this group, send a mail to
symfony-users+unsubscr...@googlegroups.com
On Fri, Jul 10, 2009 at 09:22, swapana pawarpawarswap...@gmail.com wrote:
Dont send me this mail
On Fri, Jul 10, 2009 at 12:34 PM, Frank Stelzer d...@bleedingmoon.de wrote:
Hi,
We have
no sorry dont send this ok
On Fri, Jul 10, 2009 at 1:20 PM, Alexandru-Emil Lupu
gang.al...@gmail.comwrote:
hi guys!
I think it was a related thread back to February ...
On Thu, 9 Jul 2009, Jonathan Wage wrote:
They are just ruby scripts :)
I know.
do this has existed for a long time, outside of symfony. I would recommend
using some existing best practice for deployment like the svn diff/patch and
capistrano approach.
I just wish there was something like
There hasn't been much talk about the database migrations here.
Are most people using the doctrine migrations functionality? I do
really like this tool for my small projects, but on larger
applications with databases from 10 - 100 GB of data, I'm much happier
with the performance of a direct DB
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
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
Why would you svn co and not svn export?
Gareth McCumskey 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
Hi cleve,
I also use SVN to deploy my project's (ähm currently only one :-))
I use svn propedit svn:ignore to ignore that files on commit and
commit that files as .dist as example: database.yml.dist
I use a self made script on my clients servers to update theier repos.
set the permissions and
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
*
Svn update is bad because it can fail half way through, if you have
connection problems it could die part way through and you are left with
broken code that is sometimes hard to fix quickly. Svn update is slow, so
even if it does finish, you have this period of time where the code is
throwing 500
I'm still in the latter stages of development, but my strategy is to
allow my deployment to easily rollback to the previous version and
avoid any mistakes in terms of SVN syncing.
I see it going something like this:
load desired svn tag in my development copy
smoke test development copy
disable
Good point. I have always worked with svn in the local network so svn
update was quite quick, but patching is even faster. Great suggestion,
thanks,
Pablo
On Thu, Jul 9, 2009 at 11:12 AM, Jonathan Wagejonw...@gmail.com wrote:
Svn update is bad because it can fail half way through, if you have
On Thu, 9 Jul 2009, Jonathan Wage wrote:
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.
I spent some time playing with Capistrano a long time ago but the
They are just ruby scripts :) You just write ruby code essentially to
automate some commands in to a script that can be invoked easily across lots
of machines.
Honestly, the deployment of something is not the job of symfony. The way to
do this has existed for a long time, outside of symfony. I
For me it's very important, to automate that task so a user can run the
complete upgrade without the need of my help.
The upgrade process should run on a unix (Mac/BSD/Linux) box, without
the requirement of ruby.
But using patches as you described, is something i have to implement.
Also i
You can write the scripts in PHP then instead of Ruby.
- Jon
On Thu, Jul 9, 2009 at 12:18 PM, Rene r...@pc-dummy.net wrote:
For me it's very important, to automate that task so a user can run the
complete upgrade without the need of my help.
The upgrade process should run on a unix
This is something that makes total sense. I do it all the time. Since
you are good with PHP, use it in command line to automate things
instead of struggling with Bash (which is not difficult but takes time
to learn the ins and outs) or other languages.
Pablo
On Thu, Jul 9, 2009 at 1:22 PM,
There are many methods for deployment. My preferred method is Cappistrano. My
reasons for this are:
Deploy to more than on server at a time
Use any SCM
Can carry out additional tasks before and after the deployment e.g. disable
the site, update database, run patches, clear cache, enable the site.
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?
I keep my project self-contained (including plugins and generated
artifacts) in a Git repo and deploy via Vlad (also a Ruby tool but
23 matches
Mail list logo
