JP2009244974A - Program development management device - Google Patents

Abstract

[PROBLEMS] In program development, it often happens that some of the programs to be released are forgotten to be released at the time of program release, or the programs to be released and the programs not to be released are mistakenly released. is doing. Such mistakes usually cause serious system failure.
In a program development management apparatus, a theme-specific program table manages a program to be developed and a release condition for each development theme. The directory generation unit 130 refers to the theme-specific program table 10, extracts programs having the same release condition as one release unit, generates a release unit directory in the release storage area 170, and extracts the extracted release unit program. Store in the directory. This makes it possible to manage programs according to release conditions.
[Selection] Figure 2

Description

  The present invention relates to an apparatus for managing program development.

A version management system is generally used to manage development and update of programs that construct business systems and the like. In this system, the administrator can manage, for example, the update history of the development target program for each development theme. Further, in this system, the developer updates the program, and the person in charge of the operation releases the updated program.
JP 2008-003985 A

  Normally, when a program that has been updated is released, it is rarely released for each development theme. This is because there are very many release conditions such as delivery dates and release destination servers among programs belonging to a certain development theme.

  Therefore, the person in charge of operation manually collected the programs to be released at the time of release based on the materials of the release meeting. For this reason, a “release omission” in which some of the programs to be released are forgotten to be released, or a “release error” in which a program to be released is mistakenly released with a program that is not to be released frequently occur. Such mistakes usually cause serious system failure.

  Furthermore, when a mistake that releases a program that has not been updated has occurred, it is very cumbersome to determine whether it is a mistake on the operation side or a mistake on the development side.

  The present invention has been made in view of these problems, and an object thereof is to provide a program development management apparatus for smoothly releasing a program.

  In order to solve the above problems, a program development management device according to an aspect of the present invention refers to a theme-specific program table for managing a program to be developed and a release condition for each development theme, and a theme-specific program table. A directory generation unit that extracts a program having the same release condition as one release unit, generates a release unit directory, and stores the extracted release unit program in the directory.

  According to this aspect, the program managed for each theme is stored and managed in the directory for each release condition. The person in charge of the operation can release each directory, and the release omission of the program at the time of release or a release error can be greatly reduced.

  It should be noted that any combination of the above-described constituent elements, or those obtained by replacing the constituent elements and expressions of the present invention with each other between apparatuses, methods, systems, computer programs, recording media storing computer programs, and the like are also included in the present invention. It is effective as an embodiment of

  According to the program development management device of the present invention, the program can be released accurately.

  The present invention will be described below based on preferred embodiments with reference to the drawings. The same or equivalent components, members, and processes shown in the drawings are denoted by the same reference numerals, and repeated descriptions are omitted as appropriate. The embodiments do not limit the invention but are exemplifications, and all features and combinations thereof described in the embodiments are not necessarily essential to the invention.

  The embodiment of the present invention provides a program development management apparatus that stores a program managed in units of development themes in a program development process in a release unit directory after the update and releases the program for each directory. As a result, it is possible to greatly reduce program release omissions and release mistakes at the time of release.

  FIG. 1 is a system configuration diagram showing a program development system 1000 including a program development management apparatus 100 according to an embodiment. The program development system 1000 includes a program development management apparatus 100, development terminals 200a,..., 200b, a development leader terminal 300, an operation staff terminal 400, and customer servers 600a,. The program development management device 100 includes a development update unit 110, a release approval unit 120, a directory generation unit 130, a release execution unit 140, and a storage device 150.

  The program development management apparatus 100 is connected to the development terminals 200a,..., 200b, the development leader terminal 300, and the operation staff terminal 400 via an intranet, the Internet, or the like. Here, the program development management apparatus 100 may be a server and the rest may be connected by a client / server system. The program development management apparatus 100 is connected to customer servers 600a,..., 600b via the Internet or the like.

  FIG. 2 is a block diagram showing functions and configuration of the program development management apparatus 100 according to the embodiment. Each block shown here can be realized in hardware by an element such as a CPU of a computer or a mechanical device, and in software it is realized by a computer program or the like. Draw functional blocks. Therefore, those skilled in the art will understand that these functional blocks can be realized in various forms by a combination of hardware and software.

  The storage device 150 includes a theme storage area 160 and a release storage area 170. The theme storage area 160 stores a theme-specific program table 10 and a program to be developed. The release storage area 170 stores a program table 20 by release and a program to be released.

  The development update unit 110 serves as an interface with the development side through the development leader terminal 300 and the development terminals 200a,..., 200b, and manages the development target program in the theme storage area 160.

  The release approval unit 120 receives the release approval in units of release, extracts the program ID of the release unit from the theme-specific program table 10 and registers it in the program table 20 by release.

  The directory generation unit 130 creates a release unit directory in the release storage area 170 based on the information in the release-specific program table 20, and stores the program therein.

  When the release execution unit 140 receives a release command for a release unit, the release execution unit 140 locks the directory of the release unit until the release condition of the release unit is satisfied. Such a directory lock may be realized, for example, by making the directory unclickable, or may be realized by requesting input of a predetermined password to open the directory. When the release condition is satisfied, the program is automatically copied to the customer server for each release unit directory. Hereinafter, the configuration of FIG. 2 will be described in more detail with specific examples.

