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:
- Developer checks out the DEV folder, performs changes and checks it back in.
- 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.
- 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:
Which would map to the current development cycle of the company as:
- Developer creates a branch for the development work, perform changes and tag it.
- Support deploy the tag to the UAT environment. There is no need for them to check anything in.
- 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?