Build Bridges and Bust Silos with a Common Toolchain

It was time for the small company I worked for to pick new content tools, and we were in a meeting to hear from the project lead. She gave a great talk, explaining the benefits and tradeoffs of each tool. Her slides had cat pictures. She was funny and self-deprecating. But the Q&A afterward was tense. The underlying note of each comment was, "I don't mind change as long as it's happening to anybody else." Afterward, we joked about the meeting. "It's hard," she said. "People like their tools, and you've got to tell them they might have to change something, and ..." "Nerd rage," I finished for her. "Right. Nerd rage." Technical folks, whether they're sysadmins, front-enders or application developers, are deeply attached to their tools: It's either tmux or screen, vim or Emacs,  git or svn, rvm or rbenv. Most of the time, those preferences are benign: Maybe you have to twist the sysadmin's arm to get him to install Emacs alongside vim, or just settle on using tramp over ssh to sidestep the issue. Sometimes those preferences become damaging blockers as tooling becomes the focus of inter-departmental squabbles. Our 2013 State of DevOps Report recommends learning a common toolchain to foster communication throughout an organization. When different teams and departments have common tools, they become more aligned and benefit from a bigger pool of experience. Instead of three siloed bug trackers containing three Rashomon-like versions of the same issue, you've got one. And that script they use over in engineering that adds a Trello card when someone files a bug in the tracker? Now everyone gets to use it. Getting everyone on the same page is key to establishing DevOps culture. Our report shows the benefits of that culture grow over time: Your organization starts shipping code faster, with fewer errors. When errors do crop up, they're resolved faster because you don't have to pull stakeholders from multiple silos to work out a fix.

Leveraging Common Tools

When we looked at our survey data from the State of DevOps report, Git proved to be the ascendant version control system among all organizations, not just the ones that identified as DevOps shops. About two-thirds of our respondents reported using it, and version control tools in general figured prominently. That makes them ideal subjects to explore the ways the ops and development teams can come together: Version control is everywhere. Puppet Labs operations lead Kelsey Hightower demonstrates the ways Git can help bridge the gap between the operations and developer teams in the video below.  He shows how Puppet Enterprise can help facilitate that process by capturing the wisdom of a sysadmin with the Puppet DSL, a web developer's code in Git, and then bringing the two together with its orchestration engine.
The tool Kelsey demos shows how an operations team can provide developers with self-service code deployments to different web environments. Instead of handing over root or juggling permissions in specific directories, a sysadmin can use Puppet Enterprise to express the desired state of a given environment. Once she's configured the server environment, she can write orchestration engine plugins that allow a developer to visit a web console, enter the Git SHA he'd like to deploy to staging or production, then push code out over multiple nodes at once. Thanks to the guarantees of consistency and on-the-spot remediation offered by Puppet Enterprise, sysadmins can rest easy knowing basic operational and security concerns are handled. Thanks to their ability to push code on their own, without hand-holding or being forced to navigate an unfamiliar shell environment, developers know they can get their work into staging or production on their own timetable. Better yet, developers can inspect the environments their code will be running on using the Puppet Enterprise console, which offers a frequently updated, single source of truth that provides complete reporting on the state of any node on the network. Working in unison with operations, developers can review custom facts that report on application versions and other key system data, helping them anticipate the environments their code will be running in before pushing it out. The common thread throughout this process  is a shared tool: Git. The ops team doesn't need to master Git to write the simple code needed to leverage it for deployments, and the dev team is probably already using it. Kelsey's orchestration plugin could also work with svn or any other automatable version control system. The only thing that's really required is an agreement on the tool in question, and some communication between the developer and operations teams to make it work. But don't stop here. Once you've figured out one way to share tools and build better communications, it's time to tackle bigger projects and build more bridges.

Learn More

Puppet sites use proprietary and third-party cookies. By using our sites, you agree to our cookie policy.