|
The post’s argument is illogical. It doesn’t follow from wanting to speed things up for other teams that you can avoid some kinds of testing in the pipeline by having monitoring. That makes no sense. It also says a full test suite in the pipeline is not needed because there should be monitoring in production. Monitoring doesn’t catch all bugs, and letting things fail at a later stage isn’t the right path for a CMM level 5 application that lives and/or serious investment depend on. Granted, while application monitoring puts additional ongoing load on the application, which slows it down, going against the desired goal of speed, it can help to have application monitoring that may identify slow, insecure, or error prone queries. However, that shouldn’t have to run constantly unless it has low overhead. Also, if problems are just reported after deployment and aren’t a gate to deployment, then you’ll keep pushing crap code into production. So, what I’m reading here is that Dev Ops, as defined, values getting things through the pipeline quickly, so that when bugs, security, and performance problems are found, those aren’t a Dev Ops problem, and those production issues can be handled by developers, because they’ll have fast feedback from monitoring that maybe they didn’t kill someone yet? |