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.
4
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.