WO2015186256A1

WO2015186256A1 - Development support system

Info

Publication number: WO2015186256A1
Application number: PCT/JP2014/065140
Authority: WO
Inventors: 中村　秀樹; 晶田中; 前岡　淳
Original assignee: 株式会社日立製作所
Priority date: 2014-06-06
Filing date: 2014-06-06
Publication date: 2015-12-10
Also published as: JP5973091B2; JPWO2015186256A1

Abstract

This development support system automatically associates an issue, a branch, a commit and the like while suppressing an increase in the number of branches generated corresponding to the issue in a social coding system. The development support system includes: a repository management system that keeps a developed product and a modification history thereof in a repository; and a social coding system that manages the developed product and the issue in association with each other. The social coding system includes an issue management unit that manages information of the issue, and a branch processing unit that generates a branch in the repository. The branch processing unit identifies a first branch as a branch source on the basis of the information of the issue that has been designated, and generates a second branch branched from the first branch and corresponding to the issue.

Description

Development support system

The present invention relates to a program development technique, and more particularly to a technique that is effective when applied to a development support system that supports program development using a social coding system.

In recent years, in program development, in addition to a so-called repository management system that registers development products such as source code, design documents, and specifications in a repository for version management and change history management, issue management in development projects (Issue) A so-called social coding system having a management function for a development process, such as a function for reviewing a product, reviewing a product, and reflecting it in a repository, is being used. The social coding system has, for example, a function for creating a branch for development / modification in a repository and a Pull request function for merging a branch including a development product into the repository. An example of the social coding system is GitHub (Non-Patent Document 1).

As a related technology, for example, JP 2013-191003 A (Patent Document 1) describes a branch that automatically creates a branch from a pending registration by linking the repository management system and the pending management system. A repository management system is described.

JP 2013-191003 A

The social coding system described in Non-Patent Document 1 and the like uses, for example, an issue management function to manage development products and issues in association with each other, and after designers discuss problems and new functions Development of programs and other software in such a way that the developer actually corrects the source code, releases the correction difference, performs the source code review by the reviewer, and merges (integrates) it into the repository if there is no problem. It is a tool to support.

However, for example, in order to manage source code modification differences, it is necessary to manually create a branch on the repository before performing source code modification. In addition, when a source code review is performed, in order to enable a reviewer to grasp which problem (Issue) the correction is related to, for example, when a source code correction is registered (committed) It is necessary to manually associate and associate a number (such as an issue) with a comment (commit comment). In addition, regarding the source code to be corrected, it is also necessary to manually specify in advance which branch should be merged after the review is completed.

In this way, since it is necessary to manually associate issues (issues), branches, commits, etc., the burden on the user is heavy, and for example, the association is forgotten or mistakenly associated with a mistake. There was a problem that there was a case where I could get lost.

Further, the branch repository management system described in Patent Document 1 is not a system that assumes a social coding system, but simply generates a branch as an association between a concern and a branch. The problem cannot be solved. In addition, when the branch repository management system described in Patent Document 1 is applied to program development using a social coding system, it is recommended that problems be registered in small units. Issue) is registered, and as a result, many branches are created, and there is a problem that the operability of branch operations such as selection and display of branches is greatly reduced.

SUMMARY OF THE INVENTION Accordingly, an object of the present invention is to provide a development support system that automatically associates issues (issues), branches, commits, and the like while suppressing the number of branches generated corresponding to the issues (issues) in a social coding system. It is in.

The above and other objects and novel features of the present invention will be apparent from the description of this specification and the accompanying drawings.

Of the inventions disclosed in this application, the outline of typical ones will be briefly described as follows.

A development support system according to a representative embodiment of the present invention includes a repository management system that holds a development product and its change history in a repository, and a social coding system that manages the development product and a problem in association with each other. The social coding system includes: an assignment management unit that manages information on the assignment; and a branch processing unit that generates a branch in the repository, wherein the branch processing unit is designated. Based on the information on the issue, a first branch that is a branching source is identified and branched from the first branch to generate a second branch corresponding to the issue.

Among the inventions disclosed in the present application, effects obtained by typical ones will be briefly described as follows.

In other words, according to the exemplary embodiment of the present invention, in the social coding system, the association of issues (issues), branches, commits, etc. is automatically performed while the number of branches generated corresponding to the issues (issues) is suppressed. By doing so, it becomes possible to improve the work efficiency in the source code correction work, and hence the software development work.

It is the figure which showed the outline | summary about the structural example of the development assistance system which is one embodiment of this invention. It is the figure which showed the outline | summary about the structural example by the branch of the branch on the repository in one embodiment of this invention. It is the table | surface which put together the kind of branch and naming convention in one embodiment of this invention. (A), (b) is the figure which showed the outline | summary about the data structure of the problem management information in one embodiment of this invention, and the example of concrete data. It is the figure which showed the outline | summary about the example of the data structure of the development function information in one embodiment of this invention. It is the figure which showed the outline | summary about the example of the data structure of the malfunction information in one embodiment of this invention. (A), (b) is the figure which showed the outline | summary about the data structure of the label information in one embodiment of this invention, and the example of concrete data. It is the flowchart which showed the outline | summary about the example of the flow of the automatic generation process of the branch in one embodiment of this invention. It is the flowchart which showed the outline | summary about the example of the flow of the automatic addition process of the commit comment in one embodiment of this invention. It is the figure which showed the outline | summary about the example of the repository display screen in one embodiment of this invention. It is the flowchart which showed the outline | summary about the example of the flow of the automatic designation | designated process of the branch in one embodiment of this invention. It is the figure which showed the outline | summary about the example of the Pull request screen in one embodiment of this invention. It is the figure which showed the outline | summary about the example of the Pull request screen in one embodiment of this invention. It is the figure which showed the outline | summary about the structural example of the conventional development assistance system using a social coding system. It is the figure which showed the outline | summary about the example of the work flow at the time of the development in the conventional development assistance system using a social coding system. It is a class diagram showing the example of the relationship of the data handled by the development in the conventional development support system. It is the figure which showed the example about the specific correspondence between the subject in a conventional development support system, a branch, a commit, and a Pull request. It is the figure which showed the outline | summary about the example of the processing image in the repository management system and social coding system in the conventional development assistance system.

Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings. Note that components having the same function are denoted by the same reference symbols throughout the drawings for describing the embodiment, and the repetitive description thereof will be omitted. In the following, in order to make the features of the present invention easier to understand, the description will be made in comparison with the prior art.

