I’m in SCM and work with a variety of tools (Subversion, Clearcase, TFS, Perforce) and technologies (.NET, Java mostly). Before I started work, the normal order of business was to create a controlled branch.
I define controlled branch as:
-A separate branch which contains promoted code which developers are unable to access. Only a team of build engineers have access to this.
Controlled build:
-Build engine which takes code from controlled branch and produces an artifact developers are unable to modify.
As a result, merging into this branch has become a significant step as part of a controlled build process. This can create both issues with speed and errors (which will be mostly mitigated by automation).
Benefits:
Automatic Code Lock (since devs can’t modify branch)
Branch names can be different (other teams don’t necessarily follow standardized practices and we are not necessarily able to exert the required pressure.)
easy way to find out exact version code state (i.e. latest code in controlled branch for a version is what went to prod)
Drawbacks:
Speed
matching dev builds with controlled builds when discussing issues with developers (this is automated, but a little messy).
Errors (another place to mess up in the process)
Can the security/role separation functionality be fully handled by using changelists/changesets/immutable labels?
Questions:
Should I recommend moving from the current controlled branch strategy? Am i missing other benefits?
I wouldn’t recommend using branches as promotion mechanism, unless you intent to do lots of modifications from the label being merged to said branch.
A branch should isolate a development effort (i.e. something where files are modified and new versions committed)
A Label associated with some kind of metadata (ClearCase attributes, SVN properties, Git notes, …) should be enough to monitor the promotion of said label (with its immutable content) through the various promotion levels.