By Hand vs Automatically

To put a new version of Pageturn online, Sam used to follow about twenty careful steps: copy the files to the server, restart the program, clear an old cache, check a setting, run a quick test, and on down the list. He did it himself, by hand, every single time. And step fourteen was the kind of thing that's easy to forget when it's late and you're tired.

There is another way to do that work. You can write the steps down once — in a form a machine can read — and then let the machine run them for you, the same way, every time. That is automation: capturing a task once so a computer repeats it exactly, instead of a person redoing it by hand. It is the single most repeated move in all of DevOps, so it's worth getting clear on right at the start.

What "by hand" really means

Manual work is a human performing the same steps each time the task comes up. Sam reads the list, does step one, does step two, and works his way down — using his attention and his memory for every line. Nothing is wrong with this for a task you'll do once. The trouble starts when you do it again and again.

Because each run depends on a person, each run is a little different. Sam might do the steps in a slightly different order, or pause halfway to answer a message and lose his place. The work gets done, but it gets done by hand, which means it gets done a bit differently every time.

The cost of doing it by hand

Manual work is slow, because a person can only move so fast and has to think about each step. It's inconsistent, because no two runs are exactly alike. And it's where mistakes creep in — a step skipped, a value mistyped, a "wait, did I already do that one?" These errors don't show up because anyone is careless; they show up because humans are doing repetitive work, and that's exactly what humans are worst at.

The cost grows with how often you repeat the task. Deploying Pageturn once a year by hand is fine. Deploying it several times a week, at all hours, is where the slowness and the slip-ups start to hurt.

What automation is

Automation flips the order of work. Instead of doing the steps each time, you do the harder thinking once: you write the steps down precisely, in a form the machine understands, and from then on the machine performs them. The human effort moves to the front, into describing the task; the repetition moves to the computer.

Think of a dishwasher. Washing every dish by hand means standing at the sink each night, and your results depend on how careful you are at that moment. A dishwasher is set up once — you load it and start it — and then it does the same job the same way while you go do something else. Automation is that move, applied to the steps of building and running software. (Then drop the dishwasher; from here we'll just say automation.)

The payoff

The result is the same outcome every time, no matter who runs it or when. The machine doesn't get tired, doesn't skip step fourteen, and doesn't do the steps in a new order because it was distracted. Run it now or at 3am, run it yourself or let a teammate trigger it — you get an identical result.

That reliability is the whole point, and it's why automation shows up in every chapter ahead. Almost every DevOps tool you'll meet is a way to automate one slice of building or running software — and the first time several automated steps get chained together, that chain gets a name, which is exactly where the next topic goes.