<Overview>
FIG. 14 is a diagram showing an outline of a configuration example of a conventional development support system using a social coding system. The development support system 1 has a configuration in which each information processing system of the social coding system 100 and the repository management system 200 and a user terminal 400 that is an information processing terminal of a plurality of users are connected via a network 500. . Furthermore, you may have the task management system 300 which manages a task separately.

The repository management system 200 includes, for example, a repository management unit 210 that manages a repository held in a repository database (DB) 201, a branch management unit 220 that manages a branch created on the repository, and for development in the repository. A merge processing unit 230 that merges (integrates) the branch that has been created and branched is merged with the branch that is the branch source. Each of these units is implemented by, for example, a software program.

On the other hand, the social coding system 100 includes, for example, a user authentication unit 110 that performs processing such as authentication for a user such as a developer, and a problem (Issue in a development project held in the problem DB 101, hereinafter simply referred to as “issue”. And a branch processing unit 130 that performs various processes on the branch on the repository via the repository management system 200. Each of these units is also implemented by, for example, a software program. As the social coding system 100, for example, the above-described GitHub, GitLab, and the like are known. Note that the assignment management unit 120 may be replaced by the assignment management unit 310 of the assignment management system 300, or may be configured to manage the assignment DB 101 in parallel.

Each user terminal 400 used by each developer has a social coding client 410 that is a client application of the social coding system 100. The social coding client 410 allows each developer to perform development related to an issue, so that a part or all of a repository including a branch created for development can be imported from the repository DB 201 to the local repository DB 401 as necessary. Each unit includes a repository processing unit 411 for performing processing related to the repository, and an issue processing unit 412 for managing issues to be developed. The social coding client 410 may be entirely or partially implemented as a dedicated client application program, or may be implemented as a web application that runs on a web browser in cooperation with the social coding system 100. .

FIG. 15 is a diagram showing an outline of an example of a work flow at the time of development in a conventional development support system using a social coding system. First, a designer or a development leader or the like examines new function development or countermeasures for defects (bugs) (S1). At this time, the problem created as the examination result is newly registered in the problem DB 101. Specifically, as information representing the problem, for example, a change slip is issued on the system in the case of function development, and a failure slip is issued on the system in the case of failure countermeasures.

Next, response is started based on the registered issue (issued change slip or defect slip) (S2). More specifically, a management branch is created on the repository DB 201 for development related to the subject. The processing so far is performed on the social coding system 100 and the repository management system 200 by a designer, a development leader, a project manager, or the like (hereinafter, these may be collectively referred to as “leader”). It is normal.

Next, as preparation for development, the developer takes in the above management branch into the local repository DB 401 and creates a branch for the developer (S3). Thereafter, the developer performs development corresponding to the created developer branch (S4). Specifically, source code is created / modified, a manual test is performed, and the source code after the test is registered (committed) in the developer branch. Furthermore, a fetch request (Pull request) to the management branch is made for the developed part (S5). Specifically, the latest management branch is fetched from the repository DB 201 to the local repository DB 401, reflected in the developer branch, and then requested to the repository management system 200 for fetching to the management branch (Pull). Request).

When a Pull request is made, the reader reviews the development contents in the developer branch on the social coding system 100, performs an automatic test or the like as necessary, and if there is no problem, merges it into the management branch. Capture (S6). After that, further review as a task is performed, an automatic test or the like is performed as necessary, and if there is no problem, this is taken in by merging into the main branch and released to the production environment or the like (S7).

Here, for example, in steps S2 and S3, a branch for management is created for each function development or defect handling case, and a developer branch is provided for each developer so as to enable distributed development by a plurality of developers. However, in the development in the conventional development support system, these branches need to be created manually, which is complicated and has a high workload.

When the source code is developed in step S4 and the test is completed, the development branch is committed. Since each commit corresponds to the issue created in step S1, each commit is performed. Although it is necessary to associate with a corresponding problem, this also needs to be done manually at present, and is complicated and has a high workload.

Further, in step S5, a Pull request is created in order to merge the development part related to the commit performed in step S4 into the corresponding management branch. However, the processing is premised on merging between the branches. Therefore, it is necessary to specify a developer branch as a merge source and a management branch as a merge destination at the time of a Pull request, but this also needs to be done manually at present.

FIG. 16 to FIG. 18 are diagrams for explaining the situation in development in the conventional development support system as described above in more detail. FIG. 16 is a class diagram showing an example of the relationship of data handled in development in a conventional development support system. As shown in the figure, the social coding system 100 or the problem management system 300 manages problems. Further, the social coding system 100 manages Pull requests. Further, the repository management system 200 (including the local repository DB 401 on the user terminal 400) manages branches and commits.

As described above, the problem is divided into a change slip that manages function addition items and a failure slip that manages defect correction. When starting the development work, a function development branch or defect correction branch corresponding to the problem is created as a management branch on the repository of the repository management system 200. However, as described above, these branches need to be created manually at present. Therefore, it is also necessary to manually perform association (link creation) between the change slip or defect slip and the function development branch or failure correction branch (indicated by a dotted line in the drawing). In the technique described in Patent Document 1, a function development branch corresponding to a change slip (corresponding to a pending matter in Patent Document 1) can be automatically created. There is no mention of branches.

