JP2017215762A - Build system for software and build method for software - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a software build system capable of preferentially developing high-priority software, and a software build method.SOLUTION: A software build system comprises: a source code management system; an automatic build system; a compile server group; a file server group; a development theme management system for a design manager of software to register a build priority for each development theme; and a fault management system for a person in charge of software test and a person in charge of market support to register priorities of measures corresponding to faults that occur in the software. The automatic build system requests the compile server group to build the software based on a source code that is committed by a designer, the build priority registered in the development theme management system and the measure priority registered in the fault management system.SELECTED DRAWING: Figure 3

Description

  The present invention relates to a software build system and a software build method.

  Software development, particularly large-scale software development, includes a component server device including a component database unit and a build server device that automatically builds software using software components sent from the component server device. (For example, refer to Patent Document 1).

  In this kind of software build system, in order to increase the speed of software development, a system administrator arranges multiple build server devices so that the throughput of each build server device is equalized, and multiple build server devices In general, the number of parallel execution jobs of each build server apparatus is set so that the throughput of the system approaches the target value as a whole.

  In this type of software build system, when a plurality of software is simultaneously developed, it is common to perform queue management so that the build is executed in parallel for the plurality of software.

  By the way, when developing a plurality of software at the same time, inevitably, development of software with high priority and development of software with low priority occur. For example, it is required to improve the priority of software malfunction countermeasures under development and software malfunction countermeasures that have occurred in the market and resolve the malfunctions promptly.

  However, a method of setting the number of parallel execution jobs of each build server device so that the throughput of the plurality of build server devices is equalized and the throughput of the plurality of build server devices approaches the target value as a whole, The method of performing queue management so that builds are executed in parallel for a plurality of software cannot increase the development speed of software with high priority.

  The present invention has been made to solve such problems of the prior art, and an object of the present invention is to provide a software build system and a software build method capable of preferentially developing software with high priority.

  In order to solve the above-described problems, an aspect of the present invention provides a source code management system that manages a source code committed by a software designer and its change history, and detects a change in the source code from the source code management system. Then, an automatic build system that requests software compilation to the compile server group, a file server group that stores the built artifacts created by the compile server group, and a software design supervisor who builds the build priority for each development theme A development theme management system for registering software, and a fault management system for registering fault information related to faults occurring in software by software testers and market support staff. The automatic build system is committed by the designer. The source code and the development theme Said build priorities registered in the management system, the based on the failure management the fault information registered in the system, and performs the build request software on the compilation server group.

  ADVANTAGE OF THE INVENTION According to this invention, the software build system and software build method which can preferentially develop high priority software can be provided.

