Tips on managing dependencies for a release?

Question

Our system comprises many .NET websites, class libraries, and a MSSQL database. We use SVN for source control and TeamCity to automatically build to a Test server.

Our team is normally working on 4 or 5 projects at a time. We try to lump many changes into a largish rollout every 2-4 weeks.

My problem is with keeping track of all the dependencies for a rollout. Example:

Website A cannot go live until we've rolled out Branch X of Class library B, built in turn against the Trunk of Class library C, which needs Config Updates Y and Z and Database Update D, which needs Migration Script E...

It gets even more complex - like making sure each developer's project is actually compatible with the others and are building against the same versions. Yes, this is a management issue as much as a technical issue.

Currently our non-optimal solution is:

• a whiteboard listing features that haven't gone live yet
• relying on our memory and intuition when planning the rollout, until we're pretty sure we've thought of everything...
• a dry-run on our Staging environment. It's a good indication but we're often not sure if Staging is 100% in sync with Live - part of the problem I'm hoping to solve.
• some amount of winging it on rollout day.

So far so good, minus a few close calls. But as our system grows, I'd like a more scientific release management system allowing for more flexibility, like being able to roll out a single change or bugfix on it's own, safe in the knowledge that it won't break anything else.

I'm guessing the best solution involves some sort of version numbering system, and perhaps using a project management tool. We're a start-up, so we're not too hot on religiously sticking to rigid processes, but we're happy to start, providing it doesn't add more overhead than it's worth.

I'd love to hear advice from other teams who have solved this problem.

Answer 1

It sounds like you already have a Continuos Integration Server in place, but do not make proper use of it. Part of the problem is you don't know which changes will end up in a release and which will not.

I assume all your projects are part of an encompassing project, for which a source control repository exists. As a first measure, you should try to separate your code under development vs. stable/to-be released code in branches. Set up Teamcity to make a full build of the stable branch regularly. If a set of changes is ready for release, the creator of the change should be responsible for merging them, together with all dependencies, in the stable branch. CI will tell you if everything went smooth or not. It is the idea of CI that you are "always ready for release".

You mentioned that there are several projects your team is constantly working on and they have certain interdependencies. This makes me a little suspicious:

• If the projects are interdependent, why are they separate? Even if they evolve at different speeds, do they really need to be separate?
• Do you consequently have different repositories for each project? This will make releasing really hard.
• Can dependencies be managed on a binary level? Or are there compile time dependencies?

In my experience, it is always easier to manage dependencies on binary level (simply upgrade a library in your project). On the other hand, I've never had the situation where unrelated projects depend on the same dll (which is an application in itself and not just a utility library or something). In this case, it's easier to manage dependencies on the source level.

At the end, a random thought: If you'd use a distributed versioning control system (such as git or mercurial), having all code in the same repository would be very easy. Each project can have its own branch, which is regularily updated with the latest changes from the master branch (forward integrate). When a change is complete, the project branch is merged back into the master branch (reverse integrate). The Windows team at Microsoft came up with this workflow.