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?
If you’re running collectd chances are you’ve struggled or are struggling with the web frontend. The one shipped with collectd has some limitations and most people tend to use 3rd party solutions. Graphite has its own storage system called whisper, so here are some things elated to that.
We often talk about tension caused competing bonus / success structures for development and operations teams in the build and release process. At Gartner IOM Cameron Haight framed this using the classic Prisoner’s Dilemma concept from game theory. I wanted to elaborate on that idea.
This was an interesting exercise, especially since I’d had caching and Puppet on the radar for quite some time now but I had not actually had a chance to use it or investigate it. The work paid off and will let our system scale up a whole lot more.
Establishing a devops platform in an enterprise environment is challenging because there are a bunch of groups who own different pieces of the puzzle, and they will generally have different ideas on how to move forward. But there’s a way to pull it all together into a coherent, integrated data and tools platform, and this post will explain how my colleagues and I are doing it.
I got my hands on the Definitive Guide to Drupal 7 that talks about Drupal use with Vagrant. I decided to take on this opportunity to automatically manage my own Drupal infrastructure.
In this post I will show how we are using Jenkins to pull a versioned binary out of Nexus and deploy to one of our remote test, staging or production Glassfish servers. By remote I mean that the Glassfish instance does not live on the same box as the Jenkins CI instance, but both machines are on the same network.
Continuous Delivery is all about setting up your development processes such that you can deliver into production much more frequently than is typical, perhaps with multiple releases per day. Here are 7 points I took away from a recent presentation...
I decided to see if RVM – Ruby Version Manager – would allow me to setup an isolated Ruby environment just for graylog2 and not disturb the other Ruby apps on the machine. I also wanted to setup an isolated instance of Passenger-standalone for graylog2 then configure apache to listen on port 80 and forwarding requests with mod_proxy.
Having a good Continuous Integration setup is the gift that keeps on giving, but what about your database? For most web applications these days, your database is a large part of your application – so why is versioning it such an uncommon thing?
“Availability is the most important thing…” I heard this recently and I cannot agree with it. It sounds good, until you think about all the things that become less important things when you say something like that.
A look at this week's news about Azure Linux support, multiple price drops by cloud providers, the Flame exploit, IPv6 growth, and what the browsers of the future will need to speed up the web.
For some, the task of automated deployments seems either too difficult, too time consuming to setup or is perceived as un-needed. I’m about to attempt to prove all of these things wrong, while at the same time allowing you to get back to doing what you do best: write code.