Development update unit 110:
The development update unit 110 receives a development theme from the development leader terminal 300, creates a directory for each development theme in the theme storage area 160, and stores therein a program targeted for development by the development theme. Thereafter, the development update unit 110 registers the contents of the development theme in the theme-specific program table 10.

  In the present embodiment, the development update unit 110 first creates a directory named “theme01” in the theme storage area 160. Then, a directory named “JAVA (registered trademark)” is stored in the directory, a directory named “class” is stored in the directory named “JAVA”, and “directory” is stored in each directory named “class”. Stores programs named “abc.class”, “ghi.class”, “uvw.class”, and “xyz.class”. Hereinafter, “/ theme01 / JAVA / class /” is abbreviated as “(theme) /”.

  FIG. 3 is a data structure diagram of the theme-specific program table 10 and the release-specific program table 20 of FIG. The theme-specific program table 10 associates a development theme ID given for each development theme, a program ID given for each program and uniquely identifying the program, a release condition, and an update completion flag, and provides a development theme ID. Remember separately. In the present embodiment, the program path is adopted as the program ID, and the delivery date of the program is adopted as the release condition.

  The release-by-release program table 20 stores release IDs and program IDs in association with each other by release ID. Here, the release ID is an ID given to each release unit when programs having the same delivery date are regarded as one release unit.

  In the present embodiment, as seen in the theme-specific program table 10 shown in FIG. 3, the development theme ID “Theme01” has a program ID “(theme) /abc.class” and a program ID “(theme) / ghi. class ”, the program ID“ (theme) /uvw.class ”, and the program ID“ (theme) /xyz.class ”are associated with each other.

  January 15 is registered as the delivery date of the program corresponding to the program ID “(theme) /abc.class” and the program ID “(theme) /xyz.class”, and the program ID “(theme) /ghi.class” and February 15 is registered as the delivery date of the program corresponding to the program ID “(theme) /uvw.class”.

  In the present embodiment, as seen in the release-specific program table 20 shown in FIG. 3, the release ID “release0115” has the program ID “(theme) /abc.class” and the program ID “(theme) /xyz.class”. Is associated by the release approval unit 120 described later. 3 is an arrow indicating which program ID in the theme-specific program table 10 is associated with the release ID in the program table 20 by release by the release approval unit 120.

  Returning to FIG. 2, the description of the development update unit 110 will be continued. Next, the development update unit 110 receives program updates from the development terminals 200a,. This update acceptance may be, for example, in the following manner. The development update unit 110 provides a working storage area in the storage device, and copies the development target program from the theme storage area 160 to the working storage area. The development terminals 200a,..., 200b are caused to update the program in the working storage area. The program notified of the completion of the update is overwritten from the work storage area to the theme storage area 160 and an update completion flag is set for the program in the theme-specific program table 10. The development update unit 110 may accept program updates in the above manner.

  The development update unit 110 may further display the development status of the program on the development leader terminal 300 in response to a request from the development leader terminal 300. For example, the development update unit 110 refers to the theme-specific program table 10 and associates the word “update complete” with the program for which the update completion flag is set, and the word “update incomplete” for the program that is not. It may be executed by displaying the associated program list.

