In case you missed them, here is a curated list of of the best articles from this week's edition DZone's DevOps Zone. This week: 31 reference architectures for DevOps and Continuous Delivery, why you shouldn't apply the 8-20 rule, making fun of your AngularJS tests, why security IS DevOps, and how to reduce risk in web development.
If you have been drawn to the evangelists like David Farley, Jez Humble, and Gene Kim, you’ll know that high performance IT organizations are seeing a massive payoff in their continuous delivery investments. To help you along your continuous delivery and DevOps journey, I have compiled a set of 31 reference architectures created by users across the continuous delivery and DevOps communities.
I’ve written about the 80-20 rule several times because it keeps coming up. The general principle is that a large portion of your results come from a small portion of your inputs. The 80-20 rule sounds too good to be true. If 20% of inputs are so much more important than the others, why don’t we just concentrate on those? Here's why:
The bottom line is to avoid complexity (when a component calls a component calls a component) also isolate your components so they each have one responsibility, then mock your dependencies. You may even grow to enjoy testing more!
Security is DevOps, but many think it’s not the case. Different teams collaborate to quickly and swiftly bring a product to fruition in the DevOps world. However, it’s often felt that Security will slow the process down. In this post I’m going to explain why it’s important that Security is at DevOps collaborative table, and how it fits within DevOps realm.
Web development can be an inherently risky endeavor. While the costs to get up and running with a development environment are almost non-existent, every choice you make as you build your application has long-term effects on your technology stack, your application’s performance, and the expertise available to you as you build a development team. Below we’ll look at a few strategies for reducing the risk inherent in web development.