How to structure a VCS with multiple dependent projects

Question

I'm sure that this is a common issue that other have solved before so I'm calling on the collective wisdom of other developers/project managers out there for some help.

I've got a number of projects:

• Application
• WebApp
• ServerApp
• Dev Utils
• ORM

All of the apps/utils depend on the ORM: When the ORM changes, it needs to be compiled and all of the apps need to be re-compiled against it and then deployed. Right now my VCS structure is kind of a jumble:

• AppName
  • Trunk
    • Application
    • WebApp
    • ServerApp
    • Dev Utils (around 4 folders right now, but growing)
    • ORM
  • Relase
    • ProjectName (be it Application or WebApp) version.number
  • Branches
    • ExperimentName_DevName

Ideally, I'd like to have a root folder per application (Application/WebApp/ORM etc.), each with its own Trunk/Branches/Releases etc. to logically and physically separate them. My reasoning is that because lots of work gets done on the Application, and it gets released far more often, each release branch has identical copies of the same utils etc. Also checking out the Trunk to work on it always means that all of the other projects come along for the ride.

However, separating would mean ripping certain projects out of solutions and making modifying any projects simultaneously a pain - jumping between 2-3 IDEs (especially when making changes to the ORM).

I'm thinking about this because very soon I'm putting together a CI machine (be ready for questions about that in a week or so) and I'm trying to figure out a way to have the releases automatically created/deployed. Normally, just the Application gets deployed, via script copy to the server where all of the workstations pull from on startup, but like I said before, if the ORM changes/releases, all of the other apps should re-build and deploy.

(Today I broke our website and 3 utilities cause I changed the ORM and deployed it with an updated version of the Application, but forgot to rebuild/deploy the other apps with the new ORM - oops.)

Answer 1

Splitting up your code base into different "projects" can be very difficult. We have done this at each separately "deployable" boundary. Including a "platform" layer that is common/used by the others, as a separate project. But this isn't really perfect either.

The one thing that I cannot stress enough is that one needs to have some form of continuous regression/testing that runs after checkins and before you actually deploy anything. In addition a "release" process that might even involve some manual testing can be helpful and has definitely prevented a few egg on the face situations. (Better to release it a couple days late then broken.)

(Sorry to not directly address your problem)

Answer 2

Put yourself in your developer's shoes. This shouldn't be hard because it sounds like you're one of them :-) Look at your version control layout not from an architectural point of view, but from a usability point of view. Ask yourself: on a daily basis what are the most common things that we as developers do with our source code? Think specifically with regards to your interactions with your VCS system and the project layouts. You want to make the common things brain-dead easy. It's ok for the less common use cases to be harder to get to, as long as you have a record of how to do them, so that when (not if!) people forget, they'll know where to look to remind themselves how.

I've seen a lot of VCS layouts that try to be architecturally "perfect", but end up causing no end of hassles and headaches from a day-to-day usage point of view. I'm not saying the two can't coincide and mesh well together, I'm just saying think about it from the users point of view, and let that be your guide.

From a CI point of view, I'd still take this approach. Even if your setup ends up becoming more complex to define in your CI of choice, you only have to do the setup there once. If the layout is easy to use during development, most of your CI setup should also be relatively easy. You then just focus on the last bits that will take more time.