Release approval unit 120:
The release approval unit 120 displays a release approval screen 80 on the development leader terminal 300 in response to a request from the development leader terminal 300.
FIG. 4 is a screen view of the release approval screen 80. The release approval screen 80 includes a delivery date column 74, a release ID column 76, and an approval button column 78. The delivery date column 74 displays the delivery date, the release ID column 76 has a space for inputting the release ID of the release unit corresponding to the delivery date, and the approval button column 78 can be pushed down regarding the release unit release approval. Approval buttons that cannot be pushed down or approval buttons that cannot be pushed down are displayed. Here, the approval button that cannot be pushed down is a button that does not accept a click by the user.

  After receiving a request from the development leader terminal 300, the release approval unit 120 refers to the theme-specific program table 10 and searches for a program update completion flag before displaying the release approval screen 80. As a result, if at least one of the programs in the release unit does not have a flag indicating that the update has been completed, an approval button that cannot be pushed down is displayed in the approval button column 78 corresponding to the release unit, and can be pushed down otherwise. Display an approval button.

  In the present embodiment, it is assumed that the update status is as shown in FIG. 3 when the development leader terminal 300 requests the display of the release approval screen 80. That is, the program ID “(theme) /abc.class”, the program ID “(theme) /ghi.class”, and the program ID “(theme) /xyz.class” are flagged for updating, but the program ID “(theme) /abc.class” (Theme) /uvw.class "does not have an update completion flag.

  Therefore, the release approval unit 120 displays the approval button 70 that can be pushed down in the approval button column 78 corresponding to the release unit for the delivery date on January 15 on the release approval screen 80, and corresponds to the release unit for the delivery date on February 15. An approval button 72 that cannot be pushed down is displayed in the approval button column 78. In order to approve the release of the program for the delivery date of January 15, the development leader inputs “release 0115”, which is the release ID, in the input space of the release ID column 76, and clicks the approval button 70 that can be pushed down.

  Returning to FIG. Then, the release approval unit 120 refers to the theme-specific program table 10 and reads the approved program ID for the January 15 delivery date. The program ID “(theme) /abc.class”, the program ID “(theme) /xyz.class”, and the release ID “release0115”, which are the program IDs, are registered in the program table 20 by release. Thereafter, the release ID “release0115” is transmitted to the directory generation unit 130.

Directory generation unit 130:
The directory generation unit 130 receives the release ID “release0115” transmitted by the release approval unit 120. First, the directory generation unit 130 creates a directory named “release0115” in a directory named “RELEASE” in the release storage area 170. Next, referring to the program table 20 by release, the program ID “(theme) /abc.class” and the program ID “(theme) /xyz.class”, which are the program IDs associated with the release ID “release0115”, are obtained. . Thereafter, the program “abc.class” and the program “xyz.class” in the theme storage area 160 specified by the program ID are read and stored in the directory named “release0115”.

Release execution unit 140:
The release execution unit 140 searches the release storage area 170 in response to a request from the operation staff terminal 400 and causes the operation staff terminal 400 to display a list of release IDs provided with a directory. Thereafter, a release execution command for the release ID “release0115” is received from the operation terminal 400. Then, the release execution unit 140 does not allow the directory named “release0115” to be clicked until January 15, which is the delivery date of the release unit corresponding to the release ID “release0115”. When the delivery date is January 15th, the release execution unit 140 takes out all the programs stored in the directory named “release0115” and copies them to the release destination customer servers 600a to 600b. This completes the series of processing for program development.

