I'd like to improve my team's workflow and architecture.

Right now we have a LAMP dev server on which every member of the team has a subdirectory. We work directly in this directory via LAN. There is also a "release" directory for when we're ready to upload via FTP to the production server.

We use a github private repo that serves as a centralized repo.

Example of a programmer's current daily workflow :

Choose a user story to work on after a quick daily meeting Open a git branch named after the user story Work, commit some changes Push to github When I decide to deploy, I pull the changes, perform a code review, change the needed variables for production and upload via FTP. If changes were made to the dev database I replicate them on the production server's database as well.

Any ideas where I should begin to improve this situation ? Current issues :

  • Members of the team can't easily work from home since they'd have to edit on the dev server directly (lag issues)
  • Deployment process is awful (changing variables manually and FTPing to production)

EDIT : I'll try to add better questions.

  • Setting up subdirectories for each developer on a common dev server : good idea or not ? Possible alternative : each developer setups his own dev environment (using WAMP or similar) and pushes to test server.
  • For the deployment aspect I feel manually changing config variables and FTPing to production is a bad idea. Possible alternative : setting up git on production server, set config files in .gitignore (maintain them manually directly on production server) and git pushing the changes.
  • For remote developers, should they replicate the dev environment (again, WAMP or similar) but work on the dev server's database ? I think it's better than copying the database on local machines.
  • Do you have/want/need a test server? You have dev & production, but where do you do your testing? Commented Apr 5, 2013 at 15:51
  • I do the testing on my local machine (I'm the only one testing).
    – Lukmo
    Commented Apr 5, 2013 at 15:54
  • Been there, done that! Long term you're going to want more testing - more eyes to validate, perhaps some automated tests, etc. Probably not your first priority now, but something to think about. Commented Apr 5, 2013 at 16:00
  • 1
    What prevents devs from replicating the environment on a home machine? (@gnat is correct - you really haven't provided enough details for anyone to come up with a meaningful answer). Also, why specifically is your deployment process so painful and what parts don't you know how to fix? Commented Apr 5, 2013 at 16:03

1 Answer 1


Give each dev his own environment, doesn't matter if that's on a shared box or a local install (local installs do have many advantages though)

Next, get your server to build and automatically deploy to a test (or integration) environment. As commits are pushed on a dev branch, they get deployed to this central test environment so you can give it some testing preferably using automated tools.

Then get a similar setup to the test environment for the release branch - so when the code gets merged, it also gets deployed but to a more representative system. Typically the test and pre-production environments will start off the same, but the test one will end up with more cruft built up on it, the pre-prod should be much cleaner as only code that's merged onto the release branch will end up on it, with no 'experimental' code or rollbacks.

Configs - this is a standard SCM problem, I'd keep a separate area for the config for each environment (inc. production too) and store all versions in there, then pick the right one for whichever deployment is happening. Obviously you will need to script all this so it works correctly, and it can be a PiTA, but it seems you already have the necessary steps to perform for deploy, so just script them. I'd recommend Jenkins as a CI server which will help you with this if you don't want to code it directly in githooks.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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