From a small bug to azure Devops


1. A small bug

Recently, I mentioned a bug a few years ago with my colleagues. It was a very small bug with little technical content. At that time, I just joined the company. It happened that the company sold an instrument to a certain country, but there said that the supporting software could not run. As soon as I opened it, I reported an error. The error code found after troubleshooting is very simple, which is roughly as follows:

public static int GetSecond(DateTime time)
    return Convert.ToInt32(time.ToString().Split(":")[2]);

I couldn’t laugh or cry at that time. This code should be migrated from the old language. If it is only in China, there is no problem at all, but if it is put abroad, it may report an error, because different regions and languages will have different time formats. For example, the time display format in Canada is different, and the second is followed by a time indicating noon / afternoona.m/p.m., this can be changed in the codeThread.CurrentThread.CurrentCultureTo verify:

var time = new DateTime(2000, 1, 20, 1, 2, 3);
Console. WriteLine(time); \\  Output 2000-01-20 1:02:03
Thread.CurrentThread.CurrentCulture = new System.Globalization.CultureInfo("en-CA");
Console. WriteLine(time); \\  Output 2000-01-20 1:02:03 a.m.

As for the tester, the area format in “time and language – > Language & region” in the system setting can beEnglish (Canada)To verify:

However, neither developers nor testers found any problems. At that time, this outrageous bug spread its wings, flew over the mountains and the sea, and flew to the hands of foreign customers. The whole team from top to bottom, from development to testing, didn’t find the whole bug. Maybe the team has problems in technology and process, so I have to suspect that I’m in a big hole.

If you take a cut, you should learn a lesson. Although it is only a small bug, it also reflects the lack of team technology and code process. In order to avoid this situation again, we need to start from two aspects: team cultivation and process improvement. Team development is another topic. This article only talks about process improvement. At that time, we were already using TFs (the predecessor of azure Devops), but it was only used for code management and many functions were not used. Later, azure Devops continued to improve, and we also used its more functions to help us improve product quality. This article takes the small bug at the beginning of the article as an example to briefly explain the process of azure Devops processing it.

2. Record and start processing this bug on azure Devops

First, suppose I have managed code in azure Devops and configured pipeline and other infrastructure. Now I only need to deal with this bug.

The first step is to add a bug. In addition to the title of the bug, the detailed content of the bug can also add reproduction steps, system information, etc. if there is an error log, it can also be added to the bug as an attachment.

After the team understands and agrees with the contents of this bug, theBoardsRemove it fromNewDrag toApproved, and in···Selected from the drop-down menuAdd TaskandAdd TestAdd tasks and test cases respectively.

I randomly added two tasks and a test case.

3. Fix bugs and add unit tests in Visual Studio

Then it’s up to the developer in charge of handling the bug in the team to take over the work. Open visual studio, create a new branch, repair the bug, and add a corresponding unit test according to the unit test methods of range, act and asset:

public void GetSecond_DifferentCultureInfo_Succeed()
    var time = new DateTime(2000, 1, 20, 1, 2, 3);
    Thread.CurrentThread.CurrentCulture = new System.Globalization.CultureInfo("en-CA");
    var second = DateTimeUtils.GetSecond(time);
    Assert.AreEqual(second, time.Second);

    Thread.CurrentThread.CurrentCulture = new System.Globalization.CultureInfo("zh-CN");
    second = DateTimeUtils.GetSecond(time);
    Assert.AreEqual(second, time.Second);

Run unit tests to ensure that all unit tests have passedGit changeThe panel submits the information of the bug, enters the ID of the associated work item, and then clickSubmit all and push

When you return to the code editor after the push is successful, you can see that the codelens on the modified function has a green icon that the unit test to be changed has passed. Put the mouse up to show which unit tests it has been verified by.

“4 work items” are displayed on the far right of the codelens of the modified function and related unit tests. When you put the mouse up, you can see the work items associated with the previous code submission.

4. Enter the acceptance code in the pull request

The next operation needs to go back to azure Devops. The new code cannot be checked into the main branch casually. You need to create a pullrequest to notify the relevant personnel of the code change, and record the associated work item, modified code, who needs code review, etc. in this pullrequest. It sounds like a lot. In fact, developers who submit code only need to click Create pull request, select the branches to be merged, and then click create. Almost all other contents are automatically filled by azure Devops.

Pull request requires at least two checks. One is the automatic unit test, which requires all unit tests in the code to run and pass. The other is code review. Azure Devops can set various code review policies, including the minimum number of code review people, resetting all audits when there are changes, etc. In addition to ensuring the quality of checked in code, code review is also an embodiment of collective ownership of code. Collective ownership of code is an important element in agile. It ensures the inheritance of knowledge in the team and promotes the improvement of ability.

The following figure shows a completed pull request. You can see several green icons representing how many “processes” it has passed. You can also see its associated work items, who created them, which branch merged them, and where.

Switch toFilesTab, you can see the specific code changes:

5. Test verification and test cases

After completing the above steps, remove the bug from theApprovedDrag toCommittedAnd set the associated two tasks to complete. After the code is merged into the master, azure pipeline will automatically compile and deploy the latest code, and then notify relevant testers by email or teams. The tester opens it after receiving the noticeBoard, when it sees that all the tasks of the bug have been completed (next to the Yellow Icon)2/2), he knew it was time to start testing and acceptance. On the right side of the test case after completing the test···Select the test results from the drop-down menu. If successful, selectPass testAnd drag this bug toDone

At this point, the bug processing has been completed. In order to prevent errors from happening again, developers added unit tests, and all relevant personnel shared their experience through this process, which made both the code and the team stronger. But this is not the end. The test cases contained in this bug are another valuable asset left by it and need to be treated with caution. Open this bug, which can be in the lower right cornerTested BySee its test cases in the section.

Click this test case to view the details, and you can see itsSteps(I’m too lazy to write here), and various related work items.

Azure Devops provides the test plans module to manage test cases and test plans. Various test cases generated in the development process are finally integrated into the test plan, and the testers ensure that the functions that have been run correctly will not make mistakes again. However, this part is only open to charging users. I have the opportunity to introduce its various functions in detail.

6. Finally

Now the company’s code has set up a home on azure Devops, and a series of processes are running smoothly (although there are still many places to improve). Although the software functions have expanded several times, there are fewer after-sales feedback problems. Looking back at the bug a few years ago, the code production mode and code quality at that time were really different from today, and azure Devops contributed a lot.

Finally, if you want to try azure Devops, you can not follow the process I wrote. The process introduced in this article is only a simplified version, which is slightly different from the actual work, and should be flexibly changed according to the actual situation of your team to create your own and your team’s process (fortunately, azure Devops can be quite flexible).

For more information about azure Devops, please refer to the official documents:

Azure DevOps documentation _ Microsoft Docs