Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

We have three developers, one system administrator, and an artist that primarily work on a single website (forum) on our spare time to consistently develop features for the forum (but there are other projects that we work on). Because our system administrator recently joined, we dropped managed hosting for a single server and decided to rent out two unmanaged servers (one for testing and the other for production).

In the old server, we simply used Git as a middleman for pushing updates from the non-unified developer team into the server without conflicting updates. Pull other developer updates. Push our own updates. Revert if something breaks.

Since we have two servers now, we plan to push updates to the development server and somehow have it push updates to the production server.

Developer(s) -> development server (bare) -> production server

We want to keep the repositories in the development server and the work tree of the web site on the production server (web server). Is there an efficient way to do this without pushing from the dev server to production? Is there a better workflow for two servers in general?

P.S. The development team consists of high school teenagers and some college kids that have never developed on teams for for-profit businesses.

share|improve this question
add comment

1 Answer

up vote 3 down vote accepted

What is probably easiest to do is:

  • Use Git on the development server and have a version running there corresponding to the current master (a checkout from the repository). Everyone can merge changes into this version and if it breaks, the development server breaks and it's clear that action is required.
  • The production server is a remote checkout from the development server. Whenever the development server is at a stable point (or ready to release a new version), just log into the production server and do a git pull.

This is easy because when something does go wrong, you can just revert the production server with a single git revert command.

Furthermore, you can automate this by creating a hook on the production server to automatically pull changes based on anything you define. How this works in your specific situation will depend on how your actual release process works. Personally, I would just update it manually (you can even create a simple script so you don't actually have to log into the production server), since it's just one command and you generally want to be there whenever you update a production server :)

Also: do remember to secure the production server so your repository files are not served by the web server. This is trivial and your system administrator can configure this.

share|improve this answer
    
We don't release any stable versions of updates since each of our developers acts independently of each other (they work on their own set of features for the website), so I was really looking for a way just to bridge the development server's repository to the production server's work tree. –  Gio Borje Apr 23 '11 at 19:26
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.