Gathering Requirements
We’ve stressed from the beginning that one of the central ideas in this book is that one of the best ways to ensure that operations deliver business value is to ensure conversations happen with the stakeholders, in order to understand the business needs behind the infrastructure requirement. To do this, we need to get everyone who might be involved in using the infrastructure (or their best representatives), together to discuss the rationale behind the requests, to unearth the requirements as they are currently known, and to work out what the most pressing need is.
So, you call a meeting, and invite the CTO and the rest of the technical team. You explain that the purpose of this meeting is to write down in plain English the reasons for the request for a team server and what will need to be in place in order to satisfy that requirement—that is, for it to be deemed a completed project. In the meeting, you explain that you’re going to write some acceptance tests that can be executed as code, and that will form the specification for what is built using Chef. The tests will run, and when they all pass, this means we have cookbooks that will deliver the required functionality as agreed at this meeting.
When I run these meetings, I like to start by asking a series of why questions. Although they can rapidly start to sound like they’re being posed by a frustrating three year-old, they quickly get to the real purpose behind a request:
You: Why do you want us to have a ...
Get Test-Driven Infrastructure with Chef now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.