Practices while releasing the python/ruby/script b

问题:

I am purely a windows programmer and spend all my time hacking VC++.

Recently I have been heading several web based applications and myself built applications with python (/pylons framework) and doing projects on rails. All the web projects are hosted on ubuntu linux.

The RELEASE procedures and check list we followed for building and releasing VC++ windows application are merely no more useful when it comes to script based language.

So we don't built any binaries now. I copied asp/php files into IIS folder through ftp server when using open source cms applications.

So FTP is the one of the way to host the files to the web server. Now we feel lazy or not so passionate to copy files via ftp instead we use the SVN checkout and we simply do svn update to get the latest copy.

Is SVN checkout and svn update are the right methods to update the latest build files into the server? Are there any downside in using svn update? Any better method to release the script/web based scripts into the production server?

PS: I have used ssh server at some extension on linux platform.

回答1:

I would create a branch in SVN for every release of web application and when the release is ready there, I would check it out on the server and set to be run or move it into the place of the old version.

回答2:

Is SVN checkout and svn update are the right methods to update the latest build files into the server?

Very, very good methods. You know what you got. You can go backwards at any time.

Are there any downside in using svn update? None.

Any better method to release the script/web based scripts into the production server?

What we do.

We do not run out of the SVN checkout directories. The SVN checkout directory is "raw" source sitting on the server.

We use Python's setup.py install to create the application in /opt/app/app-x.y directory tree. Each tagged SVN branch is also a branch in the final installation.

Ruby has gems and other installation tools that are probably similar to Python's.

Our web site's Apache and mod_wsgi configurations refer to a specific /opt/app/app-x.y version. We can then stage a version, do testing, do things like migrate data from production to the next release, and generally get ready.

Then we adjust our Apache and mod_wsgi configuration to use the next version.

Previous versions are all in place. And left in place. We'll delete them some day when they confuse us.

回答3:

The one downside of doing an svn update on your web root is that the .svn directories can potentially be made public, so be careful about permissions on the web server.

That said, there are far better ways to deploy an app built with dynamic languages. In the Rails world Capistrano is a mature deployment tool, as well as Vlad the Deployer. Capistrano can easily be used for non-rails deployments

There are many deployment strategies based on version control. You could go through the tutorials and get some ideas.

I'd also like to add that even though we do not "build" (compile) the project in dynamic languages, we do "build" (test/integration) them. A serious project would use a continuous integration server to validate the integrated "build" of project on every commit or integration, well before it gets to production.

回答4:

One downside of doing an svn update: though you can go back in time, to what revision do you go back to? You have to look it up. svn update pseudo-deployments work much cleaner if you use tags - in that case you'd be doing an svn switch to a different tag, not an svn update on the same branch or the trunk.

You want to tag your software with the version number something like 1.1.4 , and then have a simple script to zip it up application-1.1.4,zip, and deploy it - then you have automated repeatable releases and rollbacks as well as greater visibility into what is changing between releases.