This forum is in READ-ONLY mode.
You can look around, but if you want to ask a new question, please use the new forum.
Home » support » symfony 1.3 and 1.4 » Git and release deployment
Git and release deployment [message #103179] Wed, 28 July 2010 12:25 Go to next message
pulse00  is currently offline pulse00
Messages: 25
Registered: June 2008
Junior Member
Hi all,

i'm wondering what strategies people use when deploying new releases of their webapps using some kind of version control (git in my case).

The reason i ask is because i would like to avoid errors for end users, which happened during our last deployment.

Here's the workflow:

- The production checkout is on a "master" branch
- A new feature has been developed on a "dev" branch
- The new feature contains some refactoring, which forces us to do some manual config file changes on the live server and rebuild the model. These 2 steps might take a couple of minutes
- When the feature is finished, it's merged over to the master branch
- Finally, on the production checkout, the master branch is updated from the repository.

Now until all the manual configuration steps have been done on the production server, anything that does not come from the cache might throw an error to the end user.

I guess there's not really a way to avoid this, because anything that has not been cached before the update, symfony will need to render, which might lead to errors.

Any strategies symfony/git users can recommend for this situtaion?

thanks!
Re: Git and release deployment [message #103184 is a reply to message #103179 ] Wed, 28 July 2010 12:40 Go to previous messageGo to next message
halfer  is currently offline halfer
Messages: 9535
Registered: January 2006
Location: West Midlands, UK
Faithful Member
I heard of something the other day which sounded like a good idea. Apparently the Rails deployment tool Capistrano does some magic, but it could easily be replaced with a shell script for PHP. We will start using "svn switch" in due course, so we are in a similar position to you.

However I am not sure why there are so many steps in your process. You should not need to make any manual changes on the live server - they should come entirely from the SCM command you use (svn for us, git for you).

One of the beauties of using svn switch is that manual changes (e.g. the paths to the symfony folders, environment settings in the front controllers) are preserved between changes. So, our process is:

* svn switch <new-version-uri>
* chmod -R ... (to fix broken permissions)
* run database changes script
* clear cache

This is all manual at the moment but hopefully will be automated soon. If we have db changes that will break something, we organise downtime.

OK, back to the Capistrano magic. What this does apparently is to do a checkout, and run the necessary database migrations, but it does it in a non-live folder. If everything goes OK, it changes the live web symlink to point to the new folder, deleting the old symlink. This means that if something goes wrong during the deployment, only database migrations need to be reversed, and the live system can carry on working.


Remember Palestine
Re: Git and release deployment [message #103188 is a reply to message #103184 ] Wed, 28 July 2010 13:51 Go to previous messageGo to next message
pulse00  is currently offline pulse00
Messages: 25
Registered: June 2008
Junior Member
halfer wrote on Wed, 28 July 2010 12:40

However I am not sure why there are so many steps in your process. You should not need to make any manual changes on the live server - they should come entirely from the SCM command you use (svn for us, git for you).

We have a development server where we test new features, and it needs some server specific settings in databases.yml and app.yml, so we moved those files out of the scm to update them manually if needed. Maybe there's a better solution for this, but i'm not sure how to implement server specific configuration files.

halfer wrote on Wed, 28 July 2010 12:40

OK, back to the Capistrano magic. What this does apparently is to do a checkout, and run the necessary database migrations, but it does it in a non-live folder. If everything goes OK, it changes the live web symlink to point to the new folder, deleting the old symlink. This means that if something goes wrong during the deployment, only database migrations need to be reversed, and the live system can carry on working.


That sounds like a pretty clean solution, i'll give this a try on our development server right away, thanks!
Re: Git and release deployment [message #103192 is a reply to message #103179 ] Wed, 28 July 2010 14:43 Go to previous messageGo to next message
halfer  is currently offline halfer
Messages: 9535
Registered: January 2006
Location: West Midlands, UK
Faithful Member
Ah, right - on the first issue, there is a way to do things better. You'll see in app.yml and in databases.yml that they both are environment aware. That is to say that a number of keys are part of the "all" environment, and others are for dev, test, prod etc.

So, all you need to do is to decide what environments you have (we have dev, uat and prod) and then put all of your server-specific stuff in each one. Things that do not change per environment can go in "all".

Then all you need to do is to change the environment in your front controller, and you don't have to do any other manual changes at all. With svn switch (and I dare say with the git equivalent) once you have made a change to a front controller, it is respected as a "local change" and will not be reverted during deployments.


Remember Palestine
Re: Git and release deployment [message #103196 is a reply to message #103192 ] Wed, 28 July 2010 15:32 Go to previous message
xplo  is currently offline xplo
Messages: 428
Registered: September 2008
Faithful Member
i deploy from windows env to linux server env with rsync.
i use rsync to deploy code source on the server :
.the server might not be able to connect to your svn/git repository
.rsync seems faster than svn (compress on the run) especially on the first run.
.does not put any unnecessary file on the server ( the .svn cached directories got way too many file )
.more control than svn on update if you want to ignore some file/directory like database.yml

a simple .bat file just run rsync then ssh symfony cc

Like halfer if i need db change i put downtime with the front controller index.php.
Anyway if you need to do manual code change on a live server you ll need a downtime, i dont see an alternative for this.
Previous Topic:Validate get params
Next Topic:how to use new plugins in symfony1.4
Goto Forum:
  

powered by FUDforum - copyright ©2001-2004 FUD Forum Bulletin Board Software