How to manage feature changes during release cycle?

[Fr0sT.Brutal 900]

From me:

Don't make videos for coding stuff!!!

[Mike Torrettinni 198]

On 9/30/2021 at 12:28 PM, Darian Miller said:

From Dave Farley:

 

Well, this guy definitely pushed me read up more on this stuff, I just couldn't listen and follow his graphics at the same time.

The good thing is that being single developer on a project that you can not only decide which branching model you use, if any, but you can combine and switch as needed.

 

But using Git flow model, It would be really nice if Delphi IDE could give a little more info about the current working branch, as it has so many branches.

 

Pretty cool when you can refer to your product as legendary and write it on your blog about Git branching models:

https://www.gitkraken.com/learn/git/best-practices/git-branch-strategy

[Darian Miller 361]

9 hours ago, Fr0sT.Brutal said:

From me:

Don't make videos for coding stuff!!!

 

For me, I sometimes like to watch coding videos.  This guy is pretty good.  He likes stating controversial statements as click-bait, but nothing is written in stone.  There are exceptions for everything.

 

 

 

 

 

 

 

[Darian Miller 361]

I suggest you be careful managing 'many branches'.  Merges become much more painful as time progresses.  Choosing the appropriate branching method heavily depends on the type of product and how it's deployed to the users (and how many distinct active versions you maintain.)  Since you are a single dev team - you get to pick the least painful, most productive way to maintain your software.  Here's another reading source for you:  https://trunkbaseddevelopment.com/

 

There is no 'perfect' way of doing things.  One of my mantras has long been "Progress, Not Perfection"  If you slowly get better over time, your cumulative progress will add up rather quickly.  This counters the real fact that "change is painful"  On my team, we went years avoiding pain and it just made things much worse.  So it seems like you are on the right path - keep poking away and things will get better.

 

[David Heffernan 2345]

1 hour ago, Mike Torrettinni said:

But using Git flow model, It would be really nice if Delphi IDE could give a little more info about the current working branch, as it has so many branches.

Delphi IDE integration for vcs isn't very good. I'd use another tool for that. 

[David Heffernan 2345]

1 hour ago, Darian Miller said:

I suggest you be careful managing 'many branches'.  Merges become much more painful as time progresses.

It's not so much how many branches. It's how long they live and how regularly changes from the develop branch get pulled into them.

 

The other issue that can bite is when you have multiple branches working on the same area of code, for obvious reasons. 

 

But I don't think you should be afraid of having many feature branches so long as they are managed properly.

[Darian Miller 361]

32 minutes ago, David Heffernan said:

I suggest you be careful managing 'many branches'.  Merges become much more painful as time progresses.

32 minutes ago, David Heffernan said:

It's not so much how many branches. It's how long they live and how regularly changes from the develop branch get pulled into them.

Which is why I said they become more painful as time progresses.

 

Managing branches 'properly' typically becomes increasingly difficult as the number of branches increase as the change scope creeps up and conflicts quickly mulitply. Branches typically defer and increase the pain of merging.  It's best not to branch at all unless you can guarantee isolation, but if you can do that, then you can use other methods to stick to the mainline.

 

 

[David Heffernan 2345]

23 minutes ago, Darian Miller said:

Managing branches 'properly' typically becomes increasingly difficult as the number of branches increase as the change scope creeps up and conflicts quickly mulitply. Branches typically defer and increase the pain of merging.  It's best not to branch at all unless you can guarantee isolation, but if you can do that, then you can use other methods to stick to the mainline.

Branch management requires skill but it's perfectly possible. You just need to know how to do it. 

[Darian Miller 361]

16 minutes ago, David Heffernan said:

Branch management requires skill but it's perfectly possible. You just need to know how to do it. 

 

As the videos I posted conclude, apparently it has been proven that software is developed more quickly and more robust with CI/CD techniques which involve few (if any) short-lived branches.  I tend to agree with that concept.

 

Every situation is different and success is measured in different ways. I know what has worked well for me and what has not.  I leveraged that knowledge to help me retire at a fairly young age.  But I'm heading back to work soon after a few years of inactivity as I simply enjoy to code and retirement is somewhat boring (especially in an extended pandemic which doesn't seem to want to end.)  And the place I'm going to apparently uses branches heavily, so that's what I'll do.  It obviously works for them as they have enviable market share and have been making software for 30+ years.  It's difficult to argue with success.  

 

So whatever is working well for you, certainly keep doing that but there's nothing wrong with thinking about improvements.  It would be foolish to change something that's working solely based on some video or forum message.

