2 台云服务器，1 台开发，1 台产品； 什么是好的部署过程？

Question

Currently using LAMP stack for my web app. My dev and prod are in the same cloud instance. Now I am getting a new instance and would like to move the dev/test environment to the new instance, separating it from the prod environment.

It used to be a simple Phing script that would do a SVN export into the prod directory (pointed to by my vhost.conf). How do I make a good build process now with the environments separated?

Thinking of transferring the SVN repository to the dev server and then doing a ssh+svn push (is this possible with Phing?)

What's the best/common practice for this type of setup?

More Info:

I'm currently using CodeIgniter for MVC framework, Phing for automated builds for localhost deployment. The web app is also supported by a few CRON scripts written in Java .

Update:

Ended up using Phing + Jenkins. Working well so far!

Answer 1

We use Phing for doing deployments similar to what you have described. We also use Symfony framework for our projects (which is not so much important for this but Symfony supports the concept of different environments so it's a plus).

However we still need to produce different configuration files for database, front controllers etc.

So we ended up having a folder with build.properties that define configuration for different environments (and in our case also for different clients we ship our product to). This folder is linked to the file structure using svn externals (again not necessary).

The Phing build.xml file then accept a property file as a parameter on the command line, takes the values from it and produces all necessary configuration files, controllers and other environment specific files. We store the configuration in template files and then use copy/filter feature in Phing to replace the placeholders in the templates with the specific values.

The whole task of configuring the given environment can then be as simple as something like this:

phing configure-environment -DpropertyFile=./build_properties/build.properties.prod

In your build file you check if the propertyFile property that specifies the properties file is defined and load the file using <property file="./build_properties/build.properties.prod" override="true" /> . Then you just do any magic with the values as you need.

You can still use your svn checkout/update and put all the resulting configuration files into svn ignore (you will have them generated by phing). We actually use additional steps in Phing. Those steps in the end produce a Linux shell installation self-deploy package. This is produced automatically in Jenkins. We then send the package to our clients or the support team can grab the package from Jenkins and they can do the whole deployment just by executing it (we still prefer manual deployments to production servers) or Jenkins can deploy it automatically (for example to test servers).

I'll be happy to write more info if needed.

Answer 2

I recommend using Capistrano (looks like they haven't updated the docs since they moved the site) and railsless-deploy for doing deployment. Eventually, you are probably going to need to add more app boxes and run other tasks as part of your deployment so choosing a framework that will support this can save you a lot of time in the future. I have used capistrano for two PHP deployments (one small and one large) and although its not perfect, it works well. It also handles all of the code checkout / update, moving symlinks into place, and rolling back if something goes wrong.

Once you have capistrano configured, all you have to do is something like:

cap dev deploy 
cap prod deploy

Another option that I have explored for doing this is fabric . Although I haven't used it, if I had to deploy a complex app again, I would consider it. The interface is simple and straightforward.

A third option you might take a look at thought its still in the early stages of development is gantry (pardon the self promoting). This is something I have been working on out of frustration with using capistrano to deploy a PHP application in an environment with a lot of moving pieces. Capistrano is great and works well for non PHP application deployments, but you still have to some poking around in the code to understand what is happening and tweak it to suit your needs. This is also why I suggest giving fabric a good look.

Answer 3

I use a similar config now. Lamp + SVN + codeigniter + prd and dev servers.

I run the svn repos on dev. I checkout the repos into the root folder of the dev domain. Then use a post-commit hook to update the root folder everytime any developer commits.

When we are happy and have fully tested the code I ssh into the prd server and rsync the dev root to the prd root.

Heres my solution for the different configs. Outside the root folder I have a config.ini file. I parse the file in my codeigniter constants.php script. This means that the prd and dev server can have separate settings without them ever being in the repos.

If you want help with post-commit, rsync and ini code let me know.