About Python Fault management semi-automation experience [one]

recently, from the yard to the bitter forceFC The so-called FC is fault coordinator abbreviation, is responsible for coordinating the handling of fault related roles. FC is responsible for a particularly large number of chores, many of which are completely repetitive mechanized labor.

In doingFCOne of the responsibilities is to add a different branch of the change table to the developer for each Fault, so that all the branches affected by the Fault have related changes.
In the company's Turtle Speed Network, the creation of each branch is quite torture, and in fault particularly many cases, the workload is huge, basically an afternoon of time is gone. At the same time each fault need FC to help build a jira issue to get developers to work on the statistics, and this is undoubtedly manual labor.
In the case of helpless, you start writing Web automation tools to help with semi-automated repetitive work.
The need for this tool has been clear, that is, semi-automatic self-duplication of some of the work. Before you start coding, you need to make some relevant use of yourself.
Because the main operation is related to the fault management system, usually the manual tool is a Web browser, so it is basically dealing with HTTP more. And the language that can be quickly iterated seems to me to be the most appropriate python. The main reason is that the relevant library is relatively full, while the interaction of HTTP is better.
After the technical solution is determined, the following begins a quick iteration.
In the original software engineering is the waterfall model, that is, the requirements---design----------test--delivery, that is, the first difficult to get tools, this does not meet my situation, I need to quickly solve my pain points.
So I chose a fast iteration model, that is, every time I go out with a product, I have a feature I want, and then I need to add extra overtime to use it. This will free me from some physical activity. Of course, one of the problems in fast iterations is that the architecture design can change more frequently, which is detrimental to the subsequent extensibility of the code. Therefore, in the fast iteration, we must consider the robustness and extensibility of the architecture, and cannot write dead. The user experience is very good at the same time, at least it's a lot easier for me to get my own life.
When we have a good model, we start the real coding.
We need to use the reset API to Urlib/urlib2 and Jira, which makes it easy to simulate web-related operations.
In a fast iteration, it is necessary to understand what the user's most painful point is so that the tool makes it for the user to use. The biggest pain point before is that each fault creates Jira issue. Especially in the case of fault particularly many cases are particularly evident. I spent the whole morning on this.
With this basic pain point, you can begin to design the basic architecture of the software.

We can see the basic tool design as above, in fact the time series diagram is not very complex, so basically spent 2 days from design to function implementation.
In the so-called fault file, this fault file format choice also let me struggle for a long time, in the end how to choose the format it? Later, in order to facilitate Excel to make a diagram, you chose the CSV format, so it is easy to open in Excel. Python has a CSV-related processing library that makes it easy to process data.
While Jira's python reset is quite handy, many jira-related processing functions are provided directly from the API.
And their own real-time trial, found very useful.
At this point, the first phase of the iteration is completed

About Python Fault management semi-automation experience [one]