Hereinafter, the flow of processing in the program development management apparatus 100 will be described with reference to flowcharts.
FIG. 5 is a flowchart showing a series of processing in program development management. The development leader transmits a development theme from the development leader terminal 300 to the program development management apparatus 100 (S900). The program targeted for development according to the development theme is copied to the theme storage area 160 (S902). The development theme ID, program ID, and delivery date are registered in the theme-specific program table 10 (S904). The program update from the developer is accepted (S906).

  The development leader transmits a release approval request from the development leader terminal 300 to the release approval unit 120 (S908). The release approval unit 120 refers to the theme-specific program table 10 and reads an update completion flag for each delivery date (S910). If all the programs corresponding to the delivery date have not been updated (N in S912), an approval button that cannot be pushed down is displayed in the approval button column 78 corresponding to the delivery date on the release approval screen 80 (S916), and it is developed. The reader confirms, and the process returns to S906. When all the programs corresponding to the delivery date have been updated (Y in S912), an approval button that can be pushed down is displayed in the approval button column 78 corresponding to the delivery date on the release approval screen 80 (S914). By clicking the button, release corresponding to the release unit corresponding to the delivery date is approved (S918).

  The release approval unit 120 refers to the theme-specific program table 10, obtains an approved release-unit program ID, and registers it in the release-specific program table 20 in association with the release ID assigned to the release unit (S920). ). The release approval unit 120 transmits the release ID to the directory generation unit 130 (S922). The directory generation unit 130 receives the release ID, and creates a directory corresponding to the release ID in the release storage area 170 (S924). The directory generation unit 130 refers to the program table 20 by release (S926), and copies the program corresponding to the program ID associated with the release ID from the theme storage area 160 to the directory corresponding to the release ID (S928).

  The person in charge of operation receives a release ID corresponding to the delivery date from the development leader in advance. When the delivery date arrives, the operation staff transmits the release ID from the operation terminal 400 to the release execution section 140, and the release execution section 140 releases the programs stored in the directory corresponding to the release ID in a batch (S930). ).

  According to the program development management apparatus 100 according to the present embodiment, a program managed for each development theme is stored and managed in a directory for each delivery date after being updated, and released for each directory. . Therefore, it is possible to greatly reduce the program release omission and release mistake at the time of release. In addition, the speed of collecting programs to be released is improved.

  Further, after receiving the release execution command, the release execution unit 140 makes the directory unclickable until the delivery date of the release unit that has received the execution command. Therefore, it is possible to prevent mistakes that the person in charge of operation accidentally releases before the delivery date. Furthermore, it is possible to prevent the program in the release unit directory from being destroyed due to an operation error or the like. In addition, when the delivery date is reached, the program is released in units of release without human intervention, so the delivery date can be more reliably protected.

  Further, a directory corresponding to only a release unit for which release approval is accepted by the release approval unit 120 is created in the release storage area 170. Therefore, even if a program that has not been completely updated is released, it is clear that the responsibility lies with the development side, not the operation side. In other words, an audit trail is realized.

  In addition, the release button cannot be pushed down for a release unit including a program that does not have an update completion flag on the release approval screen 80. Therefore, it is possible to prevent a program without an update completion flag from being released due to a mistake of the development leader.

  FIG. 6 is a data structure diagram of the theme-specific program table 16 and the release-specific program table 24 according to a modification of the release condition. The release condition may be determined according to a situation such as a request of a customer who requests development. For example, when the customer wants to update the program released to the server A as soon as possible, the release condition is set to the server as shown in the theme-specific program table 16 of FIG. Then, the development leader can confirm the update status on the release approval screen, and satisfy the customer's request by executing the release to the server A as soon as the program released to the server A is updated. According to this modification, it is possible to realize the flexible response to customers as described above.

  FIG. 7 is a screen diagram of a warning screen 82 according to a first modification of the release approval unit 120. In this modification, the release approval unit 120 displays a release approval screen on the development leader terminal 300 without referring to the theme-specific program table 10 in response to a request from the development leader terminal 300. In this release approval screen, an approval button that can be pushed down for all delivery dates is displayed. That is, in this modification, on the release approval screen 80 shown in FIG. 4, an approval button 70 that can be pushed down is displayed instead of the approval button 72 that cannot be pushed down for the delivery date of February 15.

  When a push-down approval button corresponding to the February 15 delivery date is clicked, the release approval unit 120 refers to the theme-specific program table 10. As a result, it is recognized that there is a program for which the update completion flag is not set among the programs for the delivery date of February 15, and the warning screen 82 shown in FIG. Thereafter, the release approval unit 120 performs processing for invalidating the click of the approval button corresponding to the February 15 delivery date, and closes the release approval screen.

  According to this modification, it is possible to notify the development leader of the program having a certain delivery date through the warning screen that the update has not been completed. In addition, it is possible to prevent a program that has not been updated due to a mistake of the development leader from being released.

  FIG. 8 is a screen diagram of a caution screen 84 according to a second modification of the release approval unit 120. FIG. 9 is a data structure diagram of the theme-specific program tables 12 and 14 and the release-specific program table 22 according to the second modification of the release approval unit 120. In this modification, a predetermined period, for example, one month, is registered in the program development management apparatus 100 by the development leader. For example, an item “extension period” and a corresponding input space are provided on the release approval screen displayed on the development leader terminal 300 by the release approval unit 120, and the value input thereto is converted into an appropriate file in the theme storage area 160. It may be realized by saving.

  In this modification, the release approval unit 120 accepts registration of an approval date for each delivery date. This may be realized, for example, by further providing an approval date column on the release approval screen and providing a space for inputting an approval date for each delivery date in the column.

  In this modified example, as seen in the theme-specific program table 12 shown in FIG. 8, the development theme ID “Theme01” has the program ID “(theme) /abc.class” and the program ID “(theme) /ghi.class”. Are associated with the program ID “(theme) /uvw.class” and the program ID “(theme) /xyz.class”. January 15 is registered as the delivery date for all programs.

  In this modified example, when the approval date inputted for the delivery date of January 15 comes, the release approval screen is displayed on the development leader terminal 300. On the release approval screen, an approval button that can be pushed down for the delivery date of January 15 is displayed. When the button is clicked, the release approval unit 120 refers to the theme-specific program table 12. As a result, it is recognized that there is a program ID without an update completion flag among the program IDs for the delivery date of January 15th. In this modification, it is recognized that the update completion flag corresponding to the program ID “(theme) /ghi.class” is not set.

  Then, as shown in FIG. 9, the release approval unit 120 extends the delivery date of the program corresponding to the program ID to the predetermined program period, for example, one month, and re-registers it in the theme-specific program table 14. Thereafter, the program IDs and release IDs of programs for the remaining delivery date on January 15 are associated with each other and registered in the program table 22 by release.

  According to this modification, it is possible to prevent the release of a program that has not been updated, and to prevent a program whose development was not in time for delivery from being released from the release target.

