November 30, 2020 at 12:00 am
Comments posted to this topic are about the item Delivering Patches Quickly
November 30, 2020 at 1:48 am
I'm thinking "Ok... Catch 22". IMHO, the more quickly you move, the more likely you are to make a mistake and that's not limited to what most people consider to be a "release". They forget that "patches" are really just mini-releases. They also forget that "patches" are even more tricky than a "release" because a lot of people will take short-cuts to more quickly push out a "patch" and, possibly, miss the fact that the "patch" actually broke something else. If it's an edge case (which is no less important), it may not have been tested at all.
The amount of electronics going into vehicles now just scares the hell out of me. All I really want my vehicle to do auto-magically for me is to turn the headlights on when I start it and turn them off when I turn off the engine. Of course there needs to be a manual control for if/when I want to turn the headlights off/on whether the engine is running or not. Even having computer control for spark, timing, and fuel injection is spooky to me compared to other methods. Just imagine if someone figured out the control codes to make all the vehicles in a given area go through the "slow down and die" mode that some vehicles have (like mine).
And, yeah... I love my cruise control but I could make due without it with no effort.
As a bit of a sidebar, hacking key fobs and garage door openers has been around for a very long time. It's not something new with Tesla. What is new is the ability to "patch" them remotely, which also makes them even more prone to hacking.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 30, 2020 at 2:15 pm
In my final DBA position before retirement, patching and bug fixes were usually provided quickly and accurately but were most often sidelined by 'project managers' too timid to allow release. They mostly depended on manual user work around or even tolerating invalid data over and above 'the risk' of releasing patches. We had fixes that remained on the shelf for the life of the applications without being applied
Rick
Disaster Recovery = Backup ( Backup ( Your Backup ) )
November 30, 2020 at 4:26 pm
In my final DBA position before retirement, patching and bug fixes were usually provided quickly and accurately but were most often sidelined by 'project managers' too timid to allow release. They mostly depended on manual user work around or even tolerating invalid data over and above 'the risk' of releasing patches. We had fixes that remained on the shelf for the life of the applications without being applied
Ouch, that hurts.
Kindest Regards, Rod Connect with me on LinkedIn.
November 30, 2020 at 4:27 pm
That's one of the tenets of DevOps. Don't leave software in inventory. Get it to the customer.
We do make mistakes moving faster. We also make mistakes moving slower. The thing that gets me to think faster is that I can fix things that are broken if we have the habit of deploying often.
I've been in that situation of having patches, but being unable to release them.
November 30, 2020 at 4:34 pm
In my previous job, working in a small IT shop, we all wore lots of hats. We were IT, DBAs and developers. But I now realize that experience isn't typical of a lot of businesses and environments.
In my current job there's lots of people who work in IT (I'm including operations, DBAs and developers), so everyone is specialized. After almost 6 years in this job, I still don't know how Ops and Dev can work better together. The silos seem as high as ever. Having never experienced a large, functioning Ops and Dev environment that worked well together, I don't know how it's supposed to work.
Kindest Regards, Rod Connect with me on LinkedIn.
November 30, 2020 at 4:51 pm
the way I see it. If you deploy every day or even once a week, you eventually either learn how to do it safely or go out of business.
November 30, 2020 at 5:31 pm
the way I see it. If you deploy every day or even once a week, you eventually either learn how to do it safely or go out of business.
Heh... I've seen enough garbage code out there to know that it doesn't necessarily cause you to go out of business... although I think it should. 😀
Consider Microsoft and some of their recalled SP's and CU's and RTM's and broken or slothful features and... and... and... 'nuff said.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 30, 2020 at 5:52 pm
And consider how quickly broken systems get patched.
A far cry from patches that were delayed months, sometimes closing in on double digit months, in the 90s and early 2000s.
November 30, 2020 at 5:55 pm
And consider how quickly broken systems get patched.
A far cry from patches that were delayed months, sometimes closing in on double digit months, in the 90s and early 2000s.
True enough but the questions remains... would there be less need for patches if they slowed down a bit and did it right the first time instead of marching to the beat of a drum?
--Jeff Moden
Change is inevitable... Change for the better is not.
November 30, 2020 at 5:58 pm
I'll also add that a lot of the "patches" by MS actually take years to fix, if they even bother to fix them at all.
For example, there's been a whole lot of complaining to MS about their string splitter function (since day 1, BTW) not being fully function because it doesn't return the ordinal positions of the rows in the return.
--Jeff Moden
Change is inevitable... Change for the better is not.
November 30, 2020 at 5:58 pm
No, we've seen them do that. We've seen millions of software projects that go slow. Bugs still appear.
Delivering every week doesn't mean you start writing code today and release it tomorrow. The people that do that will still produce horrific code. We may still spend 3 weeks working on code, but if it gets done AND gets tested (automated, manual, following protocol), it gets released quickly.
Teaching people to follow best (or better practices), test their code, use realistic data in tests, ensure you watch edge cases, etc. has nothing to do with how fast or slow you can release.
The big failures in companies I see adopt DevOps is that they don't
They fail at the biggest part of DevOps, which is learning and changing over time. They often just want to write more code faster, without changing anything else.
November 30, 2020 at 5:59 pm
I'll also add that a lot of the "patches" by MS actually take years to fix, if they even bother to fix them at all.
For example, there's been a whole lot of complaining to MS about their string splitter function (since day 1, BTW) not being fully function because it doesn't return the ordinal positions of the rows in the return.
Your complaints here are not bugs, nor are they valid. That splitter is by design. We can argue with them this is a bad design, but they produced what they wanted to produce and it works well, given that ordinal position is not a spec item.
December 1, 2020 at 3:20 pm
The big failures in companies I see adopt DevOps is that they don't
- test more, especially automated testing
- include more instrumentation and get metrics/data/feedback from the operation or deployment of code
- learn new patterns and anti-patterns as they get feedback
They fail at the biggest part of DevOps, which is learning and changing over time. They often just want to write more code faster, without changing anything else.
Where I'm working, we're trying, for a second time, to adopt DevOps. I, personally, do not believe it will succeed. The reason I don't believe it will succeed is because we're relying only upon the tool. There is, at least so far, no change in process nor in how people approach DevOps. In fairness to my colleagues, I suspect that wherever DevOps fails, its often due to thinking that the tool, alone, will get you there.
Kindest Regards, Rod Connect with me on LinkedIn.
Viewing 14 posts - 1 through 13 (of 13 total)
You must be logged in to reply to this topic. Login to reply