On Thu, Mar 4, 2010 at 3:46 PM, Huan Truong <[email protected]> wrote: > Github, then untar -xzvf the tarball, then cp -R the untarred files to > the working production directory. It works but it's rather a boring job.
It sounds like you want a "continuous integration" system, such as http://buildbot.net/. Personally I've used mostly CruiseControl.NET, there also exist CruiseControl (implemented in Java) and tinderbox (an ancient system from Mozilla) and many others. The CI system's job is to notice when something changes in git, and respond by building, testing, deploying, and communicating about the results. > Definitely I don't want the .git directory in my production directory to > serve the users -- so creating a .git repo right in the public_html web > directory is not really a good idea... Normally my deployment scripts deal with this by selectively copying from the build outputs to the deployment target. The CI system would run (n)ant/rake/whatever and that build script would have a deployment target that knows to call scp/rsync/whatever. The build script is normally parameterized so that I can easily deploy to different targets depending on which branch I'm building; these parameter values can and should also be version-controlled (not necessarily in the same repo as the code you're building). HTH. Sean ----------------------------------------------------------------- To get off this list, send email to [email protected] with Subject: unsubscribe -----------------------------------------------------------------
