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.
I installed Jenkins last week for the very first time. A couple of days later I was able to publish my first plugin, called AnsiColor, which colorizes ANSI output. It’s the plugin you’ve all been waiting for.
I never thought we'd be hearing those words from Jez Humble, an advocate for Agility at ThoughtWorks, but here is the point he's trying to make...
Infrastructure is hard to build. This is true when putting together compute clusters, or when dealing with roads or power lines. Typically this involves both increases in operating expenses and capital expenses, and a small mistake can be quite costly.
Build Flow enables us to define an upper level flow item to manage job orchestration and link up rules, using a dedicated DSL. Learn to harness this awesome plugin.
Log messages are destined to end up in a log file … are they really? When you search megabytes of logs file for a clue what went wrong, or when you want to generate some statistics, you realize that this calls for proper tooling. In logFaces I’ve found a tool that I’m using happily for more than two years now.
As an initiative to get developers, sysadmins, and testers working together to increase the speed of delivering high quality software changes, a key challenge devops must address is trust. Sysadmins simply don’t trust developers to hand them production ready code.
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. Here are 3 ways to do it...
Once we have good metrics and a good set of monitoring systems on top of them, we can be much more aggressive in pushing out changes due to the fact that this style of monitoring gives us a very effective early warning system with regards to bugs or breakages that have been introduced.
Developers are driven by getting new features out the door. Operations, being charged with keeping things running, wants to avoid change. RISK is a 4-letter word keeping them apart.
Once you’ve been working with Jenkins and uberSVN for a while, you may find yourself in a situation where you have several jobs that need to run in a specific order. How do you implement a complicated setup?
Everyone knows the C-I-A triad for information security: security is about protecting the Confidentiality, Integrity and Availability of systems and data. In a recent post, Warren Axelrod argues that Availability is the most important of these factors for security. I don't agree...
Hosted applications need to be upgraded regularly. Configuration changes are regularly needed to tweak the environment so that it runs efficiently and communicates properly with other systems. This requires some mix of command-line invocations, jumping between GUI screens, and editing text files.
The result is a unique snowflake - good for a ski resort, bad for a data center.
Here we will highlight some of the measures that were necessary to further operationalize the system for production use. As our environment receives anywhere from 2,000 to 6,000 log messages per minute (with occasional peaks to 40,000!)
A recent question on Twitter prompted me to write a quick blog post about managing cron jobs. As more and more people want to automate provisioning and deployment of web applications some, maybe previously manually managed, items come into the fold.
Terraform is a flexible tool made available under the Apache 2.0 license that makes it easy to define, instantiate and manage environments. Terraform integrates with existing cloud providers. Today, Amazon EC2 and VMWare vSphere are supported.
"Once IT decides to focus on speed, two obstacles get in the way: security and governance." This is important. Manage security without it becoming an impediment.