At the time of development work, as described above, a developer branch (development branch for function development or developer branch for defect correction) is provided for each developer so that multiple developers can independently perform distributed development in parallel. However, in the development in the conventional development support system, it is necessary to manually create these developer branches. Note that the technique described in Patent Document 1 does not mention creation of a branch corresponding to a developer branch.

∙ After creating the developer branch, development such as source code creation / modification and testing is performed, and the completed one is registered as one commit. As described above, each commit corresponds to an issue. Therefore, it is necessary to make an association with the corresponding issue (actually the corresponding change slip or defect slip) for each commit, but this must also be done manually at present (indicated by dotted lines in the figure) ) As shown in the figure, a commit can be divided into a plurality of items for registration.

Then, a Pull request is created in order to merge (integrate) the development branch corresponding to the commit into the corresponding management branch (function development branch or defect correction branch). The actual branch merge process is performed after review, approval, etc. for the Pull request. As described above, in the Pull request, it is necessary to specify the developer branch that is the merge source and the management branch that is the merge destination. In addition, a Pull request always corresponds to one of the issues (actually corresponding change slip or defect slip), but in order to associate them with the system and manage them, for example, the issue corresponding to the comment of the Pull request It is necessary to manually describe the identification information of these (in the figure, the relationship is indicated by a dotted line).

Plural requests are associated with a plurality of commits, but if a merge-source development branch and a merge-destination management branch are specified, the merge request is not in the merge-destination management branch. Commits, that is, all commits that are registered by branching from the merge destination management branch to the merge source development branch. Normally, in the repository management system 200, a branch is always created by being derived from one parent branch, that is, every branch is always created by branching from a part of the parent branch. A commit corresponding to the Pull request can be identified.

FIG. 17 is a diagram illustrating an example of a specific correspondence between the issues, the management branch, the development branch, the commit, and the Pull request as described above. That is, in the function development case, the change slip and the function development branch are associated one-to-one, and the function development branch is associated with the function development developer branch for each developer on a one-to-many basis. A function development developer branch is associated with a plurality of commits (function development modification commits) in a one-to-many manner. A plurality of function development modification commits are associated with one Pull request (function development modification Pull request) in a many-to-one relationship, and this function development modification Pull request is associated with the change slip on a one-to-one basis.

The correspondence between the function development branch and the function development developer branch is associated with the function development modification Pull request on a one-to-one basis. That is, the development part related to the developer branch for function development of each developer is merged into the branch for function development by one function development modification Pull request. Note that the correspondence as described above is the same in the defect countermeasure case, and thus the description thereof will be omitted.

FIG. 18 is a diagram showing an outline of examples of processing images in the repository management system 200 and the social coding system 100. The local repository DB 201 of the repository management system 200 shows a state in which a branch hierarchical structure is held. A clone (copy) is created in the local repository DB 401 of the user terminal 400 for each developer for all or part of the contents of the repository, and development is performed based on the clone. The repository on the local repository DB 401 in which the completed development content is registered is pushed (reflected) to the repository DB 201 of the repository management system 200.

