DevOps is Really Helpful

Question

DevOps is Really Helpful

Steve Jones - SSC Editor

SSC Guru

Points: 734434
More actions
June 30, 2018 at 1:15 pm

#371056

Comments posted to this topic are about the item DevOps is Really Helpful

Viewing 15 posts - 1 through 15 (of 20 total)

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

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

I have to disagree when I see something like this. There are no DevOps tools other than the human brain. DevOps is not a set of tools... it's a culture.

Are the tools like the one you spoke of great to have? Absolutely.... but they are not DevOps tools and you don't need to even know the word "DevOps" to use them never mind enjoying the culture of "DevOps".

--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: 734434 More actions · Answer 2

I'll disagree as well. There are tools used to support the DevOps ideas and methodologies. They could be tools used in other areas, but they certainly support and enable a DevOps attitude.

That in no way implies you need any specific tool.

Jeff Moden SSC Guru Points: 1003857 More actions · Answer 3

Steve Jones - SSC Editor - Saturday, June 30, 2018 6:15 PM
I'll disagree as well. There are tools used to support the DevOps ideas and methodologies. They could be tools used in other areas, but they certainly support and enable a DevOps attitude.
That in no way implies you need any specific tool.

My disagreement will have to continue. Such tools have existed for decades before the word "DevOps" was even a glimmer in someone's eye. Heh... some of the tools have existed before the people that coined the word were a glimmer in the Daddy's eye. 😉

DevOps isn't a person, place, thing... it's a culture. The tools we use are cool but they are not DevOps tools.

--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)

Beatrix Kiddo SSC-Dedicated Points: 32407 More actions · Answer 4

I agree that DevOps is a culture. It's first and foremost about how people work together. You can do it without special tools.

funbi SSCarpal Tunnel Points: 4992 More actions · Answer 5

You can do it without specialised tools, but it is EASIER with them. There are a lot of tools out there that have been developed relatively recently that facilitate DevOps and have been created specifically for this culture shift in IT.

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

funbi - Monday, July 2, 2018 4:33 AM
You can do it without specialised tools, but it is EASIER with them. There are a lot of tools out there that have been developed relatively recently that facilitate DevOps and have been created specifically for this culture shift in IT.

There's no question in my mind that the various jobs in IT are easier with tools. But, I disagree about the tools suddenly becoming available because of DevOps. Such tools have always been available and such tools have always been looked at for improvements. I will, however, admit that the culture of DevOps frequently does make people more aware of such tools significantly owing to the fact that more people are talking about such tools even if the erroneously refer to them as "DevOps Tools".

--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)

funbi SSCarpal Tunnel Points: 4992 More actions · Answer 7

Jeff Moden - Monday, July 2, 2018 6:27 AM
funbi - Monday, July 2, 2018 4:33 AM
You can do it without specialised tools, but it is EASIER with them. There are a lot of tools out there that have been developed relatively recently that facilitate DevOps and have been created specifically for this culture shift in IT.
There's no question in my mind that the various jobs in IT are easier with tools. But, I disagree about the tools suddenly becoming available because of DevOps. Such tools have always been available and such tools have always been looked at for improvements. I will, however, admit that the culture of DevOps frequently does make people more aware of such tools significantly owing to the fact that more people are talking about such tools even if the erroneously refer to them as "DevOps Tools".

We may just be arguing semantics 🙂 but when the software providers themselves refer to their tools as "DevOps tools" (e.g. Microsoft) then perhaps this is indeed why they were written. But yes it is a culture & mindset as well.

Rod at work SSC-Dedicated Points: 33898 More actions · Answer 8

Interesting article. I'm going to be following the discussion with interest. From a developer's point of view, I think DevOps is somewhat easier. I understand the tools that can be used, at least in the Microsoft world of things, but I'm sure the same is true in other development stacks. What I don't understand so well is how DevOps is done from operations side. Using Microsoft's tools as an example, if you're working on improving an SSIS package, for example, do you track progress in Visual Studio Team Services (VSTS)? Or what do you do?

Kindest Regards, Rod Connect with me on LinkedIn.

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

I think you're being pendantic and picky, Jeff.

Hammers existed before we worked with wood. Does that mean they're not caprpenter's tools? We had spanners (wrenches) for machines before they were used for cars, does that mean they're not auto mechanic's tools?

Many of these tools existed before, but they're being used in , and marketed for, DevOps. That doesn't mean they make up what DevOps is or ensure you're "doing" DevOps. That certainly is culture and practice, but they are still DevOps tools.

Or they're tools you use to slowly build waterfall designed, poor quality software. The choice is yours.

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

Rod at work - Monday, July 2, 2018 9:02 AM
Interesting article. I'm going to be following the discussion with interest. From a developer's point of view, I think DevOps is somewhat easier. I understand the tools that can be used, at least in the Microsoft world of things, but I'm sure the same is true in other development stacks. What I don't understand so well is how DevOps is done from operations side. Using Microsoft's tools as an example, if you're working on improving an SSIS package, for example, do you track progress in Visual Studio Team Services (VSTS)? Or what do you do?

I'd argue SSIS package development is a dev item, but certainly you should be using version control to track changes. This is hard in SSIS, but having the binaries of each package and some comments of the changes means that you can at least find an older version if you need it. Comparing them is hard, but you'll have something.

For tracking progress, what do you mean? The work to be done? The development changes? If you're managing work, DevOps asks that you have some transparency on what work is coming (upstream), what work is in progress (WIP), and what is being delivered (or has been) to clients. This could be post its on a wall, something like Microsoft Project, or anything else. The important thing is that anyone trying to triage and plan work knows what's being done and what else is in queue. They can use this to reorder the flow of work.

