Is Science a blessing or a curse? Human race is doing this debate from the ancient times. Today in this century also, the question still roams in all of our mind. I remember, our teacher used to ask us to write an essay when I was in 10th std. I’m sure, many of you who has completed their initial education from India can reminisce their childhood age. Anyway, I brought this topic today for a specific purpose. In our daily life, we always see a demand to automate everything. This demand has even more prominent with the advancement of Cloud Computing. But, unfortunately, in many occurrence, we don’t perform a proper feasibility study. Not all topic in this earth can be automated and those that we can automate can’t be automated effectively without a proper feasibility study. Trying to automate everything can not only be costly but can add unnecessary complications to any topic. Resources get wasted on unneeded processes, and you can even alienate customers. As a general rule of thumb: “if a task needs a human touch, leave it to a human. If it’s robotic, leave it to software bots”. Today, in this article, we will find out automation worst practices!
|Automation Worst Practices|
|1. Missing of feasibility study.|
2. Mixing up automation with AI
3. Duplication of configurations
4. Centralize your automation scripts in your code repositories.
5. Ensure Security: Keep plain-text secrets in source control & re-use of secrets
6. Tool Selection: Affinity to Open Source Tool just to eliminate cost but without mastering that tool.
7. Conquer the fear of “build” and “failure”.
8. Smart deployment is desirable.
9. Maintain the code standard
10. Limiting access.
11. Defining the logs
12. Test the application and the bots.
Missing of feasibility study
A proper project management is needed for implementing automation to any repetitive service. Failing to perform few analysis before start implementing automation and involving teams into that project not only increase your overall cost but also it may demotivate your team and your customer can loose confidence on you. You should first understand the goal and get it verified with your client to avoid any confusion at the end. Once your goal is fixed, you should pick those resources from your resource pool who has a prior experience in such project. At this point, you should also prepare the planning for this project. Involve your experienced resource to identify the right tools for you. Don’t forget to emphasize on skill-set while finalizing any tools. If you’ve no other option than to pick any new tool, you need to book the time and cost for training that has to be agreed before hand. It will help for the project continuation and it won’t freeze in the middle due to cost or lack of knowledge.
Mixing up automation with AI
We often get confused when we talk about automation and AI. Automation is not AI. It’s not a ‘smart’ product. Automation does exactly what you tell it to do, in the way you ask it to do it. This means that it doesn’t learn or adapt by itself. You must instruct it. If you tell it to do something incorrectly, it will complete the task incorrectly.
For this reason, it’s important to review the process your automation is completing. Make sure that there are no errors when setting up your automation solution, or you could make a long-standing and costly mistake. That is also a big reason why you need feasibility study at the first place.
Duplication of configurations
Duplication of configuration files and parameters are very bad for any project. When it comes to automation, it get even worst. You must not duplicate your configuration files. Rather you should keep it at a central place which will help you to manage and scale in the future if needed. We often face this issue when there is a mismatch in team co-ordinations. With the DevOps process in place, we can get some relief from this. However, you can not enforce DevOps practice over night.
Centralize your automation scripts in your code repositories
Automation scripts should be kept in a single place and in a sequential way. You should consider using any version based repository like Git or GitHub or so. Else, 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.
Ensure Security: Keep plain-text secrets in source control & re-use of secrets
Sometime, we end up plain text secrets or password in repository. Often it is the outcome of the negligence. When we need use session and need to decrypt the secrets multiple times, it is often kept in plain text thinking that we will encrypt everything before the final delivery. This often leads to a disaster. We should always keep any secret or password in a single place and in an encrypted way. Sometime, ignorance can lead to this disaster when you’re dealing any project with less skilled resource.
Tool selection: Affinity to Open Source Tool just to eliminate cost but without mastering that tool
Tool selection is one of the most important factor for any successful automation. We face many situation where desire doesn’t fit practicality. Let’s assume your specialty is in bash scripting but the best fit for your automation project is python. Now, you need to choose correct decision. Else, you may encounter failure.
In addition, we often encounter the situation where open source tools are given priority without even mastering on that tool. The priority is given just to align with the cost. This situation is dangerous. The trick is to find out first what you need to achieve, and only then you start looking for a tool that takes care of your target in the most efficient way regardless of how it is licensed. There is no doubt that open source tools are powerful and cost effective in many cases. But, you or your team should master on it prior to bring it into production. Otherwise, there is a possibility to end-up with security threats!
In summary, tools must be selected based on need and your capacity; you should not select it as some blog says so!
Conquer the fear of “build” and “failure”
Fear of failure can hold your progress unnecessarily. I fully agree with Tatum Hunter who correctly illustrated the points of fear in his article regarding “automation worst practices“. The relative importance of the task being automated shouldn’t affect how the automation gets built. The developers’ feelings toward the task shouldn’t be reflected in the automation script.
If we consider a deployment, deploying to production has normally been prioritized. Your developers may be tempted to write tentative, fail-safe automation for deployment pipelines because of their feelings toward what’s being automated.
But, here failure is a good thing. Failed deployments help refine automated pipelines, which saves time and effort later. Developers should recognize this, but with tasks that feel important, it’s harder to reconcile.
For better automation, we’ve to minimize both the effort and the importance of the tasks being automated. Sometimes, our emotions get in the way.
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 you learn from the failures and optimization.
Smart deployment is desirable
We should emphasize to make a deployment plan smarter. We should neither be timid nor aggressive while defining deployment plan. Because both of them have the potential to harm your project. It should be designed in such a way so that your team can manage the code effectively it afterwards.
Maintain the code standard
We often think that no one will ever touch the automated project. Even if automation means to eliminate the repetitive tasks, it doesn’t necessarily confirm the fact. The situation may change, the need may gets modified. In all respect, you need to redesign your automated project. So, the code that you write should follow the standard! It should be written clearly and with comment so that anyone can understand by taking a look.
Limiting access can be a tricky part. You have to be very careful while defining the access. At one end, you should not provide access to every member within your team. But, on the other hand you should not create a black box within the pipeline. You team should be able to view the logs and understand the behavior as and when needed. Otherwise, it may double the effort in the long run.
Defining the logs
Right alert needs to be configured. The log configuration should not spam your team for each and every error, but must not remain silent during actual event. So, it is an important factor to decide which error to monitor and which can be skipped. Often, we try to monitor and page everything, consequently, developers set a filter to get rid of the spamming. It may lead to a disaster!
Test the application and the bots
Test plan must be proper to validate the application outcome and the purpose of the bot. Automation project may fail in the long run if you fail to validate both.
Matthew Heusser has explained it well in his article.