19 Automation Worst Practices to Avoid

Christopher Torgalson, a front-end developer at Annertech, began his session on automation at DrupalCon last week by drawing a distinction between good robots and bad robots.

Bad robots are slow, difficult or dangerous, in terms of data security.

“Good robots work fast, but they’re stupid. And that’s our fault. If we don’t account for their innate dumbness, we’ll regret it,” he said.

When it comes to automation, it seems like there are lots of ways to lose. And that was exactly Torgalson’s point.

His talk was titled “Automation Worst Practices,” and it covered 19 common, mistaken beliefs developers fall prey to when setting up automated scripts. These mistakes — or purposeful shortcuts — waste time and resources, Torgalson explained, and set organizations up for security problems.

Torgalson gave each attendee a virtual bingo square and had them track how many of the blunders they’ve committed. How many automation worst practices is your org guilty of?

This robot lawyer is taking on big companiesBots vs. Bureaucracy

Worst Practice: Repeat Yourself

Duplicate Your Configurations

The whole point of automation is to reduce effort and duplication. If devs create new configurations for automated projects that share similar tools, that point is lost.

For example, the server infrastructure needed to run Drupal can be automated with tools like Ansible. Instead of recreating automation for each similar project, devs could set up shared default configurations in Ansible, and then override when a particular project calls for extra modules.

Drag and Drop Your Code

Be careful: Sometimes dragging and dropping from a previous project does more harm than good.

Imagine you set up a gulp pipeline to minify, compile and process images for one project. When it’s time to begin a new project, you copy and paste the pipeline code and change all the paths to fit your new needs.

“There’s your configuration out the window,” Torgalson said.

Then, you find your new project requires some extra tasks — perhaps a new theme uses a lot of .SVG icons that need optimizing. That’s a whole new step in your pipeline. Before long, you’ve got a completely new automation pipeline, and it would have been a lot more efficient to start from scratch.

Keep Your Automation Scripts Anywhere but in Your Code Repositories

Automation scripts work best when you know where they are and you can find them.

Let’s say there’s a three-line Bash script you need to deploy something in Jenkins. So, you paste the script right into the Jenkins text box. Do that for 25 different projects, and you end up with 25 slightly different Bash scripts. Eventually, you won’t be able to find the automation script you need because you won’t know where it lives or what project it belongs to.

Worst Practice: Don’t Keep Secrets Secret

Keep Plain-Text Secrets in Source Control

“If you’re doing this, you should probably just call Bingo,” Torgalson said.

Sometimes, private keys, API keys or database credentials end up unencrypted in repositories. It might be from negligence. It might be because that’s the only place the secrets are stored. Either way, don’t do it.

Since most sites are still deployed by git-pulling a repository onto a server, anyone with access to that server would have access to your secrets. Choose a tool that protects any secrets inside automated pipelines.

Re-Use Passwords, Secrets and Private Keys

If your server infrastructure involves multiple machines, you might need to duplicate some of those secrets. If you simply have multiple projects sharing database passwords, it’s time to tighten the screws.

Worst Practice: Always Use the Most Convenient Tool

Use One Tool for Every Task

While working on a recent personal project, Torgalson spun up a build script in Bash. Python would have made more sense for the task, but he didn’t want to add a Python dependency to the project.

After a full day of work, he ended up scrapping it and starting over in Python.

“By the end of it, I just felt stupid,” he said.

What’s the lesson? Just because you’re comfortable with a tool doesn’t mean it will make the job easier. Take a minute to identify the most useful tool for your context, and use that.

Use a Different Tool for Every Task

But don’t use a different tool for every context.

Here, Torgalson described a hypothetical pipeline that begins with a merge to main in GitHub: That triggers a Jenkins job, which then runs an Ansible playbook, which works with Bash to run Composer scripts, which use Robo as well as NPM.

“If we use every tool in the shed, all that gets us is technical debt.”

On paper, all those tools might be great at their jobs. But side by side, that pipeline looks suspicious, according to Torgalson. It could likely be optimized to cut down on moving parts.

“If we use every tool in the shed, all that gets us is technical debt,” he said.

(“Bingo,” one attendee commented.)

Worst Practice: Humanize the Automation Process

Learn to Fear Failure

