2

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?

rickjr82
  • 203
  • 1
  • 11

2 Answers2

3

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.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
0

We use a controlled branch (MAIN) as our official build branch. Developers are only permitted access to this branch through merging operation from the development branch. Furthermore, MAIN branch code is merged to a BUGFIX branch, which is dedicated to bugfixes for our current release of software, and a PROD branch, where the code is labeled on a per-release basis.

I am of the opinion that anything that is going to be built for testing (and ultimately) production purposes should not have casual developer access, and should be managed by a SCM manager or other type of librarian role.

When we do have build issues within our MAIN branch, we are also adamant about having those bugs fixed within the development branch by the developers and having the resolution merged back into MAIN within our SCM policies.

Robaticus
  • 22,857
  • 5
  • 54
  • 63