FIG. 10 is a directory configuration diagram according to a modified example of the program development management apparatus 100. In this modification, a path having the path “/java/src/class/abc.class” is compiled by compiling a program having a path “/java/src/abc.java” (hereinafter simply referred to as “abc.java”). (Hereinafter referred to simply as “abc.class”) is generated (R2). A program having a path “/java/class/def.class” (hereinafter referred to as “/java/class/def.java”) is compiled by compiling a program having a path “/java/src/def.java” (hereinafter simply referred to as “def.java”). (Denoted simply as “def.class”) is generated (R4). Also, by compiling a program having a path of “/java/src/lib/ghi_lib.java” (hereinafter simply referred to as “ghi_lib.java”), it is called “/java/src/class/lib/ghi_lib.class”. A program having a path (hereinafter simply referred to as “ghi_lib.class”) is generated (R6). “Abc.class” refers to “ghi_lib.class” (R8). “Abc.class” refers to “def.class” (R10).
“Ghi_lib.class” is a program (library) shared by a plurality of programs, and is also referred to by many other programs other than “abc.class”.

  FIG. 11 is a data structure diagram showing a program ID-specific table 60 according to the modification of FIG. In this modification, the program development management device 100 further includes a program ID table 60 in the storage device 150. The program ID-specific table 60 stores a plurality of program paths that are related to each other in association with program IDs that uniquely specify the relationship. In addition, this program path may include other program IDs. In that case, a so-called parent-child relationship can be established between the program IDs with the original program ID as the parent and the program ID associated with the parent program ID as the child program ID.

  In this modification, when registering “abc.class” for updating, it is convenient if the programs having the relationship of R2, R8 and R10 can be registered at the same time when the program is registered. Therefore, the program ID table 60 includes the program ID “ABC”, the path “/java/src/abc.java”, the path “/java/src/class/abc.class”, the program ID “DEF”, and the program ID “DEF”. GHI_LIB "is stored in association with each other. Here, the program ID “DEF” is a program ID associated with the path of the program having the R4 relationship, and the program ID “GHI_LIB” is a program ID associated with the path of the program having the R6 relationship. The program IDs “DEF” and “GHI_LIB” are child program IDs of the parent program ID “ABC”.

  When the program ID “ABC” is specified by any configuration of the program development management apparatus 100, the configuration refers to the table by program ID 60 and the path “/ java / src / associated with the program ID“ ABC ”is referred to. abc.java ”, the path“ /java/src/class/abc.class ”, the program ID“ DEF ”and the program ID“ GHI_LIB ”are read, and the path“ / java / src / associated with the program ID “DEF” is read. def.java "and the path" /java/class/def.class "are read, and the path" /java/src/lib/ghi_lib.java "and the path" / java / src / "associated with the program ID" GHI_LIB "are read. lass / lib / ghi_lib.class "read the.

  According to this modification, by assigning a program ID to the relationship between programs in advance, the program can be managed including the relationship between them. Therefore, the registration omission can be prevented when registering the program to be developed, and the release omission can also be prevented at the time of release.

  In addition, when “abc.class” is modified, there is a relationship of R10, so “def.class” must be registered at the same time. At this time, the program ID “ABC” is designated. When only “def.class” is corrected, the child program ID “DEF” may be specified instead of the parent program ID “ABC”. As described above, in the present modification, the program ID can be managed efficiently even when there is a one-way reference relationship by providing the program ID with a parent-child relationship.

  The program ID “GHI_LIB” may be registered as a child program ID of a program ID other than the program ID “ABC”. In particular, it is convenient to register as a child program ID of a program ID associated with a program referring to “ghi_lib.class”. By defining the parent-child relationship of program IDs in this way, programs can be managed efficiently when developing a system using a program (library) shared by a plurality of programs.

  Although the present invention has been described based on the embodiments, the embodiments merely show the principle and application of the present invention, and the embodiments are defined in the claims. Needless to say, many modifications and arrangements can be made without departing from the spirit of the present invention.

