Question

I’d like to learn other people workflow when using either vcs or dvcs.

Please describe your strategy to handle the following tasks:

• Implement a feature
• Fixing bugs (during development and deployed app)
• Code Review
• Refactoring code (post code-review)
• Incorporate patches
• Releasing the newer version of your app (desktop, web, mobile, would you treat them differently?)

Feel free to organize your answer not grouped by the tasks but grouped by whatever you think is relevant but please organize it by VCS/DVCS (please don’t mix them).

Thank you.

Answer 1

The main feature all VCS use for the various task you are mentioning is branching: the ability to isolate a development effort in a collaborative way. Since it is a Central VCS, several developers can collaborate on a same branch, with pessimistic or optimistic locks on files, in order to develop a parallel history.

But being a VCS has two major impact on branching:

1. It tends to discourage commits, because once a file is committed, it will immediately influence the workspace of other views with the same configuration (i.e. “working on the same branch”).
   ~ The “publication” process is an active one, with immediate consequences,
   ~ while the “consuming” part (updating your workspace) is a passive one (you are forced to deal with changes published by other immediately upon update of your workspace)
2. It works well for linear merge workflow (i.e. “only merge from branch A to branch B, not mixing merges in both directions” — A to B to A to B…). The merges are trivial, all modifications from A are simply carried over to B

Now:

Implementing a feature

Any VCS will do that by making a branch, but what greatly surprised me is that a “feature” branch is not easy:
* the feature may grow too complicated
* it may be ready in time for the next release
* only some part of it may need to be merged back into the main development branch
* it may depend on other features which are not fully done yet

So you need to be careful in the way you manage your feature branch, and your commits: if they are tightly related to the same feature, it will go well (you merge the whole thing back to your main development branch when you need it). Otherwise, partial merges are not easy with those tools.

Fixing bugs

The difference between bug fix during development and after release is that, in the former case you can often do it linearly in the same branch, as in the latter case you will have to establish a bug-fix branch, and decide what bugs you will need to back-port to your current development branch.

Code Review

It is best used with external tools (like Crucible for instance), and uses VCS functions like blame or annotations extensively, in order to better assign code fixes after a review.

Refactoring code (post code-review)

If the refactoring is minor, it can go on in the same branch. But if it is big, a special branch needs to be setup, with unit-testing done before beginning said refactoring.

Incorporate patches

Same comment as last point. If the patch is a big one, a branch needs to be created.

Releasing the newer version of your app

A VCS will only get you so far when it comes to releasing your app, because it is not a release management tool.
You will need to formerly identify a version to be released (label), but after that comes the deployment process which involves:

• stopping what is currently running
• copying the new files
• deploying them (updating sql database, webapp, …)
• instantiating all config files (with the right values, addresses, port number, paths, …)
• restarting (and if your system is composed of several components, restarting them in the right order!)

The key things with VCS and release management are:

• they are not very well adapted to store binaries to be released, meaning you need them to build your app, not to store the resulting executable
• they are not always welcome in the production environment (where security constraints limit writing access, as well as the number of tools running on those platforms, essentially monitoring and reporting tools)

The release mechanism also has an influence on binary dependencies:

• for external binary dependencies, you will probably use mechanisms like maven to get fixed revisions of external libraries
• but for internal dependencies, when you are not developing just one app but several which depends one upon an other, you need to know how to reference the binaries produced by the other apps (internal binary dependencies), and they usually won’t be stored in your VCS (especially in the development phase, where you can produce a lot of different releases for your other apps to be able to use)

You can also choose to be in source dependencies (and get all the sources of the other internal projects you need for your own), and a VCS is well adapted for that, but it is not always possible/practical to recompile everything.