In our work, we interact with people from many different teams: developers, QA/testers, operations, etc.. In some organizations, operations may be further segmented into SCM, DBAs, Security, and so on. And, in other cases, some functions might be combined. But, if I had a nickel for every time I asked someone whether some process was automated and they incorrectly told me yes, well...you know the rest. This is why definitions matter sometimes. It's the difference between automated and automatic.
What they mean is:
- We wrote some scripts for that
- You have to log into each of the machines separately to run the processes
- Your environment/machine has to be configured just right to run the scripts
- You must manually execute each of the scripts separately
- A human must be present to run the scripts
- It's "automated"
What I mean is:
- The scripts are run headless (i.e. from a single command)
- The scripts are checked into the version-control repository
- The scripts have been integrated into the build and/or deployment scripts -- and all processes can be run from a single command
- That the automation is automatic
The difference between the approach they think is automated and what I think is automated is vast. But, it's not about using the right definitions; it's about having a common understanding of the goals you want to attain. The "manually automated" approach leads to significant bottlenecks (real scenario: 100 projects and 10 target environments per project means that your development is stopped every single time someone must manually perform these repetitive activities).
So, the next time someone tells you "(their) stuff is automated", you might want to ask a few questions because each manual task slows down the entire process which costs time, money and frustration.
