How to manage source control changesets with multiple overlapping changes and daily rebuilds?

I am working at a company which uses cvs for version control.

We develop and maintain an online system involving around a hundred executables - which share large amounts of code, and a large number of supporting files.

We have a head branch, and live branches taken from the head branch. The live branches represen开发者_Python百科t major releases which are released about every three months.

In addition there are a numerous daily bug fixes which must be applied to both the live branch - so they can be take to the live environment immeadiatley, and merged back to the head branch, so they will be in the next major release.

Our most obvious difficulty is with the daily fixes. As we have many daily modifications there are always multiple changes on the testing environment. Often when the executables are rebuilt for one task, untested changes to shared code get included in the build and taken to the live environment.

It seems to me we need some tools to better manage changesets.

I'm not the person who does the builds, so I am hoping to find a straight forward process for managing this, as it will make it easier for me get the build manager interested in adopting it.

I think what you need is a change in repository layout. If I understand correctly, your repository looks like this:

Mainline
|
 -- Live branch January (v 1.0)
|
 -- Live branch April  (v 2.0)
|
 -- Live branch July  (v 3.0)

So each of the branches contains all your sites (hundreds) as well as folders for shared code.

There is no scientific way to exactly tell the chance of an error appearing after a release but lets have a look at the two most important factors:

• Number of code lines commited per time-unit. You can not / will not want to globaly change this as it is the developer's productivity output.
• Test-Coverage, aka how often gets code executed BEFORE beeing live and how much of your codebase is involved. This could easily be change by giving people more time to test before a release or by implementing automated tests. Its a ressources issue.

If your company neither wants to spend money on extra testing nor decrease release frequency (not neccessarily productivity!) you will indeed have to find a way to release less changes, effecively decreasing the number of changed lines of code per release. As a result of this insight, having all developers committing into the same branch and going live from there multiple times a day doesn't sound like a good idea, does it?

You want increased Isolation.

Isolation in most version controll systems is implemented by

1. Incrementing revision numbers per atomic commit
2. Branching

You could try to implement a solution that packs changes from multiple revisions into release-packages a bit like the version controll system "perforce" does it. I wouldn't do that though as branching is allmost allways easier. Keep the KISS principle in mind.

So how could branching help? You could try to Isolate change that have to go live today from changes that might have to go live tomorrow or next week.

Iteration Branches

Mainline
|
 -- Live branch July  (v 3.0)
    |
     -- Monday (may result in releases 3.0.1 - 3.0.5)
    |
     -- Thuesday (may result in releases 3.0.6 - 3.0.8)
    |
     -- Wednesday (may result in releases 3.0.9 - 3.0.14)

People need to spend more thought about "targeting" their changes to the right release but it could lead to not-so-urgent changes (especialy on shared/library code) staying longer OUTSIDE of a release and inside the live branch where by chance or systematic testing they could be discovered before going live (see factor test coverage). Additional merging down is required of course and sometimes cherrypicking of changes out of the live-branch into the daily-branch.

Now please dont take me too literaly with the daily branches. In my company we have 2-week iterations and for each iteration a release branch and it is enough overhead allready to maintain that branch.

Instead of isolating by day you could try to isolate by product/site.

Project Branches

Mainline
    |
     -- Live branch July  (v 3.0)
        |
         -- Mysite-A (released when something in A changed and only released to the destination of A)
        |
         -- Mysite-B
        |
         -- Mysite-C

In this scenario the code of the single site AND all needed shared code and libraries would reside in such a Site-branch. If shared code has to be altered for something to work within site A you only change the shared code in site A. You also merge the change down so anyone can catch up on your changes. Catching up cycles may be a lot longer than releases so the code has time to "ripe". In your deploy/build process you have to make sure that the shared code of site-A does NOT overwrite the shared code site-B uses of course. You are effectivly "forking" your shared code with all implication (incompatibility, overhead for integrating team-changes).

Once in a while there should be forced merges down to the live-branch (you might want to rename that then too) to integrate all changes that have been done on shared code. Your 3-month iteration will force you to that anyway I guess but you might find out that 3 months is too long for hassle-free integration.

The third approach is the most extrem.

Project & Iteration Branches

Mainline
    |
     -- Live branch July  (v 3.0)
        |
         -- Mysite-A 
            |
            -- Week 1
            |
            -- Week 2
            |
            -- Week 3
        |
         -- Mysite-B
            |
            -- Week 1
            |
            -- Week 2
            |
            -- Week 3
        |
         -- Mysite-C
            |
            -- Week 1
            |
            -- Week 2
            |
            -- Week 3

This certainly brings a huge ammount of overhead and potential headache if you are not paying attention. On the good side you can very accuratly deploy only the changes that are needed NOW for THIS Project/Site.

I hope this all gives you some ideas.

Applied source controll is alot about risk controll for increased product quality.

While the decision what level of quality your company wants to deliver might not be in your hands, knowing it will help you deciding what changes to suggest. Might turn out your customers are adequatly content with your quality and further efforts to increase it do not amortize.

Good luck. Christoph