Servicing SQL Server

Question

Servicing SQL Server

Steve Jones - SSC Editor

SSC Guru

Points: 734459
More actions
September 16, 2023 at 12:00 am

#4287062

Comments posted to this topic are about the item Servicing SQL Server

Viewing 12 posts - 1 through 11 (of 11 total)

You must be logged in to reply to this topic. Login to reply

Jeff Moden SSC Guru Points: 1003869 More actions · Answer 1

From the Article:
The goal is repeatable, reliable software deployments, with releases, or at least deployments, being an everyday occurrence, not a big event.

I have to strongly disagree... the goal is good releases with properly working code. You frequently won't get quality code if you're compelled to release every day. And, no... DevOps does NOT mean daily releases.

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

Lisa Slater Nicholls Hall of Fame Points: 3453 More actions · Answer 2

@jeff, while I agree with you about the most important goal, I don't think Steve meant "daily" when he said "everyday". He meant "quotidien/mundane/matter-of-fact/run-of-the-mill/as-expected". And no, I'm not checking a thesaurus, on-line or otherwise <g>, so I may not be expressing this exactly right either. IAC, Steve's point in that sentence is one I'm pretty sure you don't disagree with at all:

We want good releases with reliable code, and part of making sure those releases are good and the code is reliable is a very straightforward and consistent test-merge-and-deployment process.

I ILisa) personally don't care whether that process is called DevOps or whatever, btw.

If somebody (Microsoft in this case) has such a process, and if that somebody has committed to dates for releases, you'd expect that the dates would be met, even though some release dates might offer fewer fixes and improvements than others. It's almost impossible that *nothing* was improved or fixed within that interval, with a product this complex.

At least, that's my interpretation of the point Steve was trying to make.

>L<

jahtez SSC Rookie Points: 34 More actions · Answer 3

While we would like releases to be scheduled proactively and on a schedule that makes out lives easier, security updates, in most instances, are reactive and driven by external events usually beyond our control yet with the imperative that that are corrected ASAP. I suspect that process wouldn't conform to a tidy schedule, and there may be varying degrees of difficulty in analyzing a new flaw, designing a solution, implementing that solution, then retesting any impacted elements.

Tez

This reply was modified 7 months, 2 weeks ago by jahtez.

Jeff Moden SSC Guru Points: 1003869 More actions · Answer 4

Lisa Slater Nicholls wrote:

@Jeff, while I agree with you about the most important goal, I don't think Steve meant "daily" when he said "everyday". He meant "quotidien/mundane/matter-of-fact/run-of-the-mill/as-expected". And no, I'm not checking a thesaurus, on-line or otherwise <g>, so I may not be expressing this exactly right either. IAC, Steve's point in that sentence is one I'm pretty sure you don't disagree with at all:
We want good releases with reliable code, and part of making sure those releases are good and the code is reliable is a very straightforward and consistent test-merge-and-deployment process.
I ILisa) personally don't care whether that process is called DevOps or whatever, btw.
If somebody (Microsoft in this case) has such a process, and if that somebody has committed to dates for releases, you'd expect that the dates would be met, even though some release dates might offer fewer fixes and improvements than others. It's almost impossible that *nothing* was improved or fixed within that interval, with a product this complex.
At least, that's my interpretation of the point Steve was trying to make.
>L<

We'll see.

Also, people that read this hold him in very high regard (as I do) and will take his word as gospel. This is how "myths" and "Best Practices" that aren't get started.

And, I agree. I don't call it "DevOps". Never have and never will, especially since it's real meaning has been tainted so very badly by a whole lot of people. I've also been doing what the original meaning of "DevOps" meant since long before I got involved in SQL Server, as it sounds like you have, as well.

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

Rod at work SSC-Dedicated Points: 33900 More actions · Answer 5

I've been wondering what chances DevOps has in an organization which doesn't want to adopt DevOps. I work at a place where resistance to DevOps is predominant. Because this is a government agency, we have no competition. That might be the primary reason DevOps here is DOA.

