Get Puppet Enterprise
Puppet Blog - Page 46
No Nasty Surprises: Continuous Testing & Continuous Integration for Successful Release Management
Everyone wants to release software faster, with fewer errors, so continuous integration is the watchword for modern release management. But as Andrew C. Oliver writes in InfoWorld, it’s surprising how few organizations integrate load testing early in the development cycle, since failing early is a lot less expensive than failing in production.
New VMware Provider Gives Vagrant a Boost
Developers need a quick, reproducible method for creating environments to run and test their applications. Vagrant addresses this need by making it easy to create and control virtual machines.
Until recently, the only virtualization provider for Vagrant was for VirtualBox. That changed this spring when Vagrant creator Mitchell Hashimoto released a VMware provider for Vagrant. Now you can use Vagrant to create and control VMware virtual machines using VMware Workstation and VMware Fusion along with VirtualBox.
Puppet 3.2 Introduces an Experimental Parser and New Iteration Features
Puppet 3.2.1 landed today. Though it’s a “patch” release, it’s the first public release of the Puppet 3.2 series, and it includes a taste of the Puppet DSL’s future in the form of an experimental parser that introduces some new features you’d expect to find in traditional programming languages.
Getting it Straight from the Source at PuppetConf: Justin Seabrook-Rocha & Patrick Adair
When you’re responsible for keeping other people’s enterprise websites up and running, you never want to say you’re sorry they’re down.
That’s why Justin Seabrook-Rocha and Patrick Adair both use Puppet technology in their work for Hurricane Electric, an internet services company whose transit backbone connects to more than 2,100 IP networks. Hurricane Electric is located in Fremont, California, and Justin & Patrick both work in the same building that was once the manufacturing facility for NeXT Computer, Steve Jobs’ gig before his 1997 return to the helm of Apple.
Both Justin, a network engineer, and Patrick, a network technician, are registered for PuppetConf in August. They’re expecting to get tips and advice from other attendees and speakers on ways to make their own Puppet infrastructure better, and the latest updates on what’s new with Puppet.
We Are Dev-Docs: Embedded Tech Writing at Puppet Labs
Before I started at Puppet Labs, I was a tech writer at a large corporation (I won’t name them, but their initials are HP). The approach to tech writers there conformed to the traditional “huck it over the cube wall” model I’ve seen at other large enterprises. Anyone who has worked in tech for any time at all has encountered this model, which presents a new product to the writer as a fait accompli and which imagines tech writing as an after-the-fact act of taxonomy: “Here is a thing. The thing has five things stuck to it. Three of those things are red, one of them is made of feathers.” And, we’re done.
More often than not, the huck-it-over-the-wall method results in tech writing nobody reads because it does nothing useful (“I can plainly see that thing is made of feathers, what possible good is this manual going to do me? I’m going to put it back on top of the toilet tank and continue to ignore it.”).
Release management best practices have changed
Release management best practices have evolved over time as software tools that manage and automate parts of the process appear. As a result, established structures are ever changing. An example of this is a 2007 piece on Buildmeister about best practices that were inspired by ITIL, the ISO standard IT Infrastructure Library.