[David Heffernan 2345]

54 minutes ago, Darian Miller said:

Every situation is different

This is a good point. Perhaps some settings suit a process with no branches.

 

 

But 

 

1 hour ago, Darian Miller said:

apparently it has been proven that software is developed more quickly and more robust with CI/CD techniques which involve few (if any) short-lived branches

 

This can't be right. You can't ever "prove" such a statement.

 

There's never going to be a one size fits all approach. We all have to do what works for us, and be prepared to entertain new ideas and approaches. 

[Darian Miller 361]

2 minutes ago, David Heffernan said:

This can't be right. You can't ever "prove" such a statement.

 

There's never going to be a one size fits all approach. We all have to do what works for us, and be prepared to entertain new ideas and approaches. 

Ask Dave Farley - that's his quote (and assumedly a large factor in selling his CI/CD training services.)  I said 'apparently' there has been studies to prove it.  I took Dave at his word, but also hedged my statement as I foretold a response.

 

If you are making money doing what you are doing, then you are obviously doing something right.  If you want to make more, then perhaps some well defined tweaking will improve the situation - but as we have all seen time and time again, new managers trying to dramatically and quickly change workflows typically end up costing a lot of producitivty and rarely succeed.  In the recent developer interview process, I was quizzed on Chesterton's Fence and software development.  They were happy with my response.  

 

I do not advocate for wholesale changes for a working system.  If there are ways to improve it, and there also exists valid business reasons to enact those changes, then they should be considered.  In this thread, if one is struggling with the real costs of too many branches, or not enough branches, then I suggest you watch Dave's videos and see what insight he has.  He's a pretty successful person in this area.  You reduce the need for branches by introducing Feature Toggles, Dark Launching, and Branching by Abstraction, but you don't necessarily eliminate them.  

 

[Dalija Prasnikar 1396]

11 hours ago, Darian Miller said:

As the videos I posted conclude, apparently it has been proven that software is developed more quickly and more robust with CI/CD techniques which involve few (if any) short-lived branches.  I tend to agree with that concept.

Main issue with branches are merge conflicts. They tend to get worse with time because more code is added and there is potentially more conflict. So naturally, if you have short lived branches there is less possibility for conflicts to emerge. Also continuous delivery focuses on making small incremental changes (which is not always possible) so making small features that don't span across too much code (files) tend to be easily mergeable.

 

Having said that, the lifetime alone actually means nothing. Nor the number of branches.

 

First, you can easily shoot yourself in the foot with the branch old just a few hours, if you change some "hard" to merge file - think something like dproj file. On iOS, macOS that would be storyboards - you don't even need multiple developers to make a mess. So for some types of files, you will need to have specific instructions about who and how can change them without causing issues. 

 

Next, it is not how long branch lives, but whether you keep it up to date with other development. If you have branch and you merge it after a year, of course there will be trouble, but not because the branch is year old, but because you didn't keep it up. 

 

The most important rule is don't merge, rebase and rebase often. Not only that keeps history cleaner, but you will also have less conflicts - most of the time there will be none or they will be simple to resolve.

 

 And of course, in larger teams there has to be some coordination between what is done and when. It makes no sense to start some large refactoring in one part of the code few days before another large refactoring in overlapping area of the code is finished. It is better to wait than waste time on merging.

Edited October 2, 2021 by Dalija Prasnikar

[David Heffernan 2345]

40 minutes ago, Dalija Prasnikar said:

Main issue with branches are merge conflicts.

Merge conflicts happen whether or not the team is using branches or all developing on a single branch.

 

If there are never any conflicts then it doesn't make much difference if you use branches or not.

 

If there are conflicts then they can be a massive problem on long lived branches. But if there are no branches then they are also a massive problem. Often developments are in flux. Devs try something. Realise it was the wrong idea. Try something else, and so on. If this happens without branches then everyone has to deal with the conflicts over and over again. That's more work. 

 

Well managed branches make this easier. 

 

There never are magic bullet solutions for tough problems like this. You have to keep an open mind and do what works best for their teams. 

[Dalija Prasnikar 1396]

12 minutes ago, David Heffernan said:

Merge conflicts happen whether or not the team is using branches or all developing on a single branch.

Yes, of course. 

 

Point is that merge conflicts are often used as an argument against branches and to a point branches can escalate problem. For instance single developer developing on single branch will not have merge conflicts, but reckless use of branches can cause issues even for single developer, which often leads to the conclusions that branches are inherently bad, not the how they are used.  

