February 10, 2017 at 8:19 am
Im a year into learning devops as I write this and from what I've seen the premise is reasonable, but as in all methodologies it matters how you implement it. Going from monthly releases on Sun night to weekly releases during the day requires a lot of process work but also some mindset change and revisiting how we managed risk. Weekly releases - for us - don't drive urgency, if anything its the opposite. Before we often delayed to get one more thing in or it would have to wait another month, now it goes the week its ready.
February 10, 2017 at 12:42 pm
roger.plowman - Thursday, February 9, 2017 6:49 AM...But that's not the case. DevOps is aimed at continuous feature release, not security. The more features you add, the more attack surface you add. DevOps encourages an insane development cadence, an insane user version cadence, and that is heaven for bad guys looking for bugs.
...
It's also a potential problem to users who, surprisingly, view the software as a tool to get the job done. They are not interested in geekdom. The LAST thing they want is an application that works differently this week than last week.
...
-- FORTRAN manual for Xerox Computers --
February 11, 2017 at 1:24 am
jay-h - Friday, February 10, 2017 12:41 PM...It's also a potential problem to users who, surprisingly, view the software as a tool to get the job done. They are not interested in geekdom. The LAST thing they want is an application that works differently this week than last week.
...but they are interested in it working.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
May 9, 2017 at 5:42 am
roger.plowman - Thursday, February 9, 2017 6:49 AMColor me suspicious.If DevOps was limited to security (i.e. continuous patching of a stable base) then it would probably be a net benefit.
But that's not the case. DevOps is aimed at continuous feature release, not security. The more features you add, the more attack surface you add. DevOps encourages an insane development cadence, an insane user version cadence, and that is heaven for bad guys looking for bugs.
The real issue with rapid cadence is lack of time for testing, lack of time for the good guys to understand the code in depth. Automated tests are good for catching the known attack vectors and preventing feature breakage. They do squat all for unknown vectors. Thus all the emphasis on discovering and exploiting 0 day bugs by the bad guys.
DevOps is a prime example of over-driving your lights.
I get the impression that you don't understand devops.
If it's done right, there's no lack of time for testing. A point you have missed (perhaps Steve's article doent mke it clear) is that there should be no faluts that get from developments own testing to final qulity testing and validtion - any time such fault occurs the unit testing and system testing in development has to tighten up its testing methods to ensure that a similar fault can't get past them in future. Heavyweight testing in development is one of the biggest dvntages of a devops approach - there's continuous improvement of testing methods as well as continuous release. In my experience, a continuous relese process spends more time on testing and much less time on fixing bugs than the other systems I've had the misfortune to be stuck with. And in my experience it also leads to more customer satisfaction, because they get working stuff with regular updates and very few bugs instead of rare releases that contain a new set of bugs that's larger than the set of bugs reminaing unpatched in what they are replacing.
Automated tests should never be the only form of testing; but there should be a lot of them, they should probably count for the majority of testing. It would be good if we could use code anlysis to detect holes, but as most code is written in lnguges with totally broken type systems where it's impossible to know whether something you are pointing at has the type you think it has (C, C++, etc) that's usually impossible.
The idea that continuous release gives attackers a better chance is just plain crazy; it reduces the window during which any security hole is available (whether it's fixed accidentally or intentionally) which reduces the attackers chance of finding a hole before it's shut.
Overdriving your lights was extermely common in the days of the waterfall approach, where it was absolutely the norm to release software with faults that your QA process had discovered in the hope that no-one else would discover them before you issued a patch. I'm sure that the traditional anti-continuous mad rush for an unachievable deadline is much more likely to cause light jumping than anything in devops.
Tom
May 9, 2017 at 8:01 am
roger.plowman - Thursday, February 9, 2017 8:39 AMKind of hard to say no to the people that sign your paycheck tho.Mentoring only works if they *believe* you. When sales people have the C-level ear, well, money talks and BS walks, right?
Yes, I remember it being kind of hard when I was young and unhardened. But by the time I hit 30 I changed my mind and when my employer tried to put me into an ivory tower where I couldn't rock the boat I rebelled - asked for a reference as I planned to go elsewhere; instead of a reference the employer gave me (i) a 25% pay-rise, plus better terms on my pension fund and (ii) a job of the sort I wanted (to take over and rescue a development group that was in the shit and had gone through 5 managers in the last 15 months - the only snag was that I would be based in England instead of Scotland). That firmly confimed my new idea that saying "no" wasn't a bad idea after all (and I wish I'd understood that a lot earlier). I've seen places where saying "no" to management was a crime, probably a sacking offence, but I would never want to work in one and I can't imagine why anyone would want to stay in one rather than find somewhere where the management is willing to listen.
Mentoring usully works if you don't ram it down their throats,and don't play the attitude that you are some sort of deity compred to their plebeian status. If someone sks you "why should I lern this crud" either ignore it or tell them why - don't react as if it were a meaningless or offensive question. There's a very small minority of people who just don't want to learn. The best thing to do with that minority is probably to fire them, but that's not a decision to be taken by the mentor.
Tom
Viewing 5 posts - 16 through 19 (of 19 total)
You must be logged in to reply to this topic. Login to reply