The relative importance of the task being automated shouldn’t affect how the automation gets built. In other words, developers’ feelings toward the task shouldn’t be reflected in the automation script.

Take deployment, for example. Traditionally, deploying to production has been a relatively high-stakes and time-consuming task. Developers may be tempted to write tentative, fail-safe automation for deployment pipelines because of their feelings toward what’s being automated.

But failure is a good thing, even here. Failed deployments help refine automated pipelines, which saves time and effort later. In other contexts, developers recognize this, but with tasks that feel important, it’s harder to reconcile.

The point of automation, Torgalson said, is to minimize both the effort and the importance of the tasks being automated. Sometimes, our emotions get in the way.

Learn to Fear ‘the Build’

If you’re used to deploying sites through git-pull, pulling Composer code from repositories or assembling NPM components when it’s time to compile can be intimidating.

But don’t avoid automating complicated maneuvers just because they’re complicated. If they’re repetitive, they’re a candidate for automation and — as you learn from the failures — optimization.

Deploy Code Nervously and Infrequently

The more timid teams become about deployments, the more likely problems are to arise.

Torgalson gave this illustration: If a team is using automation to upgrade Composer packages, that task will probably go off without a hitch. But if the team is upgrading 30 Composer packages because they haven’t deployed in two months, there’s a higher chance of something going wrong, and it will be tougher to pinpoint the problem when something does.

Deploy Code Creatively or Artistically

If an automated deployment pipeline hits a dead end and developers go in by hand to either roll back the deployment or manually stitch the new code into the production branch, you’ve defeated the purpose of the automation. Instead, find what went wrong and fix up your automation first. That way, you’re learning from the failure.

“The automation has failed because you’re involving the humans. We want to be out of the process as much as we can.”

“The automation has failed because you’re involving the humans,” Torgalson said. “We want to be out of the process as much as we can.”

Worst Practice: Automate on a Need-to-Know Basis

Embrace Obscurity

Just because you’re writing automated scripts doesn’t mean you’re no longer bound by what Torgalson called “nicer coding standards.”

When writing in Bash, he suggested, use long-form flags instead of short ones.

Limit Access to Deployment Scripts

When robots and humans are working in the same codebases, make sure the set-up doesn’t privilege the automation over the developers. Developers should be able to find and use chunks of deployment scripts if they need them.

So, if you have a pipeline that uses NPM-watch commands to build and compile themes, developers should be able to access individual tasks within that pipeline. If they can’t, for instance, easily pull the script that compiles CSS without also linting and minifying their Java, your automation isn’t playing nicely with developers.

Limit Access to Deployment Information

“I was involved with a project where I could trigger an automated pipeline, but I had no way of finding out what was happening inside it,” Torgalson said. “I didn’t have access to the codebase it was using, and I didn’t have sufficient access to the [continuous integration] tool to find out what it was doing. So I had literally no way of debugging it.”

When it comes to deployment pipelines, developers are your end users, and visibility matters. Make sure your pipeline isn’t a black box. 

Limit Access to Error and Activity Logs

Same deal. If devs can’t see inside your pipelines, they won’t know why their deployments failed, and they won’t know how to fix them. (In a software firm setting, devs shouldn’t have to reach out to clients for information on deployments or their outcomes.)

Don’t Log Anything

If developers don’t get automatically alerted when automation breaks, they won’t be able to fix it, and it will lead to bigger problems down the line.

Nevermind — Log Everything

Hold up, now. Nonstop public logging is not the solution. If developers get a Slack ping every time the automation does anything at all, they’ll tune out. Make sure team notification channels aren’t flooded with alerts — that makes it tough to find relevant information.

“If you report everything, it’s just as good as reporting nothing.”

“If you report everything, it’s just as good as reporting nothing,” Torgalson said. “Everybody will mute the channel and leave.”

Ignore Idempotence

Idempotence occurs when doing something twice has the same effect as doing it once. A good automation tool can make sure scripts don’t run on things that are already in the correct configuration.

‘We Tested the Application, So We Don’t Need to Test the bots’

“I’m just going to say that’s false,” Torgalson concluded.

Which social media bots are “OK”?Instagram AI Tools Are Frowned Upon — but They Work