Development setup for small team: handling assets

Question

We are a small team developing PHP applications in a LAN. Both on Mac and PC.

Individual developers check out and edit source code to their own machine, on which Apache is running. Local testing is then done over localhost.

For the DB, the application connects to a common MySQL installation, on a dedicated machine in the LAN. This works quite well because we rarely make (destructive) changes to the DB schema. This means that all the individual applications running access the same test data.

But uploaded files remain a problem: they are only uploaded to the dev's local machine, although a reference to them is stored in the central DB. This means that the other team members may be shown a broken link for a user uploaded image, that physically only exists on one devs local machine.

The ideal solution would be to have the entire persistance layer on a central machine. Any ideas on how best to achieve this?

Answer 1

i have dealt with this once and what i did was to use our NAS as the storage of everything. we developed our website on the NAS itself over FTP. it was like cloud development, IDE only on our side, every file we edited, image uploaded and so on was on the NAS. the website itself was also running on the NAS (since the NAS has the ability to be a server and have mySQL)

the NAS was turned from a network storage - to an actual local server.

---

By how I understood your question, i assumed you only needed to share uploaded resource (like images) and not develop in the same app at once.

First I suggest that you DON'T develop on the production machine at all.

Now, here are 2 ways you can do it though:

Modular Development:

you develop independently. You don't touch each other's code. you develop features separately from each other. that way, you won't be stepping into each other's shoes. this also promotes "loose coupling" which in le man's terms, "when one feature breaks, the other's won't"

you should check out this video on how you can break down your development into "modules". This is in JS though, but the architecture can still apply.

Version Controlled Development

Break your development into 3 layers:

• Production (aka Stable) is the code that is public. You don't develop or touch code here. You only publish the code only when it is tested thoroughly. Also, this is NOT the public server. this is just the public code. however, what lives here is the actual replica of the public site.

• Testing (aka Beta) is where you test your developed code. This system is for testing purposes only. You don't touch the code here either. You are just here to find bugs on your own. It's your "Quality Assurance Layer". This layer is also where your codes merge (discussed later)

• Development (aka Alpha) is where you touch your code. Here, you share your code, test it, break it, try new features as well as fix the bugs you found in Testing

as you can see, you don't break your systems due to overwriting, or broken links etc.

Now, your development strategy. Use a version system like GIT (distributed) or SVN(central) and create 3 branches according to the ones above. For this example, this uses a distributed approach (i prefer it)

Assign a "maintainer/ring master" in your group who consolidates your work and publishes it to testing. What this maintainer does is to collect your "finished" developed code and puts it into his testing branch. anyone can then clone his testing branch to your testing branch to test your code. Whatever bug they/you find, you refine in the development and submit it to him again. only after that feature is quality assured, then the maintainer can publish it to the stable where he clones it to the public server.

After all that's done and when you have moved on, you just clone the stable branch to your development branch and you start anew. Now you have a fresh canvas to play with.Overwriting is handled by the version control system, and the maintainer. you need not worry about that.

as for resources, you would not want to bog down your local development system with arriving resources from the public server. version control systems also have "ignore lists" to prevent you from cloning some resources. clone only what's necessary. if you are developing a weather widget, you only need images for weather widget. you don't need images from the other widgets (unless neccessary)

Answer 2

Basically you want some sort of shared filesystem. There are lots of options: a samba share, an NFS-mounted directory, Dropbox (or a similar service), etc. I would suggest looking into the available options to see what suits your infrastructure best.

Answer 3

Map a network folder or use a service like dropbox or similar. A local db is nice to have though and doesn't take up too much resources.