On the social coding system 100 (or the problem management system 300), problems (such as “change slip (C0001)” and “failure slip (B0011)” in the example of FIG. 18) are created, and these issues and corresponding issues Thus, the association with the branch created on the repository DB 201 is performed. In addition, on the social coding system, a Pull request (such as “Pull request (# 1)” in the example of FIG. 18) for reflecting the development contents on the repository DB 201 is created, and between the Pull request and the issue. Association is performed. As described above, these associations must be performed manually at present, and are complicated and have a high workload.

As described above, in the technique described in Patent Document 1, when a new problem is registered on a problem (corresponding to the issue in Patent Document 1) management system, a corresponding branch is automatically created, and the created branch Since the association between a task and a task can be managed, the workload as described above can be reduced to some extent. However, the repository management system 200 is premised on a known version management tool such as Subversion (registered trademark), the branch source in the branch hierarchy is limited to a specific branch (for example, “trunk”), and a branch is assigned to each problem. There is a restriction that it cannot be divided.

In addition, when the number of issues is large, the number of branches becomes enormous, making management difficult, making it difficult to select and switch branches from a large number of branches on the user interface, and the visibility of the graph display to deteriorate Have problems. Further, since the branch is branched in the state at the time of branch creation, depending on the timing of branching, there may be a waste of import work related to other corrections.

Therefore, the development support system according to one embodiment of the present invention starts the development work from the latest state as much as possible by automatically creating branches at the timing when branch creation is necessary, thereby minimizing the number of branches. It can be so. Also, by automatically associating assignments, branches, commits, and pull requests, the workload is reduced and the work efficiency in software development work is improved.

Specifically, for example, when a task is created or the state changes, a branch corresponding to the task is automatically created. At that time, a branch source branch is automatically specified based on the created task information. As a result, the branch is automatically created at the timing of the creation of the assignment, and the association between the assignment and the branch is automatically performed (for example, according to a branch naming rule).

Also, based on the branch information (for example, the name of the branch in accordance with the naming rule), the identification information of the change slip or defect slip corresponding to the branch is determined, and the information is given to the commit comment. As a result, the association between the commit and the issue (change vote or defect vote) is automatically performed.

Also, based on the branch information (for example, the name of the branch according to the naming rule), the branch that becomes the merge destination (branch source) is determined, and based on the information, the merge destination that is required when creating the Pull request And automatically specify and complete the merge source branch name. Thereby, the Pull request is automatically associated with the branch and the assignment.

<System configuration>
FIG. 1 is a diagram showing an outline of a configuration example of a development support system according to an embodiment of the present invention. As in the conventional development support system 1 shown in FIG. 14, the development support system 1 according to the present embodiment includes information processing systems such as the social coding system 100 and the repository management system 200, and information processing terminals of a plurality of users. A user terminal 400 is connected via a network 500. Furthermore, you may have the management system 300 which manages the problem separately. The social coding system 100 (or issue management system 300) has an issue DB 101, and the repository management system 200 has a repository DB 201.

The social coding system 100 and the repository management system 200 are application servers, and the assignment DB 101 and the repository DB 201 are configured as DB servers. Each of these application servers and DB servers may be configured by server devices, or may be configured by one instance of a virtual server configured on a server device or a cloud computing service. Moreover, you may be comprised by mixing these.

In the figure, each of these servers has an independent configuration, but all or a part of them may be integrated into one server device or the like. Further, the connection between the social coding system 100 and the assignment DB 101 or between the repository management system 200 and the repository DB 201 is not limited to a dedicated line, and may be connected via the network 500. The network 500 may be either the Internet or an intranet, and the physical layer is not particularly limited, such as a wired LAN (Local Area Network), a wireless LAN, or a packet line.

The repository management system 200 is similar to the conventional development support system 1 shown in FIG. 14, for example, a repository management unit 210 that manages a repository held in the repository DB 201, a branch that manages a branch created on the repository The management unit 220, and a merge processing unit 230 that merges a branch created and branched for development in the repository into a branch source branch. Each of these units is implemented by, for example, a software program.

In the present embodiment, for example, Git, which is an open source distributed repository management tool, is assumed as the repository management system 200, but other distributed repository management tools such as Mercurial (hg) can also be used. is there. Note that, for example, even if a central repository management tool such as Subversion (registered trademark) is used, although the configuration changes such that the local repository DB 401 is not required in the user terminal 400, the development support system 1 of the present embodiment is in principle. It is possible to apply to. However, in actual social coding, since development and correction are frequently performed by multiple developers, other development work is often stopped by exclusive processing of the repository. Therefore, it is desirable to use a distributed repository management tool.

The social coding system 100 is, for example, similar to the conventional development support system 1 shown in FIG. 14, a user authentication unit 110 that performs processing such as authentication for a user such as a developer, and development projects held in the problem DB 101. And a branch processing unit 130 that performs various processes for the branch on the repository via the repository management system 200. Each of these units is implemented by, for example, a software program. The assignment management unit 120 may be replaced by the assignment management unit 310 of the assignment management system 300, or may be configured to manage the assignment DB 101 in parallel.

The social coding system 100 according to the present embodiment further includes a pull request processing unit 140 that receives pull requests from each user terminal 400 and performs processing related thereto. The issue management unit 120, the branch processing unit 130, and the pull request processing unit 140 according to the present embodiment have a function for automatically associating issues, branches, commits, and pull requests as described above. ing. Details of these functions will be described later.

The user terminal 400 is an information processing terminal such as a PC (Personal Computer) used by a developer, but may be a portable terminal such as a smartphone or a tablet terminal. Similarly to the conventional development support system 1 shown in FIG. 14, the user terminal 400 includes a social coding client 410 that is a client application of the social coding system 100 and a local repository DB 401. The social coding client 410 includes various units such as a repository processing unit 411 for performing processing related to a repository and an issue processing unit 412 for managing issues to be developed.

The social coding client 410 according to the present embodiment further includes a commit processing unit 413 that performs processing for committing (registering) the developed source code and the like to the development branch, and for management on the repository management system 200. Each unit includes a pull request creation unit 414 that performs processing related to creation of a pull request for requesting incorporation into a branch. Each unit of the social coding client 410 according to the present embodiment has a function for automatically associating assignments, branches, commits, and pull requests as described above in cooperation with the social coding system 100. ing.

<Prerequisite branch operation>
FIG. 2 is a diagram showing an outline of a configuration example by branching on the repository in the present embodiment. FIG. 3 is a table summarizing the branch types and naming conventions shown in FIG. In FIG. 2, the time series is shown in the horizontal direction (time t has passed from left to right), and the type of branch is shown in the vertical direction. A black circle represents a commit, that is, a fixed source code modification difference.

As shown in FIG. 2, in this embodiment, the latest development branch is “trunk”. This is a branch to which all functions of the latest version are added (referred to as “latest development branch”), and becomes a main branch in new function development (enhancement development). In the example of FIG. 2, in function development (enhancement development), a branch “feature / C001 / DEV” is created by branching upward from the “trunk” branch. This is a branch for management for developing a new function “C001” by a team (generally called “branch for function development”), and is a branch for storing development products of the entire team. By assigning a branch name according to the naming rule shown in FIG. 3, the type of branch and the function name (“C001” in the example of FIG. 2) can be grasped from the branch name.

In the example of FIG. 2, a branch “feature / C001 / user2” is created by further branching from the “feature / C001 / DEV” branch. This is a branch dedicated to the developer “user2” who develops the function “C001” (collectively referred to as “developer branch for function development”), and is a branch for storing work products of “user2” individuals. . By assigning a branch name according to the naming convention shown in FIG. 3, the branch type and function name (“C001” in the example of FIG. 2) and developer (“user2” in the example of FIG. 2) are changed from the branch name. I can grasp it.

On the other hand, in the example of FIG. 2, branches “stable / v0001” and “stable / v0002” are created by branching downward from the “trunk” branch. These are branches (collectively referred to as “stable branches”) that store reference versions of items that have already been shipped, such as packaged products, and require maintenance such as dealing with defects. It becomes the main branch for defect correction. By assigning a branch name according to the naming rule shown in FIG. 3, the branch type and version (“v0001” and “v0002” in the example of FIG. 2) can be grasped from the branch name.

In the example of FIG. 2, a branch “fix / B011 / v0001 / DEV” is created by further branching from the “stable / v0001” branch. This is a management branch (collectively referred to as “defect correction branch”) for dealing with the defect “B011” by the team, and a correction created for the defect “B011” by the entire team. A branch that stores code. By assigning a branch name according to the naming rule shown in FIG. 3, the type and version of the branch (“v0001” in the example of FIG. 2) and the defect name (“B011” in the example of FIG. 2) are grasped from the branch name. can do.

In the example of FIG. 2, a branch “fix / B011 / v0001 / user1” is created by further branching from the “fix / B011 / v0001 / DEV” branch. This is a branch dedicated to the developer “user1” that handles the defect “B011” (collectively referred to as “defect correction developer branch”), and is a branch that stores the work product of the individual “user1”. It is. By assigning branch names according to the naming rules shown in FIG. 3, the branch name to branch type and version (“v0001” in the example of FIG. 2), defect name (“B011” in the example of FIG. 2), and development The user ("user1" in the example of FIG. 2).

For example, a branch for developers (such as “Developer branch for function development” or “Developer branch for defect correction”) is created when function development and defect correction are performed directly by the developer, not by the team. It is also possible to set it not to operate.

Further, the branch naming rules (naming rules) are not limited to those shown in FIG. 3, but as described above, “latest development branch” / “function development branch” / “function development developer branch”. , And “stable branch” / “branch correction branch” / “defect correction developer branch”, a parent-child relationship is established between the branches, and the relationship is named so that the relationship can be grasped from the branch name. It is assumed that

<Data structure>
Hereinafter, the data configuration of the assignment DB 101 managed by the social coding system 100 or the assignment management system 300 will be described. FIG. 4 is a diagram showing an overview of the data configuration of the task management information 101a, which is one of the tables in the task DB 101, and specific data examples. FIG. 4A shows a data structure, and FIG. 4B shows a specific example of data. The assignment management information 101a is a table that holds information about the contents of each assignment, and includes items such as an assignment ID, a title, details of contents, a person in charge, a milestone, a state, and a label ID list.

The item of issue ID holds information such as ID and sequence number that can uniquely identify each issue. The title item holds information on the title and name assigned to the target task. As shown in FIG. 4B, the title format is, for example, “[issue identifier] _text”, and includes information on an issue identifier (for example, “C001”) that can uniquely identify each issue. It may be. In the case where the value of the above-mentioned assignment ID item is used as the assignment identifier, the assignment identifier may not be included in the title item.

・ Detailed content item stores detailed information about the content of the subject. For example, information describing the contents of corresponding function development or defect correction can be included. The item of the person in charge holds information for specifying the person in charge, the manager, the person in charge, etc. of the subject issue. The milestone item holds milestone information indicating which version of the target issue is to be dealt with. The status item holds information on the status and status of the target task. The item of the label ID list holds information of a list of label IDs that specify one or more labels set for the target task. Each label ID is defined in a table of label information described later.

Note that the task management information 101a includes, for example, each of function development and defect correction so that, when the task is function development or defect correction, information relating to the contents can be specialized and retained. You may have a table for every subject. FIG. 5 is a diagram showing an outline of an example of the data configuration of the development function information 101b that holds information related to the contents of the function to be developed in a case where the problem is function development. FIG. 6 is a diagram showing an outline of an example of a data configuration of defect information 101c that holds information related to the content of the defect to be corrected, specialized when the problem is defect correction. The items of the development function ID of the development function information 101b and the defect ID of the defect information 101c are items corresponding to the problem ID of the problem management information 101a, respectively. In addition, the defect information 101c includes an item of an occurrence version that holds information on a version in which the target defect has occurred.

FIG. 7 is a diagram showing an overview of the data configuration of the label information 101d, which is one of the tables in the assignment DB 101, and specific data examples. The label information 101d is a master table that holds definition contents of information obtained by labeling and encoding information such as various character strings set for the task, and includes items such as a label ID and a label name. The label ID item holds information such as an ID and a sequence number that can uniquely identify each label. The label name item holds information such as a character string of a label corresponding to the label ID.

Note that the data configuration (items) of each table shown in FIGS. 4 to 7 is merely an example, and other table configurations and data configurations can be used as long as similar data can be held and managed. It may be.

<1. Automatic branch generation>
In the present embodiment, as described above, for example, when a task (change slip or defect slip) is created in step S1 of FIG. 15 or when the state of the task changes, the task in steps S2 and S3 of FIG. Based on the information, a branch corresponding to the subject can be automatically generated. The automatic branch generation process will be described below.

When the management branch (“functional development branch” or “defect correction branch”) in step S2 of FIG. 15 is automatically generated, for example, in the problem processing unit 412 of the user terminal 400 shown in the example of FIG. When a task (change slip or defect slip) is newly created or modified by an instruction / operation from the user, the task management unit 120 of the social coding system 100 registers the task in the task DB 101 in cooperation with the task. Or correct it. Then, the branch processing unit 130 is called with the registration / correction in the problem DB 101 as a trigger, and the branch processing unit 130 generates a branch corresponding to the problem.

FIG. 8 is a flowchart showing an outline of an example of a flow of automatic branch generation processing in the branch processing unit 130. First, a task identifier that can uniquely identify the task is extracted from the task information (S01). Examples of the problem identifier include a development item in function development and an ID assigned corresponding to the indicated defect in defect correction. For example, the ID of a change slip (for example, “C001”, etc.) issued for each development item in function development, or the ID of a failure slip (for example, “B011”, etc.) issued for each indicated failure in defect correction is used. it can. In the present embodiment, for example, in the case of a change slip, the first character of the ID is “C” (Change), and in the case of a failure slip, the first character of the ID is “B” (Bug). It is possible to determine whether it is a change slip or a failure slip. Other items may be used as the assignment identifier as long as the assignment can uniquely identify the assignment.

For example, the branch identifier 130 or the task manager 120 of the social coding system 100 accesses the task DB 101 to extract the portion corresponding to the task identifier from the task ID of the target task or the title item. can do. In the present embodiment, as described above, in the assignment management information 101a of the assignment DB 101, the format of the assignment title is, for example, “[assignment identifier] _text”, and information on the assignment identifier is extracted from the character string of the title. Is possible. Also, when managing issues related to defect correction for each version, version information may be acquired by processing to be described later and added to the information of the issue identifier.

In the present embodiment, the social coding system 100 has been described on the assumption that the problem DB 101 has the problem management and the problem is managed by the problem management system 300 independent of the social coding system 100. May refer to the task information managed by the task management system 300 and extract the task identifier.

Next, it is determined whether or not the problem is compatible with the defect (S02). If the problem is compatible with the defect, information on the version in which the problem has occurred is acquired (S03). In the case of function development in which the problem is not dealing with defects, the process proceeds to step S04 without performing step S03. As the processing in step S03, for example, the branch processing unit 130 or the problem management unit 120 accesses the problem DB 101, and acquires the value of the item in the label ID list for the target problem from the problem management information 101a. Then, for each label ID in the label ID list, all the labels corresponding to the task are acquired by acquiring the value of the label name item from the label information 101d.

At this time, it is determined whether or not a label indicating the version is included. For example, in the example of the task management information 101a shown in FIG. 4B, if the target task is a task with a record with the task ID = “5”, the character string “1, 3, 5” is used as the label ID list. Is obtained. This is divided by a comma (“,”) to obtain three label IDs “1”, “3”, and “5”. For these label IDs, in the label information 101d shown in the example of FIG. 7B, character strings (labels) of “v0100”, “defective”, and “WIP” can be obtained, respectively. Thereafter, whether or not each obtained label is a character string representing a version depends on whether or not it matches a predetermined regular expression (for example, “/ v [0-9] {4}”, etc.). If it matches, the character string representing the version is used.

In the present embodiment, as described above, when extracting version information from the problem correction problem information, the label ID list item of the problem management information 101a and the label ID item of the label information 101d are extracted. Correspondingly, it is acquired from the label name of the label information 101d, but is not limited to this. For example, when the problem information is managed not by the problem management information 101a but by a data configuration such as the defect information 101c in FIG. You may make it use the value of an item as it is.

Next, the branch processing unit 130 of the social coding system 100 determines whether there is a branch corresponding to the task (S04). As the processing in step S04, for example, when the problem identifier extracted in step S01 relates to a function development problem, the branch management of the repository management system 200 for the branch name generated based on the problem identifier is performed. The repository DB 201 is searched through the unit 220 to determine whether there is a target branch.

For example, in the example of the task management information 101a shown in FIG. 4B, if the target task is a task with a record with the task ID = “1”, “C001” is set as the task identifier from the title item in step S01. Since it is obtained, a branch name “feature / C001 / DEV” is generated in accordance with the naming rule of the function development branch shown in FIG. 3, and the presence or absence is confirmed on the repository DB 201.

If the problem identifier extracted in step S01 is related to a problem to be corrected, the repository management system 200 uses the branch name generated based on the problem identifier and the generated version acquired in step S03. The repository DB 201 is searched via the branch management unit 220 to determine whether there is a target branch.

For example, in the example of the task management information 101a shown in FIG. 4B, if the target task is a task with a record with the task ID = “5”, “B003” is set as the task identifier from the title item in step S01. can get. Further, in step S02, “v0100” is obtained as the generated version from the example of the label information 101d shown in FIG. 7B as the label name corresponding to the label ID = “1”. A branch name “fix / B003 / v0100 / DEV” is generated in accordance with the naming rule of the defect correction branch, and the existence of the branch name is confirmed on the repository DB 201.

If the branch corresponding to the issue is already in the repository in step S04, nothing is done (NOP: No OPeration) (S08), and the automatic branch generation process is terminated. On the other hand, if there is no branch corresponding to the task in step S04, next, a label indicating whether the status of the target task is working, that is, the task information of the target task is working. It is determined whether or not there is (S05).

In the acquisition of the label, the value of the item in the label ID list is acquired from the problem management information 101a for the target problem, and the corresponding label name is acquired from the label information 101d for each label ID included in the list. For each acquired label, it is determined whether or not there is a label indicating “WIP (Work In Progress)” indicating that work is in progress. For example, in the example of the task management information 101a shown in FIG. 4B, when the target task is a task with a record with the task ID = “5”, as described above, the task management information 101a displays the label ID. As shown in FIG. 7B, the label information 101d shown in the example of FIG. 7B can be used to obtain “v0100”, “defect”, and “WIP”, respectively. Can be obtained. Since the label of “WIP” indicating work is included in this, it is determined that the subject task is being worked.

If it is determined in step S05 that the task is not being worked on, nothing is done (NOP) (S08), and the automatic branch generation process is terminated. On the other hand, if the task is being worked on in step S05, the branch that is the branching source for generating this is specified based on the branch name generated in step S04 (S06). The branch that is the branching source can be specified based on, for example, information on the naming rules for each branch and the branching source branch shown in FIG. For example, if the branch name generated in step S05 is “fix / B003 / v0100 / DEV”, it can be seen from the naming convention of the table of FIG. It can be specified that the branch name of the branch source branch is “stable / v0100”.

Thereafter, a branch related to the branch name generated in step S04 is newly generated from the branch related to the branch name specified in step S06 via the branch management unit 220 of the repository management system 200 (S07). The automatic generation process is terminated.

By executing the above series of processing at the timing when the task is created, when the status of the task is modified, or periodically, for example, automatically when the status changes to “Working” You can also create a branch.

Even when the developer branch ("developer branch for function development" or "developer branch for defect correction") in step S3 in FIG. 15 is automatically generated, the basic processing is the processing content shown in FIG. It is the same. When generating a developer branch, in order to obtain further developer information, as an additional process, for example, before the process of step S01, the problem management unit 120 of the social coding system 100 accesses the problem DB 101 to perform problem management. A process of acquiring the value of the person in charge related to the subject problem in the information 101a is performed. If information on the person in charge cannot be acquired in this process, nothing is done (NOP) (S08), and the automatic branch generation process is terminated.

Further, when the branch name is generated in step S04, the rule that follows the branch naming rule shown in FIG. 3 is that of the developer branch. For example, in the example of the task management information 101a shown in FIG. 4B, when the target task is a task having a record with the task ID = “5”, “s-naka” is obtained from the item of the person in charge. In step S01, “B003” is obtained as the assignment identifier from the title item. In step S02, “v0100” is obtained as the generated version from the example of the label information 101d shown in FIG. 7B as the label name corresponding to the label ID = “1”. From these, when the branch name is generated in accordance with the branch naming rule shown in FIG. 3, the branch name “fix / B003 / v0100 / s-naka” is generated instead of “fix / B003 / v0100 / DEV”.

This allows the developer branch to be automatically generated while associating with the issue. Note that the developer branch may be generated together with the new generation of the management branch at the time of issue creation. If the person in charge is not set at this time, the person in charge will be set later. In addition, a developer branch may be automatically generated using the event as a trigger.

<2. Automatic addition of commit comments>
In this embodiment, as described above, after creating a developer branch, development such as source code creation / modification and testing is performed in step S4 of FIG. 15, and the completed one is registered as one commit. At this time, it is possible to automatically add information related to the association between the commit and the assignment (change vote or defect vote) to the commit comment. The process for automatically adding a commit comment will be described below.

When the developer performs development using the social coding client 410 on the user terminal 400 and executes commit, the commit processing unit 413 of the social coding client 410 is called, and commit comment addition processing is performed. FIG. 9 is a flowchart showing an outline of an example of the flow of the commit comment automatic adding process in the commit processing unit 413. First, a corresponding problem identifier is extracted from the branch name to be committed (S11).

According to the naming convention shown in FIG. 3, for example, in the “functional development branch” and “functional development developer branch” in function development, the branch name is “feature / CXXX / ˜”. If the second character string from the top of the character string obtained by dividing the branch name by “/” is obtained, the task identifier (in this case, “CXXX”) can be obtained. Similarly, the “branch branch for defect correction” and “developer branch for defect correction” in the defect correction both have the branch name “fix / BXXX / ˜”, so the characters obtained by dividing the branch name with “/” If the second from the top of the column is acquired, the task identifier (in this case, “BXXX”) can be obtained.

Next, the commit processing unit 413 accesses the problem management unit 120 of the social coding system 100 via the network 500, and issues information related to the problem identifier extracted in step S11 in the problem DB 101 via the problem management unit 120. Is determined whether or not is held (S12). Whether or not the task information related to the task identifier is held in the task DB 101 (the task is a management target by the task management unit 120), for example, the subject of the title item of the task management information 101a The determination can be made based on whether or not there is an identifier included. Instead of or in addition to the title item, determination may be made based on whether or not the subject detail identifier is included in the content detail item.

If the target issue is not held in the issue DB 101 in step S12, nothing is done (NOP) (S14), and the commit comment automatic addition process is terminated. On the other hand, when the target problem is held in the problem DB 101 in step S <b> 12, the commit processing unit 413 issues the problem ID item and the title item related to the target problem via the problem management unit 120 of the social coding system 100. Are added to the comment at the time of commit (S13), and the commit comment automatic adding process is terminated.

<3-1. Automatic branch specification at Pull request>
In this embodiment, as described above, when a Pull request is made in step S5 of FIG. 15, the branch to be merged (branch source) is determined based on the branch information, and the merge destination and merge source branch are determined. By automatically specifying and complementing the name, it is possible to automatically associate the Pull request with the branch and the assignment. In the following, a description will be given of the automatic branch designation process at the time of the Pull request.

FIG. 10 is a diagram showing an outline of an example of a repository display screen displayed by the social coding client 410 on the user terminal 400. When the developer completes development using the social coding client 410 on the user terminal 400 and makes a Pull request, the development product is included as a “branch name” in the repository display screen as shown in FIG. The developer branch to be merged is specified, and the “Pull request” button is pressed. Thereby, the Pull request creation unit 414 of the social coding client 410 is called. In the present embodiment, the pull request creation unit 414 calls the pull request processing unit 140 of the social coding system 100 via the network 500, and performs automatic designation processing of the branch at the merge destination (branch source).

FIG. 11 is a flowchart showing an outline of an example of a flow of automatic branch designation processing in the pull request processing unit 140. First, the branch name information of the branch currently displayed (designated) on the repository display screen shown in the example of FIG. 10, that is, the branch to be merged is acquired (S21). For example, the Pull request processing unit 140 of the social coding client 410 acquires from the repository display screen and is added as a parameter when the Pull request processing unit 140 of the social coding system 100 is called. Information can be acquired.

Next, the merge destination branch is specified from the merge source branch name acquired in step S21 (S22). In this embodiment, it is assumed that each branch is named according to a naming rule as shown in FIG. 3, and based on this, a branch name to be merged is specified. That is, it determines which branch in the naming rule shown in FIG. 3 corresponds to the branch name of the merge source, and generates the branch name of the merge destination based on the branch name naming rule of the corresponding branch source (merge destination) To do. For example, if the branch name of the merge source is “fix / B002 / v0100 / h-naka”, it is “branch for developer h-naka of defect B002” (the bottom row in the table of FIG. 3), so the branch As the branch name of the original branch, “fix / B002 / v0100 / DEV” can be obtained based on the naming rule.

Thereafter, the Pull request processing unit 140 generates a Pull request screen using the branch name acquired in Step S21 as the merge source branch and the branch name generated in Step S22 as the merge destination branch, and transmits the Pull request screen to the social coding client 410 of the user terminal 400. The screen is displayed (S23). FIG. 12 is a diagram showing an outline of an example of a pull request screen displayed by the social coding client 410 on the user terminal 400. As shown in the drawing, the screen can be displayed in a state where the repository name and branch name of the merge source and merge destination are automatically set and selected.

Note that when a “Pull request transmission” button is pressed on this Pull request screen, a Pull request creation unit 414 of the social coding client 410 creates a Pull request, which is transmitted to the Pull request processing unit 140 of the social coding system 100 and is sent to the Pull request screen. Processing related to the request is executed.

<3-2. Automatic addition of comments to Pull requests>
In the present embodiment, when making the above Pull request, a comment can be automatically added to the Pull request. As a result, a reader or the like who performs a review or the like on the Pull request can easily grasp information such as what problem the Pull request corresponds to.

Specifically, in the process of automatically specifying a branch at the time of a Pull request shown in FIG. 11 described above, for example, the Pull request processing unit 140 of the social coding system 100 in FIG. When the merge destination branch name is specified based on the naming rule shown in (1), a process for acquiring information on the assignment corresponding to the merge source branch name is also performed. For example, the task information is extracted from the merge source branch name based on the naming rule shown in FIG. 3 in the same manner as steps S11 and S12 of the process shown in FIG. It can be acquired by determining whether or not the task information related to is stored in the task DB 101.

When the information of the problem corresponding to the merge source branch is obtained from the problem DB 101, information such as the problem ID and title in the problem management information 101a is automatically added as a comment for the Pull request, and then the steps of FIG. In S23, a Pull request screen is generated. FIG. 13 is a diagram showing an outline of an example of a pull request screen displayed by the social coding client 410 on the user terminal 400. As shown in the figure, the screen can be displayed in a state in which the task ID and title information relating to the task corresponding to the merge-source branch (defect “B002” in the example of FIG. 13) is automatically set as a comment. .

As described above, according to the development support system 1 which is an embodiment of the present invention, the number of branches is suppressed as much as possible by automatically creating branches at a necessary timing, and the latest state possible. It is possible to start development work. Further, by automatically associating assignments, branches, commits, and Pull requests, it is possible to reduce the work load and improve the work efficiency in software development work.

Specifically, a branch corresponding to the subject is automatically created according to the naming rule when the issue is created, the status is changed, or the developer is assigned. Also, the branch source branch is automatically specified based on the created task information. This makes it possible to automatically create a branch at the timing of creating a problem and to automatically associate a problem with a branch.

Also, based on the information on the name of the branch to be committed, the identification information of the change slip or defect slip corresponding to the branch is determined from the branch naming rules, and the information is given to the commit comment. Thereby, the association between the commit and the issue (change vote or defect vote) can be automatically performed.

Also, based on the information of the branch name of the merge source, the branch that becomes the merge destination (branch source) is determined from the branch naming rules, and based on the information, the merge destination and the merge required when creating the Pull request are determined. Automatically specify and complete the original branch name. Further, information on the corresponding problem is acquired based on the information of the branch name of the merge source, and this is automatically added as a comment when creating the Pull request. As a result, the Pull request can be automatically associated with the branch and the assignment.

As mentioned above, the invention made by the present inventor has been specifically described based on the embodiments. However, the present invention is not limited to the above-described embodiments, and various modifications can be made without departing from the scope of the invention. Needless to say. For example, the above-described embodiment has been described in detail for easy understanding of the present invention, and is not necessarily limited to the one having all the configurations described. In addition, it is possible to add, delete, and replace other configurations for a part of the configuration of the above-described embodiment.

The present invention can be used in a development support system that supports program development using a social coding system.

1 ... Development support system,
DESCRIPTION OF SYMBOLS 100 ... Social coding system, 101 ... Assignment DB, 101a ... Assignment management information, 101b ... Development function information, 101c ... Defect information, 101d ... Label information, 110 ... User authentication part, 120 ... Assignment management part, 130 ... Branch processing part 140 ... Pull request processing unit,
200 ... Repository management system 201 ... Repository DB 210 ... Repository management unit 220 ... Branch management unit 230 ... Merge processing unit
300 ... assignment management system, 310 ... assignment management section,
400 ... User terminal, 401 ... Local repository DB, 410 ... Social coding client, 411 ... Repository processing unit, 412 ... Problem processing unit, 413 ... Commit processing unit, 414 ... Pull request creation unit,
500 ... Network.

Claims

A repository management system that maintains development artifacts and their change history in a repository;
A social coding system that associates and manages the development deliverables and issues, and a development support system comprising:
The social coding system
An issue management unit for managing information on the issue;
A branch processing unit for generating a branch in the repository,
The branch processing unit identifies a first branch that is a branch source based on the specified information of the problem, branches from the first branch, and generates a second branch corresponding to the problem Development support system.
The development support system according to claim 1,
The development support system, wherein the branch processing unit of the social coding system generates the second branch on condition that a state of the designated task is in a predetermined state.
The development support system according to claim 1,
The branch processing unit of the social coding system identifies the names of the first branch and the second branch from information on the designated task based on information on a branch and a branching source naming rule. Development support system.
In the development support system according to claim 3,
And a social coding client for registering the development product in the repository via the social coding system,
The social coding client includes a commit processing unit that performs a commit process for registering the development product in the second branch in the repository;
The commit processing unit obtains information for identifying the issue corresponding to the second branch based on the naming rule information from the name of the second branch, and the issue management unit of the social coding system The development support system according to claim 1, wherein when the issue is to be managed, information related to the issue is acquired via the issue management unit, and the acquired information is added to a comment when performing commit processing.
In the development support system according to claim 3,
And a social coding client for registering the development product in the repository via the social coding system,
The social coding system further accepts a Pull request for reflecting the second branch in which the development deliverable is registered in the repository to the first branch, and performs processing related to the Pull request. A request processing unit,
The Pull request processing unit of the social coding system acquires information on the second branch related to the Pull request designated from the social coding client, and converts the name of the second branch into information on the naming rule. Based on the above, the name of the first branch to be merged is specified, the screen for creating the Pull request with the merge source as the second branch and the merge destination as the first branch is the social coding Development support system that displays via client.
The development support system according to claim 5,
The Pull request processing unit of the social coding system acquires information on the second branch related to the Pull request designated from the social coding client, and converts the name of the second branch into information on the naming rule. Based on the information, the information specifying the problem corresponding to the second branch is acquired, and when the problem is a management target in the problem management unit of the social coding system, the information is determined via the problem management unit. A development support system for acquiring information related to the problem and displaying a screen for creating the Pull request in which the acquired information is added as a comment for the Pull request via the social coding client.