Shorter release cycle with DVCS

Does the choice of using a DVCS over a CVCS actually make for shorter release cycles? If so, what makes software release cycles shorter and what are the arguments for this?

Related to pull request? Does easier submission of patches play a role here?
Related to people factor? Are project teams that use CVCS act more conservative with release schedules?
Any other factors?

What makes software release cycle shorter with DVCS, compared to CVCS?

I don’t think there is necessarily a difference between DVCS and CVCS here, but rather a difference in the branching model that people adhere to.

From what I have gathered here and from my experience, people using DVCS tend to use more branches than people using CVCS. And if you develop each feature in a branch of its own, it is easier to start preparing a release with new feature X in it, but not feature Y, whose development has started but which is not yet ready for a release.

Everyone here seems to agree that projects using DVCS have shorter release cycles over all, but it’s still not certain that the adoption of a DVCS causes the shorter cycles: Correlation is not causation!

Distributed VCS and short release cycles are both relatively new technologies. Projects that embrace one are likely to embrace the other, while groups that prefer the tried and true, or that have a long-established workflow, will be more conservative and stick with CVCS and less frequent releases.

A better question to ask would be: “In what ways does use of a DVCS facilitate the short release cycle model?” This is what most of the answers are addressing, as a matter of fact. Using a DVCS doesn’t prevent anyone from having long release cycles; adopting short ones is a choice, and it involves development methodologies, branching models, code reviews, etc.– not just the VCS.

Good question!

The CVCS believe in the primary principle that everything must keep merging/syncing back to ‘the trunk’. Also, we expect that as we evolve, trunk should be the most stable points before release is made. So people put their work in working copy, take update and test before check-in. Or alternatively, you work on private/feature branches and then merge other trunk changes, test before you reintegrate.

The DVCS pattern can be significantly different. You keep branching and forking yourself. You may experiment, and then finally merge branches which make sense. Occasionally you heard of some security fix that must go out immediately, so you want that patch to be in your branch as well, but you don’t want many other stuff of trunk! So by default, you keep working in your space, keep taking and integrating things – and the time comes for release you all sit an decide what to take what to drop.

See this: http://nvie.com/posts/a-successful-git-branching-model/

So the essential difference is this: CVCS asks what mother says to their of young children -don’t go far away beyond a point where I can find you i.e. – keep synchronizing to trunk. The DVCS works assuming that all work is design to be independent unless there is explicit need to merge (e.g. creating a release).

Now coming to your question –

The above explanation actually sounds more contrary to what you observed/asked. The real challenge is, defining what is stable! when the number of user base is very large, and while people keep pouring their deltas – each of them might have counter breaking with respect to other parallel changes till everyone is settled to their individual best as well as the entire integration and dependencies are ok. So when you are trying to make release, one need to really shake things up, stop people from pouring new features – identify any integration issues when things merge up and so on. All this, implies that CVCS always ask you to take ‘release breaks’ between the development!

When number of contributors become large, getting to this point of ‘release breaks’ becomes difficult and fewer; and hence CVCS will actually force you to make ‘release creation festivals’ after a very significant one.

In DVCS – you keep working, testing, working testing on your own space. The release creation and integration is quite a parallel activity and it can also afford to do try and error by seeing what patch-sets work together and what won’t (hence will be taken or dropped from releases). In DVCS – you can decouple individual development and then once in a while just sneak in a release if that make sense.

What makes software release cycle shorter with DVCS, compared to CVCS?

I agree with Bart that the primary reason is the branching model used, but the type of version control system directly affects which branching models are viable. So we have two sub-questions. What branching model the distributed systems support better and why it makes release cycle faster?

The fundamental difference between centralized and distributed version control is, that without central authority you can’t enforce linear timeline. So to make distributed version control possible, these systems necessarily had to define history as directed acyclic graph, where each revision simply has unique identifier, one or more parent revisions and may have arbitrary many child revisions that you might not even be aware of, because you didn’t synchronize with the system where they were created yet.

It turns out that this approach lends itself very well to branching. You don’t have to do anything to get a branch, you simply always have one. So you can dive straight to work head first and leave deciding when and where to merge it or even where to keep it and under which name until you know whether it’s actually going the way you need.

In contrast all centralized systems maintain history as set of branches with linear sequence of revisions. So you have to decide in advance whether you’ll need a branch, give it a name and explicitly created it. This is quite pain in the butt when you don’t yet know what the idea is worth and you often simply don’t know that before you start programming. Complicated by the fact that in most centralized systems the branch names are global, significant, often persistent and not easily changed, while in all the major distributed systems they are just local monikers that can be changed at whim and recycled freely. And by the fact, that all the branching and merging operations are usually quite a bit slower in CVCS.

Thus DVCS makes branches easier and therefore teams using DVCS branches all the time while teams using CVCS will be avoiding them most of the time.

Now why using branches allows more frequent releases? Well, every team will underestimate a task now and then, often when hard to track bug appears. Teams using centralized systems usually do all debugging, and most development, on trunk, because branches are inconvenient. So they can’t release until they flushed out most bugs and they have to interleave development and debugging phases.

In contrast in distributed systems where all work is done on branches these can be merged together for test, tested, bugs fixed and only the work that passes tests merged separately to trunk. Resulting in trunk that has very few bugs and thus can be released more often, usually whenever an important feature lands.

It also helps that whenever there is a change in priorities, the work in progress can be trivially shelved with the branching approach used with distributed systems. In most real projects, changes in priorities happen all the time.

Filed under: softwareengineering - @ 23:27

Thẻ: cvcs, dvcs, release-management

Thiết kế website giá rẻ

Danh mục

Shorter release cycle with DVCS