March 18, 2017 at 11:15 am
Comments posted to this topic are about the item Why DevOps? Employee Satisfaction
March 20, 2017 at 1:57 am
Totally agree. For me I think that developers don't believe that the time spent releasing software is what they wanted as part of their career. Us developers just want to code. We tend to be pragmatic enough to realise that it also has to be used (and there is satisfaction in that too) so we understand that it needs to be released. We also get that we are part of the collective who know what needs to be done to get it installed. Too much time spent on release is considered as time wasted in a developer's mind. At least the ones I have known - including myself.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
March 20, 2017 at 2:33 am
I have tried to find out what is actually DevOps for some times now. Please can someone tell me what is DevOps in the context of a BI Developer or a DBA? I've seen many definition but they are so vague that everyone working in dev can claim to be working as in DevOps context. If you had a SQL DBA or BI dev coming for an interview and wanted to know if this person has worked using DevOps methodoly, which questions would you ask? What answers would you expect?
March 20, 2017 at 5:50 am
.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
March 20, 2017 at 5:52 am
Kyrilluk - Monday, March 20, 2017 2:33 AM...everyone working in dev can claim to be working as in DevOps context...
That is the key. Everyone IS working in DevOps and everyone is responsible for the whole release cycle. Sure, people will be more and less responsible for different areas but no one can say "Problem with the release? Nothing to do with me".
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
March 20, 2017 at 5:58 am
When it works, it's brilliant.
March 20, 2017 at 8:45 am
I work in State government, which in our state is traditionally waterfall in practice. I've brought up trying to do some DevOps but it has met with resistance. The single, most important thing, to the way we handle things is that any and every project must have a very detailed, exhaustively written Requirements Document! That Requirements Document is the Word of God! And if it takes 9 months to finish a requirements document, so be it. Even though I've been in this position for almost 2 years I still don't entirely grasp all of the reasons why the Requirement Document is So All Important. I've had various guesses as to what the reason(s) is(are), but I really don't entirely know. I understand that even agile software development allow for writing a requirements document, but that it doesn't insist that it must be as completely detailed and filled out as the department I work for demands.
The result of insisting that a requirements document be as detailed as we require is that often the users making requests of us to do something, can't wait around for as long as this process takes. So they go off and do their own thing, resulting in even more headache and trouble for us. But who can blame them. There aren't many places that can wait a year before someone is allowed to open up Visual Studio and start writing the app.
Kindest Regards, Rod Connect with me on LinkedIn.
March 20, 2017 at 8:55 am
Kyrilluk - Monday, March 20, 2017 2:33 AMI have tried to find out what is actually DevOps for some times now. Please can someone tell me what is DevOps in the context of a BI Developer or a DBA? I've seen many definition but they are so vague that everyone working in dev can claim to be working as in DevOps context. If you had a SQL DBA or BI dev coming for an interview and wanted to know if this person has worked using DevOps methodoly, which questions would you ask? What answers would you expect?
DevOps is somewhat amorphous. There are a couple definitions I like:
Donovan Brown - “DevOpsis the union of people, process, and products to enable continuous delivery ofvalue to our end users.â€
Gene Kim - The basic principles of DevOps are the three ways: Systems Thinking, Amplify Feedback Loops, and Culture of Continuous Experimentation and Learning.
What is DevOps for a DBA? Are you ensuring reliability and repeatability? Are there regular processes that depend on your knowledge to complete or can anyone run them? DevOps involves working closely with developers to help them produce consistent, reliable databases that they can use for development, helping them package up code, tracking versions, ensuring (as much as possible) an automated way to deploy code that works in your environment. We maximize value streams by ensuring the flow of code is efficient. This often means releasing code more often, that is of a higher quality than in the past.
For a BI Developer? You work with operations to ensure your dev/test systems are provisioned and consistent with production configurations. You package code so that changes are easily deployed, meeting the needs of Operations to reduce the risk. You include automated testing that checks your code to ensure it meets the requirements of your customers.
It's tough. DevOps isn't prescriptive. There aren't specific things you do. It's about ensuring that you are always looking for improvement and building a better system, regardless of whether you use Agile, Scrum, Lean, ITIL, or some other methodology to build and deploy software.
March 20, 2017 at 1:01 pm
I agree for the following reasons.
Imagine that you are a developer who has worked their heart out to build something as best they can with the information they are allowed to see. How would you feel if your work was described as a turd lobbed over the wall?
Imagine that you are an operations guy carefully juggling resources to ensure that you have 24/7/365 uptime. How are you going to feel if some resource hungry nightmare lands in production and you are told that it is now your problem for the rest of your tenure?
One deliverable, two miserable people. The first toe in the water with DevOps I saw came about as a result of a heated discussion between the two parties. The ops guys were pointing at their monitors proclaiming that the problems were obvious to anyone who could read a graph. The DEV response was "Great, but you won't let us have access to those graphs and won't pay for the tooling in environments other than production. It soon became apparent that the devs would be only too happy to lessen the impact of their development but what they had to predict impact was as much use as a horoscope.
March 21, 2017 at 6:04 am
DevOps is the new buzzword to replace Agile... 😛
It means that I get to add 2 more jobs to the 3.4 I already do...
March 21, 2017 at 9:09 am
Steve Jones - SSC Editor - Monday, March 20, 2017 8:55 AMKyrilluk - Monday, March 20, 2017 2:33 AMI have tried to find out what is actually DevOps for some times now. Please can someone tell me what is DevOps in the context of a BI Developer or a DBA? I've seen many definition but they are so vague that everyone working in dev can claim to be working as in DevOps context. If you had a SQL DBA or BI dev coming for an interview and wanted to know if this person has worked using DevOps methodoly, which questions would you ask? What answers would you expect?
DevOps is somewhat amorphous. There are a couple definitions I like:
Donovan Brown - “DevOpsis the union of people, process, and products to enable continuous delivery ofvalue to our end users.â€
Gene Kim - The basic principles of DevOps are the three ways: Systems Thinking, Amplify Feedback Loops, and Culture of Continuous Experimentation and Learning.What is DevOps for a DBA? Are you ensuring reliability and repeatability? Are there regular processes that depend on your knowledge to complete or can anyone run them? DevOps involves working closely with developers to help them produce consistent, reliable databases that they can use for development, helping them package up code, tracking versions, ensuring (as much as possible) an automated way to deploy code that works in your environment. We maximize value streams by ensuring the flow of code is efficient. This often means releasing code more often, that is of a higher quality than in the past.
For a BI Developer? You work with operations to ensure your dev/test systems are provisioned and consistent with production configurations. You package code so that changes are easily deployed, meeting the needs of Operations to reduce the risk. You include automated testing that checks your code to ensure it meets the requirements of your customers.
It's tough. DevOps isn't prescriptive. There aren't specific things you do. It's about ensuring that you are always looking for improvement and building a better system, regardless of whether you use Agile, Scrum, Lean, ITIL, or some other methodology to build and deploy software.
That's the best description I have ever read. It's so tiring when all you see is the market hype that gets management to ask things like "How do we replace our outdated SQL servers with NoSQL?"
March 23, 2017 at 2:22 am
chrisn-585491 - Tuesday, March 21, 2017 6:04 AMDevOps is the new buzzword to replace Agile... 😛It means that I get to add 2 more jobs to the 3.4 I already do...
That can be true just like it can be true for agile (like you said). Used as a buzzword it becomes a headache like most anything else.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
March 26, 2017 at 12:39 am
Rod at work - Monday, March 20, 2017 8:45 AMI work in State government, which in our state is traditionally waterfall in practice. I've brought up trying to do some DevOps but it has met with resistance. The single, most important thing, to the way we handle things is that any and every project must have a very detailed, exhaustively written Requirements Document! That Requirements Document is the Word of God! And if it takes 9 months to finish a requirements document, so be it. Even though I've been in this position for almost 2 years I still don't entirely grasp all of the reasons why the Requirement Document is So All Important. I've had various guesses as to what the reason(s) is(are), but I really don't entirely know. I understand that even agile software development allow for writing a requirements document, but that it doesn't insist that it must be as completely detailed and filled out as the department I work for demands.The result of insisting that a requirements document be as detailed as we require is that often the users making requests of us to do something, can't wait around for as long as this process takes. So they go off and do their own thing, resulting in even more headache and trouble for us. But who can blame them. There aren't many places that can wait a year before someone is allowed to open up Visual Studio and start writing the app.
I'm with ya. A lot of people make the HUGE mistake that the requirements document should be a plan for the code and, patently, it should not! It might contain a "process" chart but it shouldn't describe how the code will be written. Too many people think that the requirements document needs to describe the "How" instead of the "What" and the "Why" and that's when you end up spending 9 months on such a document.
Then, there's what some folks call the "design document". It's an incredibly useful document if done the right way (living document rather than a rule document) but too many people don't get that, either. There's only so much you can write about before you have something to write about. 😉 It should start out as a high level document at the functional level to be able to hand to the Developers to write code to fill in the blocks. If they come across improvements, optimizations, realizations, cancellations, impossibilities, or alternatives, then that can be fed back to the design document so that everyone knows what's going on. It should never be a gating document except for the first blush and that should come out very rapidly and define any any resources that may help the Developers excel at what they're good at..
--Jeff Moden
Change is inevitable... Change for the better is not.
March 26, 2017 at 12:41 am
Ah.... and again, I have to say... if you think that DevOps is a tool, title, or method, you probably don't get DevOps. It's a culture. The term is rapidly and rabidly being bastardized to mean whatever some people think they want it to mean.
--Jeff Moden
Change is inevitable... Change for the better is not.
March 27, 2017 at 8:42 am
Jeff Moden - Sunday, March 26, 2017 12:41 AMAh.... and again, I have to say... if you think that DevOps is a tool, title, or method, you probably don't get DevOps. It's a culture. The term is rapidly and rabidly being bastardized to mean whatever some people think they want it to mean.
I hear ya. At this point I don't think I'll be a part of DevOps, at least not for quite some time. I wonder if what DevOps is might morph enough so that what was originally a race horse, by the time I get to it could best be described as a water buffalo.
Kindest Regards, Rod Connect with me on LinkedIn.
Viewing 15 posts - 1 through 15 (of 15 total)
You must be logged in to reply to this topic. Login to reply