Frequent Releases

(Not to be confused with SmallReleases.)

Isn't FrequentReleases a clarification of the intent for having SmallReleases?


On C3, we do not practice CodeOwnership. This means that developers can go very fast, since if they need something, they just implement it.

It also means that there is the potential that several developers will edit the same class. How do you manage that, C3?

Thanks for asking. We call our solution ContinuousIntegrationRelentlessTesting. Imagine how nice it would be if, the second that you made a correct change to the system, it appeared in everyone's config. Generally speaking, it would be transparent and everyone would always be in sync.

We accomplish this by each developer releasing his/her code to the config about once a day, more often if possible. ENVY warns us if we are about to release a version that isn't based on the one currently released: that means that someone has edited and released the class ahead of us. That's rare, but when it happens, we just integrate our changes into the new version. If it looks tricky, we get the previous editor to partner with us.

How do you avoid breaking things, C3?

But testing cannot find all defects, we all know that. How could this possibly work?

But wait a minute! Sometimes you have to break something in order to fix it. What about big changes that take a long time to get done?

Developers are encouraged to load the config frequently, at least daily. By doing this, they do small integrations often, avoiding the big integrations with their hard-to-find problems. Using this approach, integration is almost free.

But it seems that a fixed amount of integration has to be done. This is just spreading it out instead of doing it in a nice efficient batch.

Our development system is VisualWorks, while our production system is GemStone. We decided to make the two completely compatible: the entire system works in VW as well as in GS. When we first started production, we changed our process to run all the tests in GS as well as VW and then push the code. This was a mistake: the tests are so much slower in GS that developers would put off releasing until it was "worth it", and then would have a big integration bite to swallow.

So we changed the process. Now we release only to VW. Weekly we run all the UnitTests and FunctionalTests in GS, and then push the code. This works quite well. When it fails, it will fail because of an incompatibility between GS and VW: we fix the incompatibility, making the entire process more bulletproof.

This process all came about because we thought "wouldn't it be nice if everyone's image was always current with the best possible code", and then came up with a simple process that came as close as practical to that ideal. --RonJeffries


Another way through this is IncrementalIntegration


CategoryExtremeProgramming

EditText of this page (last edited November 9, 2004) or FindPage with title or text search