1 is a system configuration diagram showing a program development system including a program development management device according to an embodiment. It is a block diagram which shows the function and structure of the program development management apparatus which concerns on embodiment. It is a data structure figure of the program table classified by theme and program table classified by release of FIG. It is a screen figure of a release approval screen. It is a flowchart which shows a series of processes in program development management. It is a data structure figure of the program table classified by theme and the program table classified by release concerning the modification of release conditions. It is a screen figure of the warning screen which concerns on the 1st modification of a release approval part. It is a screen figure of the caution screen concerning the 2nd modification of a release approval part. It is a data structure figure of the program table classified by theme concerning the 2nd modification of a release approval part, and a program table classified by release. It is a directory block diagram concerning the modification of a program development management apparatus. It is a data structure figure which shows the table classified by program ID which concerns on the modification of FIG.

Explanation of symbols

  1 program table for each theme, 80 release approval screen, 100 program development management device, 110 development update unit, 120 release approval unit, 130 directory generation unit, 140 release execution unit, 150 storage device.

Claims (7)

A program table for each theme for managing programs to be developed and release conditions for each development theme;
A directory generation unit that refers to the theme-specific program table, extracts a program having the same release condition as one release unit, generates a release unit directory, and stores the extracted release unit program in the directory; A program development management device comprising: It also has a release approval section that accepts release approvals on a release basis.
2. The program according to claim 1, wherein only the release unit accepted by the release approval unit is caused to cause the directory generation unit to generate a directory for the release unit and store the program in the directory. Development management device. The theme-specific program table includes a flag indicating completion of program update,
The release approval unit refers to the theme-specific program table, and if there is a program in which at least one of the release unit programs does not have a flag indicating the completion of update, the release approval unit does not accept the release unit release approval. The program development management device according to claim 2. The theme-specific program table includes a flag indicating completion of program update,
3. The release approval unit refers to the theme-specific program table, and displays a warning if there is a program for which an update completion flag is not set in a release unit program that has received approval. The program development management device described in 1. The theme-specific program table includes a flag indicating completion of program update,
The release approval unit refers to the theme-specific program table, and if there is a program that does not have an update completion flag in a release-unit program that has received approval, a predetermined rule for release conditions of the program The program development management apparatus according to claim 2, wherein the program is removed from the release unit.   2. The program development management apparatus according to claim 1, further comprising a program ID-specific table that stores a program ID and a program path and / or another program ID in association with each other. A function for generating a theme-specific program table for managing programs to be developed and release conditions for each development theme;
A function of referring to the theme program table, extracting a program having the same release condition as one release unit, generating a release unit directory, and storing the extracted release unit program in the directory; A computer program characterized by being realized.

Images