March 25, 2024 at 12:00 am
Comments posted to this topic are about the item Another View of DevOps
March 25, 2024 at 11:02 am
There's an element of cargo cult and John Frumism with regard to DevOps and the same is true of Agile development too. The performance of rituals is seen as an end in its own right, rather than those rituals being a means to an end.
My 1st introduction to the Agile world was extremely negative. In fact it was a thing that had been labelled as Agile but emphatically not. If I had not come across The Art of Agile Development by James Shore and Share Warden and read James's blog posts I would have written the whole thing off as a lazy cowboys excuse to slap dash ill thought out rubbish into production.
Fortunately I not only read James's book, I came across Ron Jeffries, Bob Martin, Grady Booch, Tim Ottinger, Allen Holub, Kent Beck and a number of others. From them I got that what Agile was always supposed to be was a set of disciplines (not rituals) and principles (flexible guidance, not rigid dogma).
The relevance of this to DevOps is the shift to a more flexible mindset I went through from my 1st impressions of Agile to respecting the thought and true disciplines behind it.
It is moving from "That won't work" to "The benefits of being able to do that are extremely valuable. We know that it is possible because others have successfully achieved this. We don't yet know how to implement it though given that we know it is possible and valuable we will look at how could work for us and address what changes to our ways of working will be necessary to ensure that it does!"
At the time we were using a DB platform for which there was very little tool support. With a flexible mindset we worked out a lot from 1st principles
I was fortunate in that I had the trust and respect of my senior peers. They informed the foot draggers that this was going to happen, there was no option to fall back to their comfortable old status quo.
March 25, 2024 at 2:51 pm
Seniors and leaders have to support change to get change to work. Ultimately a lot of what is in DevOps is stuff I did in '99/2000 with small companies.
That's a lot of what Redgate does now for customers, though a few decades later. However, having leadership support and a smart set of people made this possible. It's possible anywhere, though using standard tools makes it easy when the smart person leaves or you need to support new/changing features
March 25, 2024 at 3:05 pm
I like this article a lot. And like David Poole said, DevOps isn't a dogma so much as a principle to follow, with flexibility in mind.
The three pillars of DevOps are tools, people, and processes in alignment to bring value to our customers. From my experience I sometimes see a willingness by companies to buy the tool(s), but then stop there. DevOps will fail at a company, if people aren't willing to change and processes are rigid.
Kindest Regards, Rod Connect with me on LinkedIn.
March 25, 2024 at 3:17 pm
Redgate tools have always been great tools at a reasonable price. The company I used to work for decided to move away from Microsoft and I'd say one of the biggest pain points was losing the Redgate tools. I was and remain a big fan of Redgate, whether it be the tools or the people.
That said, simply seeing how Redgate Source Control worked gave us a lot of ideas as to how to implement DB source control.
I was surprised that RedGate did not go down the plug-in route with things like Redgate SQLDoc. I had to write my own equivalent and my approach was to have a set of queries that conformed to a standard contract across all the DB platforms I wanted to document. All I had to do was to get a suitable ODBC/JDBC driver and the right connection string to point the tool at different DB platforms.
March 25, 2024 at 3:21 pm
Plugins were a problem to maintain. I wish SQL Doc got more love, unfortunately, few people use it. I find far too many people just don't create any documentation (esp vendors)
March 26, 2024 at 10:18 am
I notice that this year's DORA report is explicit in calling out the availability of quality documentation as being a significant factor in high performing teams.
I notice that Pragmatic Works used to have a tool for documenting SSIS but now they are an IT training company rather than a tool maker.
From my perspective having business and/or technical commentary on DB and data flow objects:-
For a sizable data warehouse project that recognises the need for a data catalogue the absence of those business and technical descriptions jeopardises the entire project.
I hope that DORA calling out that documentation is a significant contributor to high performance will be a game changer but I think, sadly, that gaining acceptance is like trying to push water uphill with a fork.
March 26, 2024 at 10:59 am
David, are you referring to Digital Operational Resilience Act (DORA) or Dora the explorer?
March 26, 2024 at 11:17 am
David, are you referring to Digital Operational Resilience Act (DORA) or Dora the explorer?
Dr Nicole Forsgren wrote Accelerate which explains the science behind the 4 DORA metrics. Half the book explains it in business speak, the 2nd half goes into more technical details. The metrics that were found to have the most significance of indicating high performance teams were as follows.
March 26, 2024 at 2:29 pm
Pragmatic works tools got sold to Sentry One (now Solarwinds) : https://documentation.solarwinds.com/en/success_center/databasemapper/content/sources/ssis.htm
Viewing 10 posts - 1 through 9 (of 9 total)
You must be logged in to reply to this topic. Login to reply