Your first step in automation

First write it down. The first step to move you to automation is to first write it down. You may think that you don’t have a process today that you can automate. But unless today is your first day in business you already have some process ready that you’re using. If you have code, an app, or a website that is in production that customers see, you have a deployment process. You have a deployment pipeline whether you realize it or not. Set aside 30 minutes to go through this activity. Depending on the complexity of your product and your (or your team’s’) familiarity with the process it could be longer or shorter, but 30 minutes is usually enough to give you an idea. If your deployment process is currently powered by a post it notes, you still have a process. You can move from no automation to simple automation. All you have to do is write it down. Don’t be embarrassed and think that you can’t have automation because your process is a mess. Don’t think, “I’m not there yet”. The way you get there is by starting now. What do you write down? You start by asking yourself some questions, and writing down the answers. What would happen if everything went perfectly? Just write that down. It might look something like: first a developer will push some code into a repository. What happens after that code is in the codebase? Just focus on the ideal path, don’t worry at the point about anything other than that. Does someone copy it to a test environment? Do they build it? Write that down. What happens when tests in the test environment succeeds? Does it go to a new environment? Write that down. Then does it get tested again? Write that down. Once it succeeds there what happens? Does it finally go to production? Perhaps the way it reaches production is by it getting copied to a server and a service getting restarted. Now that you have all of the steps written down go back through the list. And just note what actual action is associated with each of these steps. You may have to ask your team about this. Is the copying done by first putting your as ssh key somewhere? Write that down.

Do you have to copy it into a box or other secure environment first? Write that down. Once it’s up and running with the new code, how do you know it’s OK? Is there a graph that you check? Do you just refresh the web page many times? Is there a health endpoint you visit? Whatever it is, you guessed it, just write that down. Now let’s take a look at that list from the top. There are going to be steps where multiple actions could happen. At first we focused on everything going right, but now write down what happens if it doesn’t go well. What happens if the tests don’t pass? Do you file a ticket? Do you open an issue? What about when it reaches production and it doesn’t look good, the refresh doesn’t work, the graph isn’t happy or the health check is bad? Do you copy an old copy of the binary? Do you reboot first? Do you read logs? Whatever it is, just write that down.

Got that list? Okay good. You now have a solid foundation for building automation and reducing toil so that your team can focus on delivering features.

This list you’ve created isn’t just an intermediary step, it isn’t just a throwaway document. You now have a foundational document for onboarding new team members. So you have automation.

What do you think? Leave a comment! For more like this see here: https://thaiwood.io/DevTo