Join devRant
Do all the things like
++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatar
Sign Up
Pipeless API
From the creators of devRant, Pipeless lets you power real-time personalized recommendations and activity feeds using a simple API
Learn More
-
So i wasn't writing code at the time but I had exposure to this practice, and it was roughly like you say, with maybe one important catch.
This also was with big bank clients and financial companies and all these different hot fixes was thought to be the cost of doing highly profitable business with them.
That didn't keep anyone from copying and pasting from one hotfix to the next, but all hot fixes were separate on a per client basis. You just didn't know what would get emphasized after they used a given hotfix.
HOWEVER:
Hotfixes were given a much shorter supported lifespan. Eventually our customers were expected to either upgrade to the more recent mainline code that also got the fix, or just live in unsupported land and in theory the answer was "upgrade and then tell us if you have the issue". Granted like all things some exceptions might apply, but one way or another all hotfixes got a shorter lifespan to avoid and endlessly growing old chunks of code. -
Hotfixes are only meant to firefight a pressing issue without delaying till the next stable release
It is unfortunate that you have to deal with Banks since it is not easy to work with in terms of technology, upgrades, etc. But your half ass RMs should fix this vicious cycle and reduce the maintenance headaches this practice ensues
when your code is a mess but everything work out in the end
When you keep getting +1s on a rant you posted a month ago.
Go big or go home.
Extremely frustrated with the release process and versioning system at my current company. Don't know if this is same everywhere or the half ass release managers can't think of a better way here.
Basically for any client raised issue that can't wait for next release are built as a hotfix. However hotfixes are never bundled togather or shiped to other clients. This is causing a vicious chain, two clients raise two separate issues on same version. Instead of fixing them as single hotfix (however minor the issues) we create two hotfix versions for each with only their issue. A week later same clients come back with the issue the other raised. Once again instead of bundling what is now effectively same code we build hotfixes on top of the clients respective branches. We now have two branches to maintain with same codebase. No matter how serious issue, the hotfix is never made generally available and always created on client's specific hotfix version.
Now that was an example for only two clients, in reality we have released five patch versions of a product in last 2 years. Each product version contains about a dozen artifacts (webapps, thick clients, etc) with its own version. Each product version being shipped to various clients. Clients being big banks never take a patch of product even if it fixes their issues and continues requesting hotfix. We continue building hotfixes on client branch and creat ever increasing tech debt. There is never a chance to clean up or new development. Just keep doing hotfix after hotfix of same things.
To top if all off, old branches are still in svn while new in git. Old branches still compile with ant new with maven. Old still build with java 5,6,7 while current with 8. Old still build from old jenkins serve pipelines while new has different build server. Old branches had hardcoded integration db details which no longer exists so if tou forget to change before releasing it doesn't work.
Please tell me this is not normal and that there are better ways to do this? Apologies I think I rambled on for too long 😅
rant
frustration
long rants
story