Somewhere along the way our industry shifted this discussion into a tools discussion & now the amount of noise out there about “DevOps tools” is magnitudes higher than any discussion about the real reason DevOps exists – to shift culture.
It is a good idea to virtually burn down your servers at regular intervals. A server should be like a phoenix, regularly rising from the ashes. The primary advantage of using phoenix servers is to avoid configuration drift.
In our Enterprise Continuous Delivery Maturity Model we looked at the idea of continuous deployments to production and flagged the process as “Extreme”. It’s just too much for too many teams. A decade ago, I might have said the same thing about continuous integration.
Net Applications updates the Browser Wars stats — currently IE still hanging on strong with 54% of the market share while Chrome is creeping up on Firefox’s 2nd place lead (19% to 20%, respectively).
Its really not that hard; you just need someone to take a breath and plan. The part of monitoring that sucks is the human part, and since your app will not tell people when its up and down, you need a person to think about that for you.
A good discussion came up at DevOps days about whether or not development shops should just eliminate operations if the organization has small-scale IT needs.
Development and Operations are both critical to IS/IT usage in an organization, but developers often look at operations as something alien – from another planet (and operations have the same view on developers). As we'll see, this couldn't be less true.
Apache Mahout is a scalable machine learning framework that can be used to create intelligent applications. In this article we’ll see how Mahout can be used to create personalised recommendations within a Grails application.
Culture is like quality. You don’t build culture, or quality, by talking about it. You build it by doing things, by acting, by making things happen and making things change, and reinforcing these actions patiently and continually over time.
Since several of the commands require having write access to ‘root’ folders we need to run ‘puppet apply’ as a super user using sudo.
Operations teams are tasked with stability and uptime. That means working against change, limiting or slowing it down where possible.
A straightforward, whiteboard presentation of how the DevOps cycle works in the enterprise. Jody Hunt of BMC explains...
These reports are great and it’s easy to configure but you need to make both a dollar investment in the software and an education investment to really understand the metrics and how they relate to code quality. What’s nice about StatSVN is that it’s free and it doesn’t take a lot of thinking to use it.
We wanted to establish a list of some of the best Twitter personalities to follow about DevOps, web performance, and development. So here's a list of 10.
In the software world, development and QA are often organised into two separate teams. Some issues may bounce between the teams multiple times before they reach resolution and the release can ship. As a developer, this has always struck me a hugely inefficient workflow.
Sometimes it might be nice to be able to test a DNS server’s output, such as with a continuous monitoring system, or as a validation tool when migrating to a different DNS server (or service.) Here's a little snippet I use
Basically the script just iterates over a list of VMs which are in a particular resource pool, and reverts them all to a snaphot. Here’s the script itself...
After Oliver Hookins struggled with scheduling and managing downtime sessions, he decided to create an extremely simple RESTful API for manipulating Nagios scheduled downtime.
Here’s a selection of great DevOps-related blogs and books. There’s also a Google Reader bundle or RSS feed that you can use to subscribe at the bottom of that section.
This is a quick how-to post for Opsview users who have a need to monitor MarkLogic.
If you use Puppet in the client-server mode to configure your production environment then you might want to be able to copy & paste from the prod configuration into the Vagrant’s standalone puppet‘s configuration to test stuff.
Tools are important, people and relationships are importanter (new word), you should automate everything, take little steps instead of big ones, stick to the principles of continuous delivery. Here's my recent little case study on a client that wanted to implement CD...
This article is about measuring the Development cost of a Deployed Feature (DECODEF). This is probably the easiest figure to measure as, conceptually, is just the multiplication of man days times the average cost of your resources.
I work with “The Enterprise” everyday. Sadly, this has nothing to do with Star Trek – just big companies with lots of internal politics. As our friends champion our products internally,the political challenges are often tougher than the technical ones. If politics is going to be a barrier, it’s fair game to use political theory to fight back.
An indispensable IT ops measurement is FALT, (Feature Average Lead Time). What kind of measure is this and why is it important?