Kindest Regards, Rod Connect with me on LinkedIn.

Jeff Moden SSC Guru Points: 1003869 More actions · Answer 6

Rod at work wrote:

I've been wondering what chances DevOps has in an organization which doesn't want to adopt DevOps. I work at a place where resistance to DevOps is predominant. Because this is a government agency, we have no competition. That might be the primary reason DevOps here is DOA.

I have to ask... what is YOUR definition of what DevOps is?

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

Lisa Slater Nicholls Hall of Fame Points: 3453 More actions · Answer 7

@jeff,

> This is how "myths" and "Best Practices" that aren't get started.

You are, of course, correct, sir. In pretty much any field.

>I've also been doing what the original meaning of "DevOps" meant since long before I got involved in SQL Server, as it sounds like you have, as well.

I expect I/we have. The labels (and the religious fervor) don't change anything (or... maybe they do, but not in a good way).

>L<

Jeff Moden SSC Guru Points: 1003869 More actions · Answer 8

Thank you for the feedback, Lisa. You're absolutely correct about the labels and fervor and, especially, the changes from what I believe the original intent was for a whole lot of things.

--Jeff Moden

RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
First step towards the paradigm shift of writing Set Based code:
________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

Change is inevitable... Change for the better is not.

Helpful Links:
How to post code problems
How to Post Performance Problems
Create a Tally Function (fnTally)

Steve Jones - SSC Editor SSC Guru Points: 734459 More actions · Answer 9

Rod at work wrote:

I've been wondering what chances DevOps has in an organization which doesn't want to adopt DevOps. I work at a place where resistance to DevOps is predominant. Because this is a government agency, we have no competition. That might be the primary reason DevOps here is DOA.

Jeff has a good question, but lots of government (US and overseas) is adopting DevOps. Self serving, as this is my employer, but there are other articles out there from other sources: https://www.red-gate.com/blog/database-devops/introducing-devops-to-the-us-government-part-1

DevOps is mostly good culture and software dev practices that are old, combined with rapid flow of the work from VCS->prod, which is new. To me, this is the continuous delivery of value to customers.

Without good management that creates good culture, nothing works well. No DevOps, no customer needs being met, no better quality code, nothing. Then we have old management that showed from the 50s through the 90s that most software dev projects fail and aren't delivered, or very much underdeliver/over budget.

Steve Jones - SSC Editor SSC Guru Points: 734459 More actions · Answer 10

I certainly didn't mean every day, though I'm not opposed to every day. Well, I am for databases in general. I think once a week is a good cadence, but if we broke something yesterday (or today), we ought to have repeatable, reliable deployment. A deployment ought to be a non-event. Easily done when the code is done.

I emphasize this constantly in my talks. Quality is not optional here. The goal is pre-approved in a VCS, we have good testing/evaluation along with modeling, etc. My quote: " I like regular deployments, after good modeling, testing, and review by multiple people that ensure we are constantly delivering value to customers"

People miss that often, but I keep saying it. I hope some of you will one day get that quality is as important as speed.

Rod at work SSC-Dedicated Points: 33900 More actions · Answer 11

Jeff Moden wrote:

Rod at work wrote:
I've been wondering what chances DevOps has in an organization which doesn't want to adopt DevOps. I work at a place where resistance to DevOps is predominant. Because this is a government agency, we have no competition. That might be the primary reason DevOps here is DOA.
I have to ask... what is YOUR definition of what DevOps is?

My favorite definition of DevOps is Donovan Brown's (formerly with Microsoft) definition. His definition is, "DevOps is the union of people, process, and products to enable continuous delivery of value to our end users." Here's a link to his blog post on DevOps.

I don't see us delivering value in an efficient way, to our end users. We can and often do take a lot of time to deliver anything. Occasionally that means we're so slow that the customer will seek an alternative way of getting the needed results. Also, as a state government agency, sometimes what we deliver is related more to the governor's political agenda, at least from my point of view. (This is regardless of who the governor is or what political party they represent.)

Kindest Regards, Rod Connect with me on LinkedIn.