May 18, 2016 at 10:57 pm
Comments posted to this topic are about the item The Complexity of Branches
May 18, 2016 at 11:03 pm
This is our take on branching.
We 'branch behind', making weekly development partner releases (DPR), deleting them after a week.
Once a month we keep the DPR and promote it to a standard (STD) release.
Each three months we promote a STD to General Product Release (GPR).
This schedule is well defined and customers know how to utilise it for early adoption of new features.
All bugs are fixed in all versions where possible.
All checkins are to the main trunk.
This is all done with 300 developers, 580,000 tests and over 1,000 assemblies.
Yesterday we were up to changeset 207565.
Now, the most recent changeset is 207682.
So we're doing over 100 checkins a day.
May 19, 2016 at 1:01 am
It depends on how much coverage your automated tests give you.
If a dev is working on a feature that can not be done piecemeal you never want that in your trunk or master branch as that branch should always be ready to release to production.
We have been moving more to Git (urgh not use to the RSI of doing everything twice - local then remote) and are following the recommended practice of having master for production, develop for work which is definitely going into the next production release, and then feature branches for work that will go in the next +1 production release.
May 19, 2016 at 2:47 am
We'll typically have a few "canon" branches. Chiefly development and production but we may create ones for specific versions, QA etc. depending on the project. These have continuous Integration running on them with 100% test coverage.
Beyond that we don't much care what branches individual want to create for their own purposes. Issues can only occur at the point of merge and the Continuous Integration picks that up. If the CI tests break the merge is undone and we're back to a stable state.
We encourage people to merge often but don't enforce it. If someone chooses to drive their own branch for 6 months and then merge a bunch of changes in at once then they own the pain of making sure the merge is successful - they tend to only do this once.
We've found that any hard and fast rules you try to set are wrong as often as they're right so you're continually making necessary exceptions, which just undermines the process. It's easier to let people do as they will but ensure that the canon braches are sacrosanct. You don't get to merge anything in there that isn't bomb proof.
May 19, 2016 at 6:34 am
We have a main trunk and one active branch at any one time. The branch is the to-be-released-next version. The problem we have is if someone is working on something that will not be complete before the two releases out. They either can't check into the trunk or have to remove/disable it before the next release when a copy of the trunk becomes the new branch.
May 19, 2016 at 10:01 am
brett.shearer (5/18/2016)
This is our take on branching.We 'branch behind', making weekly development partner releases (DPR), deleting them after a week.
Once a month we keep the DPR and promote it to a standard (STD) release.
Each three months we promote a STD to General Product Release (GPR).
This schedule is well defined and customers know how to utilise it for early adoption of new features.
All bugs are fixed in all versions where possible.
All checkins are to the main trunk.
This is all done with 300 developers, 580,000 tests and over 1,000 assemblies.
Yesterday we were up to changeset 207565.
Now, the most recent changeset is 207682.
So we're doing over 100 checkins a day.
Nice, so just a few branches? Is that 3 branches you have, each at a stable point in your cycle? If you have a bug in GPR, does it get fixed in that branch and then added to the others?
May 19, 2016 at 10:02 am
FunkyDexter (5/19/2016)
We'll typically have a few "canon" branches. Chiefly development and production but we may create ones for specific versions, QA etc. depending on the project. These have continuous Integration running on them with 100% test coverage.Beyond that we don't much care what branches individual want to create for their own purposes. Issues can only occur at the point of merge and the Continuous Integration picks that up. If the CI tests break the merge is undone and we're back to a stable state.
We encourage people to merge often but don't enforce it. If someone chooses to drive their own branch for 6 months and then merge a bunch of changes in at once then they own the pain of making sure the merge is successful - they tend to only do this once.
We've found that any hard and fast rules you try to set are wrong as often as they're right so you're continually making necessary exceptions, which just undermines the process. It's easier to let people do as they will but ensure that the canon braches are sacrosanct. You don't get to merge anything in there that isn't bomb proof.
Fair points. I don't like hard rules either, but I think some good guidelines are needed. I'd agree developers might not want to work for a month and then spend time merging, but some do. I think at that point you need to force, or enforce, them to merge more often because that's just inefficient use of time.
May 19, 2016 at 2:19 pm
Yes - 4 in total, new work always done in trunk.
Reproducing a bug will typically be done in trunk and cut back automatically by our checkin tool (gated).
Work is broken into tasks that are less than 8 hours (mandated by our workflow system) and so the impetus to work for long periods without checkin doesn't exist.
May 20, 2016 at 11:30 am
Is anyone using GitFlow and if so could you share your experience?
May 20, 2016 at 1:22 pm
Properly commenting code blocks that were modified in a branch is essential. All of my comments will contain a change tracking number, so it even if my one sentence explanation doesn't suffice, another coder can simply track back to the work item and see who made the change along with a full description of why. Also, if you have multiple coders branching from the same source file, then consider a series of collaborative code merging sessions where all contributors assist in tandem with the process of merging.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
May 24, 2016 at 8:55 am
David.Poole (5/20/2016)
Is anyone using GitFlow and if so could you share your experience?
I haven't. It looks complex, and one of our Redgate developers came from a company doing it. He found it to be overkill for most projects.
May 25, 2016 at 9:51 am
I think there is scope for a "Stairway to DB source control". I'm not volunteering for it as I'm too much of a beginner.
I've just about got the hang of the basics of working committing locally and pushing back to the remote server. Branching I sort of get but rebasing and merging scare me witless.
June 7, 2016 at 9:28 am
David.Poole (5/25/2016)
I think there is scope for a "Stairway to DB source control". I'm not volunteering for it as I'm too much of a beginner.I've just about got the hang of the basics of working committing locally and pushing back to the remote server. Branching I sort of get but rebasing and merging scare me witless.
June 9, 2016 at 1:03 am
I only run into issues when the work is poorly managed and communication is dropping. Ideally, if we are all working together, then very few merge conflicts happen regardless of how many branches. Ideally, if you can roll out a system to handle a larger team, then that works too.
On the project I work on now, I have master and dlevel. We all branch off dlevel for new features, bug fixing and so on. Each commit is handled with care and used with Git tagging. Essentially, every commit has a version number and can be rolled back when conflicts do arise that cannot be easily fixed. Merges happen daily.
My typical workflow entails refreshing the repo, going into JIRA, branching from right there in the task and banging away commits right off the bat.
January 18, 2017 at 12:57 am
A best practice I use is to ensure that tasks which are known to have significantly different durations to complete are carried out in different branches. This, I find, is best achieved by having a separate branch for any major task which is more likely to be released on a different timescale and more likely to be pulled from releases. The merge overhead is worth it for the benefit of release agility.
I should imagine that many others may have defined this, documented this or even decided on this before me but I am unaware but doubt it is anything other than standard for many.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
Viewing 15 posts - 1 through 14 (of 14 total)
You must be logged in to reply to this topic. Login to reply