The March 24 Boston DevOps meetup was a show and tell, a series of short talks from the community on tools and techniques they find helpful in their daily work.

 Jenkins (2.0) Pipeline as Code - Thomas McGonagle

Tom shares the new Pipeline as Code plugin for Jenkins that allows you to define your entire build pipeline in a Jenkinsfile.

Slides: https://speakerdeck.com/boston_devops/pipeline-as-code-in-jenkins-2-dot-0

 Workflow Abstraction - Don Luchini

Don shares how you can simplify your software delivery pipeline by standardizing interfaces.

Slides: https://speakerdeck.com/boston_devops/designing-a-project-lifecycle-using-contracts-and-constraints

 Summon - Dustin Collins

Dustin shares an open source tool that makes working with secrets easier.

Slides: https://slides.com/dustinmm80/summon-secrets-source-control

 Self Service Permissioning Approaches - Mark Ferry

Mark

The latest Boston DevOps meetup focused on the habits that are important to encourage for successful DevOps adoptions. My co-organizer, Dave Fredricks, suggested the topic. Topics like culture and collaboration are important, but sharing the daily decisions made in how we approach our work and interact with each other is helpful too.

For the February 24 meetup we had two presentations and three lightning talks. Big thanks to G2 for hosting, LogicMonitor for sponsoring and Anastas Dancha for recording the talks. Join the conversation at our next event and in the Boston DevOps Slack channel.

On to the content!

The Journey to an Agile DevOps Desk
Peter Nealon and Glenn Grant of G2 Technology Group

The merging of a DevOps workload with the traditional Service Desk model presents some significant operational challenges. Peter & Glenn will share with you how they’ve bastardized agile

READMEs. User manuals. Operation guides. Handbooks. Command-line help. Internal chat. Company blogs. As software engineers, we write often, and in many different contexts. The code we write often doesn’t provide value without some sort of writing to accompany it. Most organizations provide engineers support for getting better at writing code, usually in the form of training or mentoring. Few, however, provide this same support for getting better at writing text. Why is this?

I’m going to argue that this lack of support comes from viewing people as static instead of as dynamic. This severely limits the impact of the work people can accomplish in your organization. What do I mean by static vs dynamic? Let me explain by organizing some statements you’ve probably heard before:

You just landed your first software job. You’re excited, this is a great opportunity! You’ll be able to apply that expensive Computer Science degree to something useful and start paying back those students loans. (If you’re self-taught, good on ya). You know a lot of stuff and now you have the chance to use that knowledge to solve some interesting problems.

 zero

Your first day of work goes pretty well. You get set up with HR, someone gives you dev accounts to various tooling and you start poking around at the projects on GitHub. “Hey”, you think, “this is going to be easier then I thought”. A few days in, you are assigned a task to do. You check out the project and follow the README to run it locally. You start running into problems.

• You need RVM, but the README doesn’t say what version of Ruby to use.
• There’s a Vagrantfile in the project root, but you can’t tell what it’s used for.

If you work at a DevOps organization, you use a lot of tools. Communication, architecture, planning, programming, testing. I always like reading what tools other people use to do their job. It helps me stay current. My development machine at Conjur is a Macbook Pro. This post is a list of the tools I use day-to-day, and how I use them.

 Collaboration

• Slack - Internal chat; external chat; Github, Jenkins and Pingdom notifications.
• Google Drive - Sharing design docs/spreadsheets/presentations (inline commenting is great).
• Google Hangouts - Video chat for standups and other meetings.
• Screenhero - Pair programming tool. Both people can control mouse/keyboard and it’s the most reliable experience I’ve found with spotty connections.
• asciinema - Record and share terminal screencasts. Especially useful for sharing CLI workflows and creating tutorials. Check out the -w flag on the rec

When the Gotham City police summon the Dark Knight, they broadcast an unmistakable signal. Everyone knows what it means, the immediacy, and the intended audience. While effective communications is seldom so easily implemented, the Bat Signal demonstrates foundational concepts. Effective communications deliver the right message to the right people at the right time and convey the meaning you intended. Seems straightforward enough.

Until DevOps. Until continuous delivery. Until you have to communicate up, down and sideways. Deadlines. Multiple departments, tools. Third parties. Competing interests, competing demands. Now the only straightforward thing is you in an organization prone to reactive management, islands of self-interest, distrust and blame.

How can you possibly win?

Decades of experience reveal the following three practices of those who put themselves in the

What skill set is desirable for an engineer in a DevOps organization? Let’s take a look. Surveying DevOps job posts, you need to be intimately familiar with dozens of technologies you’d never use in a non-production setting. Reading articles on devops.com, you need to be able to write 1,500 words without really saying anything at all. Attending DevOpsDays conferences or DevOps meetups, you need to have a finely-tuned sense of empathy. So many things, what should you focus on?

In this post I’m going to talk about the top three DevOps skills I’ve seen to be most important for engineers, in no particular order.

 Code

There was some controversy over this when DevOps first became a #TrendingTopic, but I think we’ve settled it now: If you’re an engineer in a DevOps organization you need to be able to deliver solutions as code. It doesn’t matter if you’re dev, ops, QA, DBA, security, data

DevOps is hot. Everyone wants it. Continuous delivery is not just for the cool kids in the loft office anymore. Enterprises that have a long history of ‘hardware’, like Target, ING and Cengage Learning, are transforming into software companies. They need to be able to experiment in the market with shorter lead times. A potent brew of collaboration and automation is required.

A quick note. Startups, you are not doing DevOps by default. Just because you sit together does not mean you don’t also have to put in the difficult work of creating and maintaining lean delivery cycles. I’ve worked for large and small organizations, and the notion that “X only works in startups”, or increasingly common, “X only works in enterprises”, is disingenuous. This is the definition of a red herring.

import random

X = random.choice([
    'continuous delivery',
    'feature flags',
    'blameless

We’re using Docker a lot now at Conjur. Jenkins integration tests - Docker, dev environments - Docker, shipping a virtual appliance - Docker. You get the picture. A lot of our scripts have lines like this in them:

chef-runner --ssh Port=2200 -H root@$(boot2docker ip) mycookbook

I develop on OSX, so I have been using boot2docker for a while now. But I really liked the feature set of docker-machine when it was announced. It allows deployments to more than just VirtualBox and folds together nicely with the other Docker tools. For the last couple months, I have used docker-machine exclusively.

But now we have a problem.

The dev team is split: some of us are using boot2docker and some docker-machine. Our automation code assumes a boot2docker VM is up and running. When this sort of issue comes up, we have three choices.

1. Write code. Update our automation code to be smarter and switch