While I love XKCD 1205 simplifies things too much. You have to account for human psychology.

Small times doesn't mean small impact on developer time.

1. Routine makes you much more likely to make errors because you're not fully focused. This error could feed into the next process step which is maybe longer, thus costing you disproportionate amounts of time if it fails.

2. If there are wait times in these short tasks (say 30 seconds to 30 minutes) these can have an inordinate effect on developer time wasted.

Say you have a "30 second task" you do a handful of times a day. You have to do something, then wait a bit, then do something else. If you're not a robot you will not like watching for the time it takes to complete. So you might switch to HN or whatever else you were doing. What happens after the task completes?

* You could have lost your state of flow (very likely) => that's another 15-20 minutes to get back into it.

* You might forget to context switch back. Boom 30 minutes have gone by. Oh it's lunch time now. I'll do that after. Then you come back, and forgot about it again. 2h have gone by in your 30 second task, and it's still not done.

3. The problem could be that you don't do the task often enough. Maybe it would help quality if the task was done every few seconds. If it's arduous or takes some time, you're much less likely to do it as often. The graph in 1205 assumes that the number of times the task is done is not related to the speed of execution or that it is a manual task. I don't think that's true. An extreme example of this would be my previous workplace. Build times were 5h, you needed to execute two steps to trigger a build. One step after the other completed (roughly 15 min).

People would waste a lot of time on finding errors that a compiler could find right away, because compiling took half a day and wasn't something you just wanted to trigger.

The process described is not only easily scriptable, but are things for which a human could very commonly make a mistake. You can add things in to include a human in the loop, maybe hitting return at each step, or hitting y, but deploying to production should never depend on a series of manual steps except when absolutely necessary

martinkus> ... I have to pick out two artifacts ... pick out the correct jenkins jobs and run them in a specific order ...

russdill> The process described is not only easily scriptable, ...

From the description given you can't know that.

russdill> ... deploying to production should never depend on a series of manual steps except when absolutely necessary.

So you, without knowing exactly what this person is doing, are declaring that it's not absolutely necessary? That's very bold of you.

They listed exactly what they are doing. The artifacts they are picking out should already be tagged with the release. The script to push those to production can use those tags to know what to push and what git commit hashes to check.

ETA: I'll add that when pushing production, the amount not just you can waste, but everyone down the line from users, developers, testers, etc, etc, can be huge. Calculating how much time you would save isn't useful.

I don't want to say you are wrong, because there are a lot of situations (most?) where deployment automation can greatly reduce errors.

However, there can also be a number of reasons why builds and deployments could not be automated safely:

- "Production" is not a single environment, but multiple customer environments with multiple deployment version targets based on need/contract. Customer environments might not even be accessible from same network as build/deploy machines.

- Code is for industrial/embedded/non-networked equipment.

- Policies dictated by own company or regulatory body require builds are manually checked and deployed by a human who can validate and sign off.

There really is no way of knowing. Automation can save hundreds and thousands of man-hours and reduce margin of error; but it is not applicable to every scenario. Sometimes manual work reinforced by good habits and processes are the tool for the job. As much as it pains be to say, as my job is automation.

Not to leave you guys hanging about my specific case, the process we do is as almost as automated as possible. All the heavy lifting is scripted and the deployment to all other environments is done via a single click, however for prod we do have an additional checks, as deploying the wrong build could have some bad consequences.