Technical Debt in programming is a topic for the ages. It tends to permeate round table conversations and almost pre-dates physical development. Although its accumulation has no discernible pattern, time and money are common factors.
A new version of Go, the Continuous Delivery managment tool by ThoughtWorks Studios, is up for grabs today with a feature that is going to help package the right versions of your components and eliminate spurious builds.
What happens when “sometime in the future” is now? How much debt is too much to carry? When do you have to pay if off?
It’s a little-known fact that Phusion Passenger, the awesome Rack webserver module, can also competently talk WSGI as well as fit into the Rack ecosystem. This means that not only can you run your Rack and Rails applications through it, but also your WSGI-compliant Python applications.
Oftentimes we find users struggle with figuring out where to start when reviewing their log data, and what they should be looking out for. A common question we get is: "So I’ve a bunch of linux boxes, I’m running a LAMP stack, what should I be looking out for in my logs”.
We all know that protocols are an essential building block of our craft. So why not apply the ‘protocol’ idea to Devops? Let’s try and see how the idea of protocols can help us improve the adoption of a Devops culture.
IT people often try and justify new technology with technology reasoning. It's analogous to answering a question with another question.
Monitoring configuration is complicated, and the depths that you can configure alerts and tests seems endless. It may seem like a waste of time to invest in some options, but others can really help you eliminate states that send hundreds of alerts.
Learn abourt using Vagrant, Puppet, and Puppet modules to manage Maven dependencies, PostgreSQL, Tomcat, and apache as examples.
Learn some key Cloud DevOps patterns from a master in the IT space - John Willis
Recently I had a challenge of getting capistrano deployments working from jenkins installed on a RHEL box. The problem seemed to be down to the fact that ssh-agent isn’t running for the daemon process that jenkins runs as for whatever reason and it is needed to do ssh agent forwarding (which is what I do so I can use the ssh key on the jenkins server to check code out from github on remote servers).
We’re using logstash to collect all the logs across the different machines that we use in various environments and had noticed that on some of the nodes log files which we’d told the logstash-client to track weren’t being collected.
Recently I discovered the power of Vagrant and Puppet. They allow me to automate all the steps I used to manually make before. Here I test drive the process of automatically configuring a Hadoop cluster in virtual machines for a fully distributed mode.
Today, there are two broad categories of provisioning and deployment automation. The first are convergent tools such as Puppet and Chef. The second are directed automation tools.
In this write up I'll be writing some of the techniques I'm using to model environment-specific differences between dev, staging, testing, and production.
A few months ago I was struggling (again) with logging configuration in JBoss 7.x. I was so depressed that I wrote to the Java EE 7 expert group : Logs. Should we finally do something? As a developer I’ve used all the possible logging Java frameworks for the last 12 years and I still struggle with logging in 2012.
Most of what you read and hear about devops is in online startups – about getting to market faster and building tight feedback loops with Continuous Delivery and Continuous Deployment. But devops is even more important in keeping systems running – in maintenance and sustaining engineering and support.
By using Jenkins, it’s pretty easy to get a Continuous Integration server set up with an Android project. But before you dive into setting up the software itself, it’s very helpful to have some basic concepts on a few different types of software that you will run into.
One of the things that is pushed here a lot is the necessity to make all new applications really production-ready before being deployed as a service. There is of course the adage “If it’s not monitored, it doesn’t exist” but beyond that there are a lot of other little fiddly details just to make something run.
Exceptions should be easily visible to the support and development teams and your development process should look to address all exceptions in forthcoming sprints.
How often you should analyze your log data really depends on the reason why you are carrying out the task in the first place, i.e., why are you analyzing your logs, and what exactly are you interested in finding? Below I list some of the common use cases for analyzing logs and give some pointers on how often it makes sense to do so in these situations.
Just like mainstream programming languages, it is possible (and good practice) to test your Puppet manifests so that you have higher confidence in them working when it comes time to actually run them.
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.