[David Heffernan 2345]

2 hours ago, Dalija Prasnikar said:

For instance single developer developing on single branch will not have merge conflicts

Even this can happen if the developer is splitting time between two different projects. 

[Dalija Prasnikar 1396]

17 minutes ago, David Heffernan said:

Even this can happen if the developer is splitting time between two different projects. 

This can happen even if you don't use any VCS 

 

Not the conflict per-se, but changes in common code if projects are not separated can cause problems and other project may no longer work properly or even compile.

Edited October 2, 2021 by Dalija Prasnikar

[Guest]

19 hours ago, Mike Torrettinni said:

being single developer on a project

Being a single developer, the only need for a VC system is when i forget what i am on about and need to refresh my memory on my own strategies from some months back, my own commit notes are gold and when they are not specific enough i can view the comparison, "Code you wrote 6 moths ago could as well be written by someone else".

I agree with the sceptics when it comes to projects with one to three coders. Branching and merging is just a mess and way over the top.

I also agree (though this exp points are from more that 15 years back) that if you really want to update "continuously" an elaborated flow/branch/merge approach will bog you down. I.e. there are other techniques and this being a Delphi forum, it should be apparent.

Test and fix and use proper abstraction and those thingies should not have to be attached with the graveness that currently seems to be the case.

Also - videos about coding sucks. Totally. Present a writeup, if they need to use facial expressions and audible cadence, they got something to hide. IMHO.

[Mike Torrettinni 198]

5 hours ago, Dany Marmur said:

my own commit notes are gold

This actually forced me to look up if I can connect SourceTree with Jira projects and you can and works very well! I'm not that good with comments, but being able to connect Jira issues with commits, it's gold to me.

[Darian Miller 361]

6 hours ago, Dany Marmur said:

Also - videos about coding sucks. Totally. Present a writeup, if they need to use facial expressions and audible cadence, they got something to hide. IMHO.

 

+1 for Videos as they can play while you ware working on something else. My favorite part about youtube is the playback speed feature.  I normally crank it up to 2, but scale back down on occasion as needed.  Alister Christie is a good example of having to scale it back.  He articulates his words pretty quickly so at a speed of 2 it's difficult to understand so he gets 1.5.  After my kids showed me this feature, I nearly always use it now.  I have a hard time watching someone speak now at a normal speed.

 

[Darian Miller 361]

11 hours ago, Dalija Prasnikar said:

The most important rule is don't merge, rebase and rebase often. Not only that keeps history cleaner, but you will also have less conflicts - most of the time there will be none or they will be simple to resolve.

 

 

I stay away from rebasing.  It just feels like a dirty approach.  Perhaps I just need to do it more often but I probably won't use it unless I'm forced to.

 

I started out with a 'sneaker net' version control system as we didn't have a network.  A couple times per day I would copy a few source files to a floppy, walk down the hall and hand it to the one other developer to copy to his machine (or he did it with me.)  We would merge changes manually.  (We split up tasks to specifically keep merging to a minimum.)  After months of this, we finally put in a network and shared files from a single location and used MultiEdit to modify the source.  It managed the read only lock on the file to prevent two people from accessing the same file.  We kept up with file locks with VSS for about a decade and then moved to SVN for the next decade.  Large project, built over 20 years with millions lines of source with 10 or more Delphi developers each committing multiple times per day.  We kept merges to an absoulte minimum and were quite successful.  For a long time, I directly managed the workflow and kept the merging to a minimum based on task assignment.  I think it's kinda rediculous to even contemplate 5 people editing the same DFM and attempting to merge UI changes (but sometimes it did have to happen.)  Most UI conflicts were basically minimized outside of the VCS.

 

I'll follow whatever the workflow is of the next company, and may hit you up on advice on rebasing if they follow that approach! 

[Darian Miller 361]

6 hours ago, Dany Marmur said:

"Code you wrote 6 moths ago could as well be written by someone else".

 

That's probably less than 30 days for me.  🙂

 

[Fr0sT.Brutal 900]

Rebase is nice for having a branch up-to-date, its final merge commits look very tidy in history. But be aware - rebasing rewrites commits so there's a chance some changes could be lost, especially if there are merge conflicts. If this is the case, a periodic merge from master to your branch could help better. And when a feature is ready, rebase and merge back. This should help avoiding any new conflicts. Luckily Git is smart enough to skip identical commits when rebasing so the branch's history won't be flooded with merge commits

Edited October 4, 2021 by Fr0sT.Brutal