What advantages in source code control are there to a three-stage environment repository?

Question

The current company I'm working for has what I consider to be an unusual set up for their version control system. I'm working with it but I can't help but feel what they are doing is suboptimal and that they'd have much better process if they used what I consider to be a more standard Trunk, Branch, Tag approach.

I've presented this idea to them and they were open to change however before I start pushing for this change to take place (and possibly being the one who implements it) I want to make sure I'm not missing some advantages to their current set up that would be lost.

They use what could be describe as a 'three-stage environment' approach, each project will have its own repository and in that repository the top level folders will always be DEV, UAT, PROD:

A typical development cycle for this is as follows:

1. Developer checks out the DEV folder, performs changes and checks it back in.
2. Support team deploy changes from DEV into the UAT environment and checks the changes into the UAT folder. Since this isn't my responsibility it isn't clear if this is before or after testing.
3. Support team deploy changes from UAT into the Prod environment and checks the changes into the Prod folder.

I am more used to working with the Trunk, Branch, Tag model:

(Image from http://blogs.collab.net/subversion/migrating-subversion-repositories-to-git#.WfnfuGdLGUk)

Which would map to the current development cycle of the company as:

1. Developer creates a branch for the development work, perform changes and tag it.
2. Support deploy the tag to the UAT environment. There is no need for them to check anything in.
3. All being well Support deploy the tag to Prod. Against there is no need to them to check anything in (or we could tag again for a distinct record of a prod release).

I can see lots of advantages to the TBT method but really struggle to find why the three-stage approach would be better.

Although I can't find any strengths to it here are the issues I'm finding with the three-stage approach for those who would find it easier to answer against some specific points:

• Almost always the code across all three stages doesn't match and then there is a period of merging at the start of every project.
• When I check in to DEV I cannot guarantee my changes are cascading through to UAT and Prod by the end of the project. This shouldn't be my responsibility to check (IMHO) but when further changes need made it becomes my issue because I need to make sure DEV hasn't drifted from UAT and Prod.
• The idea of feature branches just doesn't fit with this, unless we branch at DEV and make a matching branch in UAT where the DEV branch gets promoted to. Normally we only have 1 developer on a project so it isn't an issue, I can work directly on trunk without conflicts, but I'd still prefer to use best practice so we can grow painlessly if we do.
• There is no solid way to confirm which version is currently in which environment. With a tag I can say, version UAT1.2.3 was published on Jan 1st, with the current set up I need to look at the revision history, see what was checked in when and marry that up with the release dates.

I don't know if it is the lack of correct terminology or if it is just because it is inherently bad approach but I'm having a hard time finding resources that promote or discuss this structure. Here is one I've found with someone asking the same question and I'm still actively looking.

What am I missing here? What are the advantages of the three-stage approach over TBT and others? Or are there none and the three-stage approach isn't actually a thing?

Answer 1

Branches are definitely the way to go, and in modern SCM systems working with branches is very efficient, so there is no reason not to do this.

In older SCM systems branches were so inefficient in moderate to large sized projects that they were completely unusable.

I guess that your system either 1) Was migrated from a SCM where branches were unusable and the process hasn’t been updated or 2) Designed by someone who’s knowledge of SCM systems it outdated, and they don’t realize that branches now work very efficiently even on very big codebases.

Answer 2

I've worked with a somewhat similar system on the desktop. Mainly this was used to enable developers to switch code versions quickly. This was based on code branches.

• Dev - ongoing development.
• UAT - patching UAT after a release branch was cut.
• Prod - patching the production branch after a release.

Different organizations use different code promotion methods. Depending on the requirements, there can be significant reviews of code before promotion to the next environment. Whatever model is used, it will be necessary to synchronize changes back to the development stream.

Your organization may use separate code repositories for development and staging. I would not expect a third repository for production. Having two repositories is not that uncommon, and works well when formal migrations are required or desired. The release repository can have quite strict access rules, while allowing open access to the development repository. Development changes are imported into the release repository after some validation. Rejected changes need to be reverted out of the development repository.