Learn some of the neat tricks and reasons that you would want to use the open source CM tool, Chef.
For those that have to deal with release management, release train is a well-understood term. It refers to a software development schedule where multiple products are released as a part of a single ‘train’ on a regular, pre-planned schedule.
Four of the principals and laws that my company cites most frequently can help reinforce this direction and provide some needed checks as you begin transforming towards an organization whose path from idea to value (the software development lifecycle or SDLC in stodgy terms) needs to be more DevOps friendly.
In 1966 Abraham Maslow said, “I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail.” Maslow gave us all too much credit. When we have a hammer and know how great it is, we not only treat everything as a nail, we actually perceive everything to be a nail.
At XebiaLabs, many of the questions we get about our enterprise deployment automation solution Deployit are from users looking for automated deployment as a prerequisite for Continuous Delivery. Often, this is the result of initiatives to extend existing Continuous Integration tooling to support application deployments.
Tom Limoncelli has his own version of The Joel Test – except his one is for sysadmins. I was only vaguely aware of Joel Spolsky’s test and only just read through it and rated my current team, and I’m glad to say we are just about at twelve for twelve.
Another great Europe-based DevOps Day is on it's way for anyone who missed the earlier ones. It's on October 5th and 6th and it's going to be in Rome, Italy.
One of the host powerful filters in logstash is the grok filter. It takes a grok pattern and parses out information contained in the text into fields that can be more easily used by outputs. This post serves hopefully as both an explanation of why and an example of how you might do that.
My alma-mater may be better known for its football team, but the engineering fraternity Theta Tau hosts a pretty wicked egg drop competition.
The Rubygem Builds have changed along with the internal #monitoringsucks repository. All of these Vagrant projects are basically my test setups to play with those new tools.
Thanks to an errant tweet, I started playing with Riemann again. It ticks lots of boxes for me, from the clojure to configuration as code and the overloadable dashboard application. What started as using Puppet and Vagrant to investigate Riemann turned into a full-blown tool and module writing exercise.
Logging tables are usually at the periphery of a design effort, sometimes added as an after-thought. But they shouldn't be. Here's how to do it without a lot of mess...
Everybody involved in Java EE production support know this job can be difficult; 7/24 pager support, multiple incidents and bug fixes to deal with on a regular basis, pressure from the client and the management team to resolve production problems as fast as possible and prevent reoccurrences.
The most important step is to implement an architecture that supports the need to rollback. For instance, componentised, service based architectures lend themselves well to this.
Let’s take a look how the ideas of The Lean Startup and Devops enrich each other to successfully create product development flow.
In this post we are going to see how to use the JaCoCo Jenkins plugin to achieve the same goal of Ant Tasks and have overall code coverage statistics for all modules.
It’s Thursday/Friday evening, the daily version / master branch was deemed too risky to install, and you decide to wait for Sunday/Monday with the deploy to production.
In this post I am going to explain how to run code coverage using Maven and JaCoCo plugin in multi-module projects.
Your architecture now has a central service that collects all of your metrics, then pushes them to appropriate software, that doesn’t need to handle too much traffic and is guaranteed data will come from a single source in a sanitized format.
For the last 5 weeks or so I’ve been working with puppet every day to automate the configuration of various nodes in our stack and my most interesting observation so far is that you really need to keep your discipline when doing this type of work.
Estimating helps when the process of estimating builds shared understanding among the people who want the work done and the people doing the work.
When you work towards a release or some other looming milestone. There’s that urge to leave stuff behind, cut some corners – you know, just a wee bit, no harm done – so we can ship the damn thing already.
The upcoming book "DevOps for Developers" will provide real-world use cases (e.g., how to use Kanban or how to release software) and well-grounded background elaborations (e.g., about the danger of moral hazard in projects), this book serves as a reality check for DevOps.
Use the simple resources, and stay away from the magic ones, and you’ll actually be able to understand the configuration of your systems and hopefully get to the root of your problems faster.
One of the biggest leaps forward in my productivity and enjoyment, as a developer was when I learned about and adopted Maven for my Java projects.