Stories
Slash Boxes
Comments

SoylentNews is people

posted by on Monday January 16 2017, @05:47PM   Printer-friendly
from the bingo! dept.

Submitted via IRC for TheMightyBuzzard

In today's fiercely competitive environment for customer satisfaction and brand loyalty, agile and DevOps are driving happier customers and employees. Results from a new CA Technologies global study reveal that advanced users of agile or DevOps realized significant increases of up to 52 percent in customer satisfaction and up to 50 percent in employee productivity.

The results showed a 30 percent advantage in employee recruitment and retention for companies that used agile and DevOps together to improve the working atmosphere for their employees – a huge benefit when you consider the shortage of talent in IT and the costs associated with attracting and retaining the best employees.

I guess I can't argue against it since I've been doing it nearly everywhere I've worked since the late 90s. Having separate Dev/Ops teams in SMBs [Small and Medium Businesses] is a pretty hard sell.

Source: https://www.helpnetsecurity.com/2017/01/12/devops-adoption/


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 3, Interesting) by meustrus on Monday January 16 2017, @09:42PM

    by meustrus (4961) on Monday January 16 2017, @09:42PM (#454537)

    I find it really unfortunate what people around here think DevOps means. Where I am, DevOps means that devs have access to infrastructure and can provision what they need. It takes good tools to give that kinds of access without worrying about whether devs understand the nuances, sure. But we have good tools, mostly based on AWS.

    DevOps shouldn't mean that devs need to design the data center. It should mean that devs can develop the infrastructure scaling code as well as the code that is being scaled. It means that devs can manage their own Jenkins servers and not have to make cross-department requests to change a plugin configuration.

    --
    If there isn't at least one reference or primary source, it's not +1 Informative. Maybe the underused +1 Interesting?
    Starting Score:    1  point
    Moderation   +1  
       Interesting=1, Total=1
    Extra 'Interesting' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   3  
  • (Score: 2) by jelizondo on Monday January 16 2017, @10:35PM

    by jelizondo (653) Subscriber Badge on Monday January 16 2017, @10:35PM (#454572) Journal

    Then you get devs who have configured their infrastructure in such a manner that is not deployable because it breaks other services or applications in the production environment.

    As Thexalon [soylentnews.org] pointed out, the two fields are separate and unless you’re running a small organization, they should be separate for the same reason you wouldn’t want a general M.D. performing surgery on you.

    Yep, it’s a pain in the arse having to request thru the sysadmins whatever you need, but it saves a lot of pain down the road for everyone.

  • (Score: 3, Interesting) by rleigh on Monday January 16 2017, @11:12PM

    by rleigh (4887) on Monday January 16 2017, @11:12PM (#454591) Homepage

    One thing that I think the devops way of doing things ignores is that we aren't all generalists and interchangeable cogs. While I can sit down and learn all the tools (and in fact already do know some of them well), it's not a very effective use of the time and expertise people already have.

    As a developer, I don't really want to have much to do with setting up jenkins, provisioning, chef/puppet/ansible and all the rest of the glue that makes this stuff go. I already have one full time job which requires significant expertise; I don't need another two or three on top of that. It's one thing to lend a hand and create or tweak a job to test and deploy your stuff, or fiddle with a VM, install a missing packages etc, but maintaining the whole thing end to end is just too much, IMHO. You could employ a sysadmin or ops person to do this; they would likely be better at it!

  • (Score: 2) by Thexalon on Monday January 16 2017, @11:30PM

    by Thexalon (636) on Monday January 16 2017, @11:30PM (#454601)

    Where I am, DevOps means that devs have access to infrastructure and can provision what they need. It takes good tools to give that kinds of access without worrying about whether devs understand the nuances, sure. But we have good tools, mostly based on AWS.

    Then what it sounds like you are doing isn't DevOps, what you're doing is outsourcing a lot of the "Ops" side to Amazon. That can certainly work, but that's not the same thing as having nobody focused on infrastructure: Just because the people doing it aren't working for your company does not mean nobody is doing it.

    I agree that devs could and quite possibly should develop the infrastructure scaling code. But the ops side should be designing the specifications of said infrastructure scaling code, as well as having input on the specifications for the code being scaled so that it does so more easily. And that still leaves ops plenty of other things to do, like hardware maintenance (if you have any of your own hardware), security management, backups / disaster recovery, and of course figuring out how to best give the devs what they need to fulfill the latest silly requirements imposed by marketing.

    --
    The only thing that stops a bad guy with a compiler is a good guy with a compiler.