The person doing the work sees what's coming and also what's delivered, hopefully with feedback from downstream. Was this deployable? did this cause any performance issues? Any metrics not being tracked? Do clients like it and/or use it? Those are items that help the person building understand how they're doing as well as manage their workload.

For Ops, you want to know what's coming, as well as find ways to improve the product, track metrics, maybe add instrumentation, ask for more logging, etc.

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

Steve Jones - SSC Editor - Monday, July 2, 2018 9:20 AM
Rod at work - Monday, July 2, 2018 9:02 AM
Interesting article. I'm going to be following the discussion with interest. From a developer's point of view, I think DevOps is somewhat easier. I understand the tools that can be used, at least in the Microsoft world of things, but I'm sure the same is true in other development stacks. What I don't understand so well is how DevOps is done from operations side. Using Microsoft's tools as an example, if you're working on improving an SSIS package, for example, do you track progress in Visual Studio Team Services (VSTS)? Or what do you do?
I'd argue SSIS package development is a dev item, but certainly you should be using version control to track changes. This is hard in SSIS, but having the binaries of each package and some comments of the changes means that you can at least find an older version if you need it. Comparing them is hard, but you'll have something.
For tracking progress, what do you mean? The work to be done? The development changes? If you're managing work, DevOps asks that you have some transparency on what work is coming (upstream), what work is in progress (WIP), and what is being delivered (or has been) to clients. This could be post its on a wall, something like Microsoft Project, or anything else. The important thing is that anyone trying to triage and plan work knows what's being done and what else is in queue. They can use this to reorder the flow of work.
The person doing the work sees what's coming and also what's delivered, hopefully with feedback from downstream. Was this deployable? did this cause any performance issues? Any metrics not being tracked? Do clients like it and/or use it? Those are items that help the person building understand how they're doing as well as manage their workload.
For Ops, you want to know what's coming, as well as find ways to improve the product, track metrics, maybe add instrumentation, ask for more logging, etc.

I see what you're saying better. In my environment I don't have access to SSIS, but I'm sure many developers do, so that's a wash.

When I was talking about tracking progress I was thinking of VSTS's work items, etc. But you make an excellent point that it doesn't have to even be in some software solution. It could be done using Kanban boards, with sticky notes on a wall somewhere. And I'm sure there's other means of doing DevOps, besides using VSTS for project management.

Kindest Regards, Rod Connect with me on LinkedIn.

Jeff Moden SSC Guru Points: 1003857 More actions · Answer 12

Steve Jones - SSC Editor - Monday, July 2, 2018 9:03 AM
I think you're being pendantic and picky, Jeff.
Hammers existed before we worked with wood. Does that mean they're not caprpenter's tools? We had spanners (wrenches) for machines before they were used for cars, does that mean they're not auto mechanic's tools?
Many of these tools existed before, but they're being used in , and marketed for, DevOps. That doesn't mean they make up what DevOps is or ensure you're "doing" DevOps. That certainly is culture and practice, but they are still DevOps tools.
Or they're tools you use to slowly build waterfall designed, poor quality software. The choice is yours.

Perhaps a bit pedantic because I'm a bit tired of companies selling snake-oil under the guise of "DevOps". It's more like "lets see how much of a premium or extra business we can get because we know of an important buzz word that many don't know the actual meaning of". It happens every bloody time the industry is affronted with the buzzword du jour.

Your hammer example is a perfect example of what I'm speaking of. The tools have always existed... the application for those tools has not. But call it a "DevOps" hammer and it's sure to sell better. And, to be sure... people also make the mistake of comparing people who work in DevOps to carpenters. DevOps isn't a person, place, or thing like carpenters, carpentry, and hammers are. DevOps is a culture that actually requires no tools to successfully implement.

And, good grief... have you seen all the job titles that have sprung up with the word "DevOps" in them? It's really gotten ridiculous.

--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)

Eric M Russell SSC Guru Points: 125520 More actions · Answer 13

When we're talking about DevOps in this context, it's sounds like we're talking about a change tracking process that integrates database development and administration; something like JIRA / BitBucket / Octopus Deployment ?

"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho

Steve Jones - SSC Editor SSC Guru Points: 734434 More actions · Answer 14

Jeff Moden - Monday, July 2, 2018 12:16 PM
Perhaps a bit pedantic because I'm a bit tired of companies selling snake-oil under the guise of "DevOps". It's more like "lets see how much of a premium or extra business we can get because we know of an important buzz word that many don't know the actual meaning of". It happens every bloody time the industry is affronted with the buzzword du jour.
Your hammer example is a perfect example of what I'm speaking of. The tools have always existed... the application for those tools has not. But call it a "DevOps" hammer and it's sure to sell better. And, to be sure... people also make the mistake of comparing people who work in DevOps to carpenters. DevOps isn't a person, place, or thing like carpenters, carpentry, and hammers are. DevOps is a culture that actually requires no tools to successfully implement.
And, good grief... have you seen all the job titles that have sprung up with the word "DevOps" in them? It's really gotten ridiculous.

There are always people that take advantage of this, but plenty of companies are selling products as "DevOps", but not charging some premium. The costs of things like Octopus Deploy or Build servers haven't gone up in many cases. They're just using new language to describe tools that were used in other applications.

A build server was used for automation of software assembly, long before it was called DevOps. There are people that have used these tools for things like the Daily Build.

DevOps certainly requires some tools. What it doesn't require is for you to purchase anything or pick any particular tool. You'll need some set of tools to put your culture into practice.