Everyone has their favorite text editor. For a lot of people that editor is Sublime Text, but there are many other choices available. A lot of old schoolers still prefer to use a flavor of the vi editor. Many OS X users swear by Mac-only TextMate. And now there's a new kid on the block from the makers of GitHub: Atom 1.0. Sublime Text and Atom are both available for multiple platforms, so whatever OS is your poison, they have a version for you.

The project space feature is one of the many reasons I usually recommend Sublime Text, but this feature is also present in other editors such as the new Atom 1.0.

To keep things current, I will use the Atom 1.0 editor in the remainder of this book's examples.

Once you have decided on the editor you plan to use for your Chef workstation and have that editor installed and working, there is one more step. You will need to set the configuration to allow you to integrate your editor with the Chef command-line tools. The best way to do that is to edit your .chef/knife.rb file and add a line to set the editor you want to use with your knife commands. (You could also add an export EDITOR= command to your shell's .bashrc or .bash_profile file.)

Here are some sample knife.rb entries:

Sublime Text:

knife[:editor] = '/Applications/Sublime\ Text.app/Contents/SharedSupport/bin/subl -w'

Atom:

knife[:editor] = '/Applications/Atom.app/Contents/MacOS/Atom -w'

On Mac, the Atom editor has a built-in feature to create symbolic links in the /usr/local/bin folder. With the Atom editor running, open the Atom menu and select Install Shell Commands from the submenu. This will create two new links for you. If you do this before updating your knife.rb file, the knife[:editor] entry simply becomes this:

knife[:editor] = 'atom -w'

When you're using a Windows OS for your workstation, you will have to take greater care in formatting your knife[:editor] line to escape the slash characters in the path. A convenient way to do that is to use single quotes around the full value and use double quotes for the path. For Sublime Text, it might look something like this:

knife[:editor] = '"C:\Program Files\Sublime Text 2\sublime_text.exe" --wait'

You can test your editor setting by issuing a knife command that requires using the editor. For example, try the command:

knife client create editor-tester

If your editor integration is configured correctly, you will see your editor open up and show you some code. Save the code and exit the editor, and you should see the private key value print out. (This key is not important at this time because we are just testing the editor, and will immediately delete the client.)

If your editor opens, you are done. If you get an error that says Please set EDITOR environment variable, then your knife[:editor] value is incorrect. There is probably a typo in the path or some other error. Double-check the value and try again until you successfully launch the editor with your knife client create command.

Once you have validated the integration with your editor, you can delete the test client with the following command:

knife client delete editor-tester

Now you are ready to edit your infrastructure code! When you are creating amazing infrastructure code, you are going to want to make sure that it gets preserved and to ensure that happens you going to want to use a source control tool. Say hello to my little friend, Git.

Git, initially designed and developed by Linus Torvalds for Linux kernel development back in 2005, is now the most widely used version control system for developers everywhere. It's the number-one choice due to its speed, data integrity, and its distributed workflow model. Git is certainly the primary choice as the version control system to be used when developing infrastructure code with Chef.

I will be emphasizing the use of Git throughout the examples in the rest of the book. Git is included with Mac OS X, but it will need to be installed on Windows and Ubuntu workstations. I recommend you to use the GitHub desktop installer where available (Windows and OS X) and allow it to deploy the command-line tools as part of the installation. This installation of Git is easy and will be left to the reader to execute.

There are several virtualization choices you can use for your Chef testing. The overall goal is to have a system that you can use to deploy a temporary Chef node to test your infrastructure code. One of the best ways to accomplish this is to install a local virtualization tool on your workstation. Among the choices for a local hypervisor are:

One of the best choices for this kind of Chef testing is VirtualBox. The reasons include its functionality, its ease of use, and its free price tag. Either of the VMware solutions will cost you not only for the hypervisor layer, but also for the integration plugins we'll use with Vagrant to manage our test nodes.

Visit the VirtualBox downloads page at https://www.virtualbox.org/wiki/Downloads to download the installer. Once downloaded, it is an easy matter to install it, so I'll leave that to the reader to take care of.

Last, but certainly not least, is Vagrant. Vagrant is another item I consider to be one of the key pieces of the Chef testing puzzle. It is the "glue" between Chef and the hypervisor that deploys the test nodes during testing. You will want to download and install Vagrant on your workstation. You can find the downloaders at https://www.vagrantup.com/downloads.html. Vagrant is also an easy install, so I'll leave that to the reader to handle.

I'll go into using Vagrant with VitualBox (and Docker) in some detail in a later chapter.