Introduction

** Overview of this article ** ** Causes of many beginners stumbling on deployment and countermeasures **

Deployment work that many programming beginners will stumble upon. I also developed a personal app last month and experienced the deployment work for the first time.

From the results, we were able to complete the deployment smoothly without much struggle. That doesn't mean that there were no errors at all. ** There was a normal setting omission. ** **

However, it didn't take much time as a whole because I was able to quickly identify the location of the setting omission.

Why many beginners stumble on deployment

It's just my personal opinion ...

** 1. There is a leak in the GUI settings (AWS, etc.) 2. I forgot to type a command in the CLI or misspelled 3. It takes time to identify the setting omission point 4. When an error occurs, I don't know what caused it, and for the time being, I'm groping around (oh, it's messed up). 5. I don't understand what each setting is for in the first place **

Regarding 5., it is good to understand the meaning of each work, but there are many difficult parts for beginners, so I think it can be honestly helped.

Other than that, I think that even beginners can take measures to some extent for 1-4.

1. Countermeasures for omission of settings in GUI

When setting on a browser such as AWS, ** I used to put a screenshot of all setting screens on the notebook app. ** **

I use Snipping Tool on Windows and ⌘ + shift + control + 4 on Mac to take screenshots with a specified range. (Full screen screenshots are fine.)

The screenshots I took are pasted on the notebook app as shown below.

Probably, when deploying, I think that I will proceed while looking at some teaching materials and reference articles, but if I proceed while comparing with the teaching materials every time I put a screenshot on a notebook, I think that the omission will be reduced considerably.

However, this method naturally takes time. However, it seems that there is often evidence of setting in practice, and I think it is better to get used to it now. The setting evidence can be used to determine the cause of the error described below, and above all, it is better to leave it to protect yourself in case of trouble.

2. Countermeasures for forgetting to type commands and spelling mistakes with CLI

For forgetting to type a command in the CLI (console screen, etc.), I took measures by pasting the screenshot of the command execution on the notebook application and checking for omissions one by one, as in the case of the GUI.

I think that spelling mistakes are also quite common mistakes, but as a countermeasure here, I tried not to enter commands directly by hand ** in the first place.

Basically, I used to copy and paste commands from the teaching materials, write the parts that depend on the personal environment such as IP address and user name in the notebook application in advance, and copy and paste them.

This is not limited to deployment, but basically if you prepare and check the command in advance and just copy and paste it when actually setting it, human error such as spelling mistakes will be reduced considerably. I will. Also, if you type directly into the CLI by hand, you may accidentally press the Enter key twice and execute a half-finished command ...

** Input to the CLI is basically fairly stable if you just paste it. ** **

3. Countermeasures against the time it takes to identify the setting omission location

The most ideal is to be able to identify the error location from the error message, but it may be a little difficult for beginners ... When that happens, I think there will probably be work to review the settings one by one.

At this time, it takes less time for the latter to review the settings of the relevant part while operating the ** GUI one by one and to review the work log. ** **

I also worked carefully while leaving a work log, but unfortunately there was a setting omission. However, ** I just reviewed the work log and found the leak immediately, so as a result it was not so important. ** **

4. About groping around

** I think this is basically taboo. ** ** It's okay if you have some idea of the cause of the error, but if you play with it from one end without thinking about anything, there is a high possibility that you will get hooked on the swamp. ** If it is a business, you should report it to your boss first, and if it is a school, you should consult a mentor first. ** **

I've been asked for help by someone who actually messed with the settings after the error, but why didn't they talk to me before this happened! !! !! I just thought ...

However, it may not be possible to isolate the cause without trial and error. I think that "try changing the settings for the time being" is allowed only when ** it has been confirmed that the settings can be restored **.

5. About not understanding what each setting is for in the first place

I think that it is a part that can not be helped to some extent for beginners, but it is good even after the deployment is completed, so it is better to investigate what is set for each work.

If the teaching materials are solid, basically you can complete the deployment without any problems if you follow the teaching materials, but the screen layout of the GUI changes and there are differences from the teaching materials. It is an image that will end up. (The setting items listed in the teaching materials may not be on the actual screen, or you may have to set them on another screen ...)

If you understand the meaning of each work at the time of deployment, even if the screen layout is slightly different from the teaching material, you can set it well.

Summary of good things to do

--Leave evidence for each setting screen and command execution log --Do not enter commands manually as much as possible --Check the meaning of each setting

[RAILS] [AWS] What I'm glad I did with my first deployment