It is a figure which shows the basic composition of the general software build system known conventionally. It is a figure which shows the basic composition of the software build system which concerns on embodiment. It is a figure which shows the detailed structure of the software build system which concerns on embodiment. It is a figure which shows an example of the source code change additional information which concerns on embodiment. It is a figure which shows an example of the model source code structure definition which concerns on embodiment. It is a figure which shows an example of the development theme management registration data which concerns on embodiment. It is a figure showing an example of failure management registration data concerning an embodiment. It is a flowchart which shows the procedure to the build request which the model group build control part which concerns on embodiment implements. It is a flowchart which shows the procedure of a process in case the countermeasure of a some source code is required for a countermeasure against a failure. It is a flowchart which shows the procedure of a process in case there exists the source code which requires the library which is the build result of the changed source code. It is a flowchart which shows the build procedure which the model group build job queue control part which concerns on embodiment implements.

  Prior to the description of the software build system according to the embodiment, a basic configuration of a conventionally known general software build system will be described with reference to FIG.

  As shown in FIG. 1, a conventionally known general software build system 100 includes a mail server, a source code management system, an automatic build system, a compile server group, and a file server group. ing.

  The mail server accepts a build result mail from the automatic build system. Designers D1, D2, and D3 can receive a build result mail addressed to themselves by accessing the mail server.

  The source code management system manages the source code committed by the designers D1, D2, and D3 and the change history.

  The automatic build system detects a change in the source code from the source code management system and makes a build request to the compile server group. In addition, the automatic build system saves the build product library and ROM image in the file server group, and requests the mail server 1 to notify the build result mail after the build product is saved in the file server group. Issue.

  The compile server group executes software build on the source code requested from the automatic build system.

  The file server group stores a library and a ROM image, which are build products, in response to a request from the automatic build system.

  In the conventional software build system configured as described above, software is built according to the procedure shown in FIG. That is, when the designers D1, D2, and D3 operate the client computer (PC) to commit the source code, the source code commit is registered in the source code management system (step S1).

  The automatic build system detects a change in the source code from the source code management system (step S2), and makes a build request to the compile server group (step S3). Next, the automatic build system receives the build product from the compile server group, and stores the received build product in the file server group in the form of a library or a ROM image (step S4). Further, the automatic build system issues a build result mail notification request to the mail server after the storage of the build product in the file server group is completed.

  The mail server receives the build result mail from the automatic build system based on the build result mail notification request issued from the automatic build system (step S5). Designers A, B, and C access the mail server and receive a build result mail addressed to them (step S6), and operate the client computer if necessary according to the contents of the received build result mail. Commit the source code again.

  Since the conventional software build system 100 is configured in this way, the software development by the designers D1, D2, and D3 is performed almost simultaneously in parallel, regardless of the priority of the software being developed.

  Next, the configuration of the software build system 200 according to the embodiment will be described with reference to FIGS. 2 and 3. FIG. 2 is a diagram showing a basic configuration of the software build system 200 according to the embodiment. As is clear from this figure, the software build system 200 according to the embodiment is the general software build system shown in FIG. The development theme management system and the failure management system are added to 100.

  FIG. 3 is a diagram illustrating a more practical configuration of the software build system 200 according to the embodiment. As is apparent from this figure, the software build system 200 of this example is provided with an A model group source code management server and a B model group source code management server in the source code management system. The A model group source code management server and the B model group source code management server are management servers for managing source code in units of similar models, and store the source code and source code change additional information described later in association with each other. Depending on the number of models of software to be developed, three or more model group source code management servers are provided.

  The A model group source code management server manages the source code and change history committed by the designers D1, D2, and D3 by operating the PC, and the B model group source code management server includes the designers D4, D5, D6 manages the source code and change history committed by operating the PC. That is, the software build system 200 of FIG. 3 is designed so that the designers D1, D2, and D3 can jointly develop A type software, and the designers D4, D5, and D6 can jointly develop B type software. It has become.

  The client software of the PC operated by the designers D1, D2, D3, D4, D5, and D6 has software for committing the source code to the model group source code management server. Each PC also has a user interface capable of inputting the source code change additional information 60 shown in FIG.

  The source code change additional information is information added when the designers D1, D2, D3, D4, D5, and D6 commit the source code. Designers D1, D2, D3, D4, D5, and D6 identify whether or not the source code change content is a countermeasure against the failure according to the form shown in FIG. If countermeasures are completed by the presence or absence of a combination change with source code and the commit of multiple source codes, the countermeasure source code is described.

  The A model group source code management server is provided with an A model group source code change monitoring unit, and the B model group source code management server is provided with a B model group source code change monitoring unit.

  The A model group source code change monitoring unit monitors the commit of the source code by the designers D1, D2, and D3 to the A model group source code management server, and if the source code commit is detected, the source is sent to the automatic build system. Notify code changes. In addition, the B model group source code change monitoring unit monitors the commit of the source code by the designers D4, D5, and D6 to the B model group source code management server. Inform source code change notification. The source code change notification includes a change in the source code and the changed source code.

  Further, as shown in FIG. 3, the software build system 200 according to the embodiment includes an A model group automatic build system and a B model group automatic build system as automatic build systems. The A model group automatic build system starts a build operation when it receives a source code change notification from the A model group source code change monitoring unit. The B model group automatic build system starts a build operation when receiving a source code change notification from the B model group source code change monitoring unit.

  As shown in FIG. 3, the A model group automatic build system includes an A model group designer definition section, an A model group ROM creation schedule definition, an A model group build control section, a model W source code configuration definition, and a model W source. Includes code build order definition, model W build control workspace, model W build queue, model X source code configuration definition, model X source code build order definition, model X build control workspace, model X build queue Composed.

  On the other hand, as shown in FIG. 3, the B model group automatic build system has a B model group designer definition part, a B model group ROM creation schedule definition, a B model group build control part, a model Y source code configuration definition, and a model. Y source code build order definition, model Y build control workspace, model Y build queue, model Z source code configuration definition, model Z source code build order definition, model Z build control workspace, model Z build queue Consists of including.

  The design person definition section of each model group provided in the A model group automatic build system and the B model group automatic build system is a mail notification destination of the build result and corresponds to the source code.

  Similarly, the ROM creation start time is set in the ROM creation schedule definition of each model group provided in the A model group automatic build system and the B model group automatic build system. Normally, ROM creation builds the entire source code.

  The model group build control unit has a role of starting a build operation in response to a source code change notification from the source code management system. Also, the model group ROM creation schedule definition is referenced, and when the set time comes, the build operation is started according to the model source code build order definition.

  The model source code configuration definition is a list of source codes constituting the model. An example of the source code configuration definition is shown in FIG. The source code configuration definition illustrated in FIG. 5 includes source code, deliverables, and library use source code. When the source code is built, is a library for other source code generated? In the case of library generation, the source code to be used is registered.

  The model source code build order definition defines the build order of the entire source code used when creating the ROM.

  The model build control workspace is a temporary storage place for build logs and build results.

  The model build wait queue is a queue that stores the order in which build requests are issued to the compile server.

  Furthermore, as shown in FIG. 3, the software build system 200 according to the embodiment includes a compile server group including a compile server for the A model group and a compile server for the B model group. The compile server for the A model group executes software build on the source code requested from the automatic build system for the A model group. The B model group compile server executes a software build on the source code requested from the B model group automatic build system.

  The A model group compile server includes an A model group build job queue control unit, an A model group build job queue, a server (1), and a server (2). The B model group compile server includes a B model group build job queue control unit, a B model group build job queue, a server (3), and a server (4).

  The A model group build job queue control section of the A model group compile server refers to the build waiting queues for model W and model X of the automatic build system for A model group, and requests build to the A model group build job queue. Write. In addition, the B model group build job queue controller of the B model group compilation server refers to the build queues for model Y and model Z of the B model group automatic build system, and enters the B model group build job queue. Write a build request.

  Each build job queue provided in the compile server for the A model group and the compile server for the B model group is a queue for receiving a build request and waiting for an empty job. Servers (1) to (4) are virtual servers for executing a build, and a job is an instance of a build process.

  In addition, as shown in FIG. 3, the software build system 200 according to the embodiment includes a library storage server and a ROM image storage server as a file server group.

  The library storage server includes a model W library and a model X library generated by the A model group automatic build system, and a model Y library and a model Z library generated by the B model group automatic build system. Saved.

  On the other hand, the ROM image storage server includes a model W ROM image and a model X ROM image generated by the A model group automatic build system, a model Y ROM image generated by the B model group automatic build system, and The model Z ROM image is stored.

  Returning to FIG. 2, the development theme management system and the failure management system provided in the software build system 200 according to the embodiment will be described.

  The development theme management system has development theme management registration data illustrated in FIG. 6, and manages the development schedule and build priority for each development theme. The development theme management registration data is information registered by the design supervisor M.

  The development theme management registration data illustrated in FIG. 6 includes a development theme name, a mass production time, and a build priority. The model W has a mass production date of January 1, 2017, the model X has a mass production date of March 1, 2017, the model Y has a mass production date of February 1, 2017, and the model Z has a mass production date of June 1, 2017. Day. In this example, build priorities are defined in the order of early mass production.

  The fault management system has fault management registration data illustrated in FIG. 7, and manages faults occurring during software development and fault contents in the market. This failure management registration data is information registered by the tester T and the market supporter S.

  The failure management registration data illustrated in FIG. 7 includes a failure management number, a failure content, an occurrence classification, an occurrence model, a countermeasure priority, a status, a person in charge name, a person in charge of a test person T It consists of the email address of the market support person S.

  The failure management number can be a serial number, for example. In the occurrence category, a category of whether the failure occurred in the market or the failure occurred during software development is registered. In the countermeasure priority, categories of “high”, “medium”, and “low” are registered. In general, the priority of countermeasures is assigned to a higher countermeasure priority with respect to failures occurring in the market. For failures that occur during software development, countermeasure priority is assigned in consideration of the mass production time.

  The software build system 200 according to the embodiment performs software build according to the procedure shown in FIG. First, the design supervisor M registers the build priority (see FIG. 6) for each development theme in the development theme management system before starting the software build (step S0).

  Further, when a failure occurs in the software under development, the tester T registers failure information (see FIG. 7) in the failure management system, and the market supporter S detects a failure in the software provided in the market. When this occurs, failure information (see FIG. 7) is registered in the failure management system (step S11).

  When committing the source code, the designers D1, D2, and D3 refer to the failure management number (see FIG. 7) registered in the failure management system (step S12). When the failure handling registered in the failure management system is performed, the designers D1, D2, and D3 add the failure management number and commit the source code to the source code management system (step S13).

  The automatic build system detects a change in the source code from the source code management system (step S14). Further, the automatic build system refers to the failure management number added to the failure management registration data, and confirms the countermeasure priority corresponding thereto (step S15). Furthermore, if the source code of the automatic build system 3 is set to the countermeasure priority “high”, the automatic build system 3 performs the queue operation so that the build is performed before the failure build with the countermeasure priority “low”, and the compilation is performed. A build request is sent to the server group 4 (step S16).

  After confirming the build priority registered in the development theme management system (step S17), the compile server group executes the build on the source code requested from the automatic build system (step S18). At this time, the compile server group refers to the registered contents of the development theme management system, and if the source code is a theme that is set to build priority "high", it will be more than the one for the theme with build priority "low". Queue operation to build first.

  If the build is a countermeasure against a failure, the automatic build system issues a status change request (see FIG. 7) to the failure management system after the build is completed (step S19). In addition, after the status change request, the automatic build system issues a build result mail notification request to the mail server and the failure management system (step S20).

  Thereafter, the file server group stores a library or ROM image that is a build product in response to a request from the automatic build system (step S21). In addition, the mail server notifies the build results to the designers D1, D2, D3, the tester T, and the market supporter S by mail (step S22).

  Next, when the model group build control unit receives a source code change notification from the model group source code change monitoring unit, the model group build control unit to start building the source code triggered by the change notification The procedure up to the build request executed by (see FIG. 3) will be described with reference to FIG.

  When the model group build control unit receives the source code change notification from the model group source code change monitoring unit (step S31), the model group build control unit sets the failure management number of the source code change additional information (FIG. 4). As a key, countermeasure priority is identified from the failure management registration data (FIG. 7) (step S32). Next, the model group build control unit uses the target source code of the model group source code configuration definition (FIG. 5) as a key to determine the model including the source code (step S33). Thereafter, the model group build control unit queues the model-specific build waiting queue prepared for each model (step S34).

  Thus, when the model group build control unit receives the source code change notification from the model group source code change monitoring unit, the model group build control unit can start building the source code using the change notification as a trigger.

  Next, a procedure in the case where countermeasures for a plurality of source codes are necessary for countermeasures against failures will be described with reference to FIG. In the example of FIG. 9, a case where measures against two source codes are required will be described, but the same applies to a case where measures against three or more source codes are required.

  When the model group build control unit receives the source code change notification from the model group source code change monitoring unit (step S41), the model group build control unit refers to the target source code in the source code change additional information and stores it in the build control workspace. An inquiry is made as to whether there is a failure management number waiting for this (step S42).

  If there is a failure management number that is waiting, the model group build control unit stores the source code names and failure countermeasure management numbers of the two waiting source codes in the model build control workspace (step S43). At this time, the flag indicating that the build request stored for each source code has been issued is turned ON. An identification ID is added to the saved contents.

  Thereafter, the request is queued together with the identification ID in the model-specific build queue (step S44).

  Next, the model group build control unit waits for reception of a change notification from the model group source code change monitoring unit (step S45), and the source code name and trouble countermeasure management number stored in the model build control workspace are stored. It is determined whether they match (step S46).

  If the source code name saved in the model build control workspace matches the failure management number, a build request stored for each source code is issued at the same time that the request is queued to the build queue for each model. Is turned ON (step S47).

  Next, when the model group build control unit receives the completion of the build from the model group build job queue control unit (step S48), in the case of failure countermeasures, the presence / absence of the identification ID is determined, and the identification ID exists. In step S49, the build completion flag that matches the identification ID and the source code name is set to ON. Then, the model group build control unit recognizes that the trouble countermeasure is completed when all the build completion flags in the identification ID are turned ON.

  As a result, it is possible to build a source code when a plurality of source codes need to be taken as countermeasures against failures.

  Next, a procedure when there is a source code that requires a library as a build result of the changed source code will be described with reference to FIG.

  When the model group build control unit receives the completion of the build from the model group build job queue control unit (step S51), the model group build control unit refers to the library use source code in the model source code configuration definition (step S52). If there is a source code, the build request for the source code is queued to the request in the model-specific build queue.

  As a result, the source code can be built when there is source code that requires the library that is the build result of the changed source code.

  Next, a build procedure performed by the model group build job queue control unit will be described with reference to FIG.

  The model group build job queue control unit sequentially polls a plurality of model build queues to identify a build request (step S61). Next, the model group build job queue control unit identifies a model from the model build queue for which a build request has been made (step S62). Furthermore, the model group build job queue control unit refers to the development theme management registration data, and identifies whether or not each of the identified plurality of models is a model under development (step S63).

  If the model is under development, the model group build job queue control unit identifies the build priority, and if the build priority is determined to be marketable, the priority is determined to be the highest priority. The model group build job queue control unit rearranges the queues in order of priority when a build request is input to the model group build job queue.

  Reading from the queue is also performed at the same time, and if there is an empty job, the build job is immediately executed (step S64). If there is no space in the job, the priority of the job being executed is compared with the priority of the build read from the queue, and if the build priority read from the queue is high, the job being executed is cancelled. Then, the queue operation is performed so as to place it at the head of the build request having the same priority stored in the queue (step S65).

  As a result, the source code can be built in order of priority.

