Version Control

So, we're coming up on moving to a more Agile development cycle at work, and the primary problem this might cause is some issues with the way we do version control.

- Every release has a branch. There is no longterm "main" branch. Every release is labelled.
- Subcontractors merge in each afternoon.
- There are merge points scheduled between each release branch, specifically, when a release is pushed to production, it's merged forward to all other branches.
- There's one person who does most or all of the merges.

I'm suggesting:
- We have a main branch for all releases. Every release is labelled.
- After a release is pushed to production, work on the next release continues in the same place.
- If work needs to be done as a production fix, a branch is created from the label that's in production. Fixes are done on that branch, that branch is pushed to production and merged back into main at that time. Production fixes should be much less code than ongoing development, so the smaller amount of code is what you want to be merging.
- Developers merge their own code, as they're most familiar with it.
- There's an individual responsible for very loosely tracking all active tasks, who alerts developers if two tasks seem to have some overlap.

There's two kickers here.
- What happens when development needs to start before the previous release is ready for production? My quick answer is that the earlier release should be branched off of main at that time.
- We actually have two sets of releases that develop in parallel; one is for core functionality, and one is for client customizations. The first is larger, and should be the main branch, but a second plan needs to be put in place for the client customization branch, to merge to-and-from main on a regular basis.

So, I know that's not a coherent whole, but thoughts, anyone?

No comments: