Section 13.2. How to Automate

13.2. How to Automate

To automate something, first you have to do it manually. Then you write code for each step. Next, you bring the little bits of code together, testing each addition as it is added. Finally, you test the entire system.

13.2.1. Step 1: Do It Manually

The first step to automating a process is to make sure you can do the process manually. Document each step, and make sure you can write code to do that step. Then put all the pieces together.

Many times a protégé has come to me asking for help automating something. "Oh, I've worked on this problem for hours! I'm completely stuck!" he'll say.

"OK," I reply, "show me how you would do this manually."

"I don't know. I can't figure that out."

"The root of your problem is just that, young padawan. Hmmm?"

As discussed in Chapter 12, one of the benefits of documenting a procedure is that writing down the steps is the key to being able to automate something. I wasn't kidding. In fact, when I don't have time to automate something, I write the step-by-step procedure on my Wiki telling someone else how to do the task. When I do that, I've accomplished two things. First, I've contributed to the documentation of how our system works. Second, I've actually performed the first step of automating the process!

Document the steps, then automate them. If you can't write down the steps, you'll never figure out how to automate them.

The process of writing down the steps forces you to identify all the steps. Unlike keeping all of the steps in your head, you can show the document to other people to have them verify the process.

If you don't have a Wiki, you can use paper and a pencil or a text file. Do the steps manually and record the steps. Any command that you type should be pasted into the text document.

13.2.2. Step 2: Code Each Step

Turn each step into something that can be done from the command line or within a short program. Test each step individually. That is, you might write a series of small scripts, each one verifying that the code you have for that particular step is correct.

If any step involves a graphical user interface (GUI), you must find the command-line equivalents. Some operating systems make this easy. For example, HP-UX's System Administration Manager (SAM) has a button you can press to output the command-line equivalent of the action it is about to perform. Mac OS X has Automator and AppleScript that let you automate processes normally done though the GUI. Windows has many different tools that are similar. However, tools that automate the clicking of buttons may not be as useful as directly setting various registry keys or LDAP entries.

Recommended books for Microsoft Windows administrators:

• Windows Server Cookbook (O'Reilly). You can learn a lot from this book by reading it cover to cover. You'll be surprised at how many things you thought could only be done though the GUI that can be scripted easily by a series of registry updates. It will open your mind up to the possibilities. The examples are in many languages, usually VBasic and Perl.

• Perl for System Administration(O'Reilly). This book is particularly good if you manage both Unix and Windows systems. It is Perl-centric (obviously) and people with an Enterprise or Unix background may feel more comfortable with it. It is particularly good if you are a big user of ActiveDirectory and/or LDAP.

• Win32 Perl Scripting: The Administrator's Handbook (Sams). This is also a good book, especially if you are new to scripting.

Recommended books for Unix/Linux administrators:

• Perl for System Administration.(See the full description under Windows books.)

• UNIX System Administration Handbook (Prentice Hall PTR). This book not only teaches the fundamentals of Unix administration, it also includes many valuable resources and tools. Most examples use the command line, which means they can be scripted easily.

• Essential System Administration (O'Reilly). Another excellent book that includes many command-line examples.

• Advanced Bash-Scripting Guide. Visit http://www.tldp.org/guides.html.

13.2.3. Step 3: Bring the Steps Together

Once the code for each step works, you can bring the code for each step together into one big script.

Even when bringing the code together, it is best to add one step at a time. Test after each new step is added. This is called incremental development and is the best way to test automation. By testing after each small change, you are more certain that the entire shebang will work when you are done.

For example, when we hire a new person, we have to create his account in the LDAP directory, set up his web space on our internal web server, and test his account to make sure it was created properly. Each of these steps can be automated individually. We verify that we have working commands for each step. Then we put the first set of commands into a script and test just that. We make sure the command-line option-processing junk works, any debugging commands we want work, and so on. We run the script and make sure the LDAP entries are correct. Once that all works, we add the next group of commands and test that. We make sure the LDAP entries are still correct, and then check that the internal web space exists. Then we add the next step and test the entire thing again.

13.2.4. Step 4: Test It All Together

Finally, we test the entire thing. If we have tested each step as we added it to the program, there is actually very little testing to be done.

Programmers generally dislike testing. They want things to work on the first try. By integrating testing into each step along the way, the testing doesn't seem too laborious and, as a result, there is a lot less of it to do at the end.