Recommendations to handle development and deployment of php web apps using shared project code

Question

I am wondering what the best way (for a lone developer) is to

1. develop a project that depends on code of other projects
2. deploy the resulting project to the server

I am planning to put my code in svn, and have shared code as a separate project. There are problems with svn:externals which I cannot fully estimate.

I've read

• subversion:externals considered to be an anti-pattern, and
• How do you organize your version control repository,

but there is one special thing with php-projects (and other interpreted source code): there is no final executable resulting from your libraries. External dependencies are thus always on raw source code.

Ideally I really want to be able to develop simultaneously on one project and the projects it dependends on.

Possible way: Check out a projects' dependency in a sub folder as a working copy of the trunk. Problems I foresee:

1. When you want to deploy a project, you might want to freeze its dependencies, right?

2. The dependency code should not end up as a duplicate in the projects repository, I think.

   *(update1: I additionally assume svn:ignore will pose problems if I cannot fall back on symlinks, see my comment)

   I am still looking for suggestions that do not require the use junction points. They are a sort of unsupported hack in winxp, which may break some programs*

This leads me to the last part of the question (as one has influence on the other): how do you deploy apps whith such dependencies? I've looked into BuildOut for Python, but it seems to be tightly related to the python ecosystem (resolving and fetching python modules from the web etc).

I am very eager to learn about your best practices.

Answer 1

One approach might be:

• one repository per dependency
• a requirements configuration file for your project which documents the dependencies and their versions (probably even your own versions of the dependencies)
• automation scripts that handle setup of the development, testing and deployment environments (can be as simple as documenting the setup procedure once and making it configurable and executable)

This has several benefits:

• you can easily (or even automatically) check whether your dependencies have become outdated (another better library is available), or have known security vulnerabilities.
• more awareness about dependencies
• easier to debug/fix/patch problems caused by dependencies
• ignoring svn:externals might also ease the pain when you switch to distributed version control like git, bzr, hg in the future.
• if you want to set up your environment on another machine (or eventually another developer takes over or joins) it will save you tons of time

Some KISS automation tools that are popular in web-development and server administration:

• fabric (python)
• buildout (python)
• capistrano (ruby)

Summary:

Document your requirements (preferably machine readable -> yaml, ini, json, xml) and handle dependencies outside of your project. It provides you with a bit of indirection which makes automated setup and deployment easier and less dependent on your version control system (separation of concerns, best tool for the job, etc).

Answer 2

This may sound cheap but I think I have a answer for you in this questions thread: http://stackoverflow.com/questions/3771373/svn-folder-structure-organization/3777709#3777709

As long as you stay within your own repository I wouldnt consider svn:externals as harmful as stated. Just don't overdo it.

Deployment with this strategy is also a piece of cake since it is ALL in one tag (checkout, run it, profit). Your directory structure remains the same on all layers, branches, tags, trunk.

By directing externals to tags (and making tags read-only on the svn server) you can be 100% sure you get the library you expect.