How to start a DevOps project: Pick the low hanging fruit and just go for it

Source:- computing.co.uk

The best way to launch a new DevOps project is simply to pick the low-hanging fruit, or what should be a relatively simple and necessary body of work, and just go for it, without spending months in planning.

That’s the opinion of Steven Armstrong, principal DevOps automation engineer at Paddy Power Betfair (pictured). Armstrong was speaking at Computing’s recent DevOps Summit, where the audience was also told about a firm which handed out cricket bats to developers in order to incentivise testers to hurry their work.

When asked how he first launched a DevOps initiative, Armstrong replied “we were just able to do it.”

“We had lots of single points of failure in a big old databse under our old architecture,” said Armstrong. “So pick something like that, the low hanging fruit, and go for it. Pick something and just start on it, don’t spend a hideous amount of time in planning,” he added.

Armstrong explained that the organisation embedded Quality Assurance (QA) engineers within development teams and “shifted everything to the left”.

“You don’t want a situation where you have QA reacting to development changes. Then testing runs will fail because the devs introduced a new GUI or something. So we moved teams together and then when the devs were developing code, QA were embedded there to help at the point when they were defining the user story. So you’re writing the test criteria along with the requirements and design. That’s really important, because you can’t have siloed departments that are purely reactive any more,” he explained.

Gordon Gracie, development team lead at insurer LV= agreed.

“The biggest injustice you can have today is the idea of QA people in a separate role,” said Gracie. “Software engineers want to write great code. If the engineer is obsessed with quality, they’re also obsessed with testing that quality. Some people are experts in testing, but the idea of separate teams doing that work needs to be broken down. If you have that set up, you’re creating a culture that stops your engineers moving to a DevOps model,” he argued.