JP 2003-005977 A

Claims (6)

A source code management system that manages the source code committed by the software designer and its change history;
An automatic build system that detects a change in source code from the source code management system and requests a compile server to build software;
A file server group for storing build products produced by the compile server group;
A development theme management system in which the software design supervisor registers build priorities for each development theme;
A failure management system in which software testers and market support personnel register the priority of countermeasures according to failures that occur in the software,
The automatic build system is based on the source code committed by the designer, the build priority registered in the development theme management system, and the countermeasure priority registered in the failure management system. A software build system characterized in that a software build request is sent to a compile server group.   The automatic build system, when receiving a change notification of the source code from the source code management system, makes a build request for software to the compile server group using the change notification as a trigger. The described software build system.   3. The automatic build system, when there are a plurality of failures that have occurred in the software, requests the compile server group to build the software for a plurality of source codes related to the failure. The software build system according to any one of the above.   When there is a source code that requires a library that is a build result of the modified source code, the automatic build system refers to the library use source code in the source code configuration definition stored in the automatic build system, and The software build system according to any one of claims 1 to 3, wherein a software build request is made to a compile server group.   5. The software build system according to claim 1, wherein the compile server group rearranges the build job queue in the order of the build priority and the countermeasure priority. A source code management system that manages the source code committed by the software designer and its change history;
An automatic build system that detects a change in source code from the source code management system and requests a compile server to build software;
A file server group for storing built artifacts created by the compile server group;
A development theme management system in which the software design supervisor registers build priorities for each development theme;
Using a software build system equipped with a fault management system in which software testers and market support staff register fault information about faults that occurred in the software,
The automatic build system performs the compilation based on the source code committed by the designer, the build priority registered in the development theme management system, and the failure information registered in the failure management system. A software building method, wherein a software build request is sent to a server group.