While few of us want to live at the extremes of many production deployments of an app per day, many of us want to detect production problems quickly and be able to respond accordingly. Copy the infrastructure of good tests, piecemeal automated deployments, and good monitoring and apply them to your more reasonable goals.
I couldn’t find any good, brief, practical introduction into Puppet that gives you basic working knowledge in minimal time, so here it is. You will learn how to do the elementary things with Puppet – install packages, copy files, start services, execute commands. I won’t go into Puppet installation, nodes, etc. as this introduction focuses on the users of Vagrant, which comes with Puppet pre-installed and working in the serverless configuration.
Once we know something, we find it hard to imagine what it was like not to know it. Our knowledge has “cursed” us. And it becomes difficult for us to share out knowledge with others, because can’t readily re-create our listeners’ state of mind.
Mainly because my production environment is usually a cloud, and changing the code is a mess. What can we do? The solution that I like for these kind of problems is to use Apache’s environ variables.
With all of these tools and examples around , there should be no excuses anymore for Drupal developers to hack on their own machine and tell the systems people "It works on my machine" (let alone to hack in production).
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.
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.
Let’s take a look how the ideas of The Lean Startup and Devops enrich each other to successfully create product development flow.
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.