The quick-and-dirty method that I've used in most of the companies I work for was something like this:
- Put all the code in a versioning system (like SVN or something) so that all the developers have a single source of the files. You're obviously already doing this. Hurray!
- Put in the root of that code, a file named
setup_permissions.sh
which updates all the local environment stuff. This can include permissions, or whatever you need to run.
- Every morning, all the programmers do
svn update
, which updates the files, and also the setup_permissions.sh
.
- They try to run their code. See a problem. They run
setup_permissions.sh
.
- All is well in the world!
As for the contents of setup_permissions.sh
, it could be something like:
#/bin/sh
TMP=/tmp
mkdir $TMP/api
mkdir $TMP/email2sms
mkdir $TMP/scheduled_sending
mkdir $TMP/billing
chmod 777 -r $TMP/api $TMP/email2sms $TMP/scheduled_sending $TMP/billing
And add any more commands you feel you need.
(Oh, and don't use chmod 777
... it's a terrible idea. Just see this as an example.)
The key to this approach is discipline. You must trust your programmers to have the discipline to run the setup_permissions.sh
when they update their local environments . The same goes for whoever updates the production system.
You must also have the discipline to update setup_permissions
with any changes you make to the directory structure, and whatever permission change it needs - instead of just doing the changes manually on your computer, and leaving it at that. (And the same goes for all the other developers who make changes to the directory structure.)