JP2022108452A - Program managing device and program managing method - Google Patents

Abstract

To provide a program managing device capable of efficiently managing a program in a development project like an intra-server development in which multiple persons are deployed.SOLUTION: A program managing device that manages the development work for a program in a server by multiple developers includes: a first processing unit that extracts a program difference which is a difference between programs developed by the multiple developers, respectively, and a present program stored in a verification environment; a storing unit that has a merging rule which defines the rule for a merging process in accordance with the program difference in advance; and a second processing unit that extracts a module difference which is a difference between a developed module and a present module. The second processing unit discards the program difference when the module difference is not extracted, refers to the merging rule, and executes the merging process on the developed program and the present program, thereby updating the program in the verification environment.SELECTED DRAWING: Figure 7

Description

本発明は、プログラム管理装置及びプログラム管理方法に関する。 The present invention relates to a program management device and program management method.

サーバ内開発など、複数人による開発プロジェクトにおいては、開発したプログラムがGitに代表される構成管理ツールなどに登録して管理される（例えば、特許文献１）。この構成管理ツールでは、改修ソースを行単位でマージするため、複数人の作業であっても同行で異なる改修が入らない限り、改修ソースのデグレードなどは発生しないようになっている。 In a development project involving multiple people, such as in-server development, a developed program is registered and managed in a configuration management tool such as Git (for example, Patent Document 1). This configuration management tool merges modified sources line by line, so even if multiple people are working together, unless different modifications are made by the same person, degradation of the modified source will not occur.

国際公開第１６／０１６９７５号WO 16/016975

プロジェクトが大きくなればなるほど、サーバ内開発を実施したときのプログラム管理、構成管理にかかる作業時間が長くなり、開発物の環境反映にネックとなり、結果作業コストが増大するという課題がある。特に、レガシーシステムの開発の場合、行単位でマージする際に、同行で異なる改修が入った場合はコンフリクトとしてエラーが発生するため、開発者による手動のマージ作業が残存していた。また、マージする際に、プログラムの差分に関して予め定められたルールを参照する方法も知られているが、プログラムの差分だけを考慮すると、過剰な差分が抽出されてしまい、やはり手作業による対応が必要であった。 The larger the project is, the longer the work time required for program management and configuration management when performing development within the server becomes a bottleneck in reflecting the environment of the development product, resulting in an increase in work costs. In particular, in the case of legacy system development, when merging line by line, an error would occur as a conflict if different modifications were made at the same line, so manual merging work by the developer remained. There is also a known method of referring to predetermined rules regarding program differences when merging. was necessary.

本発明の目的は、サーバ内開発などの複数人による開発プロジェクトにおけるプログラムの管理を効率的に実施することのできるプログラム管理装置及びプログラム管理方法を提供することにある。 SUMMARY OF THE INVENTION It is an object of the present invention to provide a program management apparatus and a program management method capable of efficiently managing programs in a development project by a plurality of people, such as in-server development.

前述の課題を解決するために、本発明は、複数の開発者によるサーバ内におけるプログラムの開発作業を管理するプログラム管理装置において、前記複数の開発者がそれぞれ開発したプログラムと、検証環境に格納されている現在のプログラムとの差分であるプログラム差分を抽出する第一処理部と、前記プログラム差分に応じたマージ処理のルールが予め定められたマージルールを有する記憶部と、前記複数の開発者がそれぞれ開発したモジュールと、検証環境に格納されている現在のモジュールとの差分であるモジュール差分を抽出する第二処理部と、を備え、前記第二処理部は、前記モジュール差分が抽出されない場合、前記プログラム差分を棄却し、前記マージルールを参照して、前記開発したプログラムと前記現在のプログラムとをマージ処理することで前記検証環境のプログラムを更新する。 In order to solve the above-described problems, the present invention provides a program management apparatus for managing program development work in a server by a plurality of developers, in which programs developed by the plurality of developers and stored in a verification environment are stored in a verification environment. a first processing unit for extracting a program difference that is a difference from a current program that is currently running; a storage unit having merge rules in which rules for merging processing according to the program difference are predetermined; each developed module and a second processing unit that extracts a module difference that is a difference from the current module stored in the verification environment, wherein the second processing unit extracts the module difference when the module difference is not extracted, The program in the verification environment is updated by discarding the program difference, referring to the merge rule, and merging the developed program and the current program.

本発明によれば、プログラムとモジュールの差分の関係を考慮したプログラム管理が可能となり、プログラム管理、構成管理に伴うコストを削減することが可能となる。 According to the present invention, it becomes possible to perform program management in consideration of the relationship between programs and modules, and to reduce costs associated with program management and configuration management.

本発明の実施形態に係る開発支援システムの構成例について概要を示した図である。BRIEF DESCRIPTION OF THE DRAWINGS It is the figure which showed the outline|summary about the structural example of the development support system which concerns on embodiment of this invention. 本発明の実施形態に係る開発支援システムにおけるプログラムの登録の推移の概要を示す図である。FIG. 4 is a diagram showing an overview of transition of program registration in the development support system according to the embodiment of the present invention; ソーシャルコーディングにおけるブランチの作成例について概要を示した図である。FIG. 4 is a diagram showing an overview of an example of branch creation in social coding; ソーシャルコーディングにおけるブランチの統合例について概要を示した図である。FIG. 4 is a diagram showing an overview of an example of branch integration in social coding; 本発明の実施形態におけるサーバ内開発の処理の流れの例について概要を示したフローチャートである。4 is a flowchart showing an overview of an example of the flow of processing for development within the server according to the embodiment of the present invention; 本発明の実施形態におけるサーバ内開発から構成管理の処理の流れの例について概要を示したフローチャートである。4 is a flowchart showing an overview of an example of the flow of processing from development within the server to configuration management in the embodiment of the present invention; 本発明の実施形態における開発ソースの他環境への同期処理の流れの例について概要を示したフローチャートである。4 is a flow chart showing an overview of an example of the flow of processing for synchronizing a development source with another environment in an embodiment of the present invention; 本発明の実施形態における親子定義のデータ構成と具体的なデータの例について概要を示した図である。FIG. 4 is a diagram showing an overview of a data configuration of parent-child definitions and specific data examples in the embodiment of the present invention; 本発明の実施の形態におけるコミット履歴のデータ構成と具体的なデータの例について概要を示した図である。FIG. 3 is a diagram showing an overview of a data configuration of a commit history and specific data examples according to the embodiment of the present invention; 本発明の実施形態における各環境で稼働しているバージョン情報のデータ構成と具体的なデータの例について概要を示した図である。FIG. 3 is a diagram showing an overview of the data structure of version information running in each environment and an example of specific data in the embodiment of the present invention; 本発明の実施形態におけるユーザマスタのデータ構成と具体的なデータの例について概要を示した図である。FIG. 3 is a diagram showing an overview of a data configuration of a user master and an example of specific data according to the embodiment of the present invention; 本発明の実施形態におけるブランチ管理テーブルのデータ構成と具体的なデータの例について概要を示した図である。4 is a diagram showing an overview of the data configuration of a branch management table and specific data examples in the embodiment of the present invention; FIG.

以下、本発明の実施形態について、図面を用いて説明する。 BEST MODE FOR CARRYING OUT THE INVENTION Hereinafter, embodiments of the present invention will be described with reference to the drawings.

図２は、本実施形態に係る開発支援システムにおけるプログラムの登録の推移の概要を示す図である。図２では、バージョン管理及びリポジトリ管理において、環境毎のプログラムを管理する領域であるブランチの分岐例と、ブランチにおいて開発したプログラムについての登録（コミット）の状況の例と、を左から右方向への時系列で示している。ここでは、本番環境で稼働しているプログラムが格納されるマスタブランチから、まずプロジェクト及び品質保証のためのブランチ(顧客検証用)が分岐して作成される。次に、開発者Ａ、Ｂ及びＣのそれぞれが、自身の開発のためのブランチを分岐させて作成し、開発が完了した後に顧客検証用ブランチに統合（マージ）してから、マスタブランチに統合（マージ）されている。 FIG. 2 is a diagram showing an overview of transition of program registration in the development support system according to the present embodiment. In FIG. 2, in version control and repository management, from left to right, an example of a branch, which is an area for managing programs for each environment, and an example of the registration (commit) status of a program developed in the branch. are shown in chronological order. Here, a branch for project and quality assurance (for customer verification) is first created by branching from the master branch that stores the program running in the production environment. Next, each of developers A, B, and C creates a branch for their own development, integrates (merges) into the customer verification branch after development is completed, and then integrates into the master branch. (merged).

プログラムは、環境などの単位で個別に設けられたブランチ上で管理される。図３は、コーディングにおけるブランチの作成例について概要を示した図である。図３では、マスタとなるプログラムが登録されているマスタブランチ４０１（ブランチ名“ｍａｓｔｅｒ”）に、“A.xxx”や“B.xxx”などのプログラム（ソースコード）が登録されていることを示している。新しいブランチは、任意のタイミングで作成することができ、例えば、既存のリポジトリをコピーすることで作成することができる。この場合、作成されたブランチは元のブランチから分岐したものとなる。なお、最初のブランチは新規に作成する。 Programs are managed on branches that are individually provided for units such as environments. FIG. 3 is a diagram showing an overview of an example of creating branches in coding. In FIG. 3, it can be seen that programs (source code) such as "A.xxx" and "B.xxx" are registered in the master branch 401 (branch name "master") in which the master program is registered. showing. A new branch can be created at any time, for example by copying an existing repository. In this case, the created branch is a branch of the original branch. Create a new branch first.

図３では、マスタブランチ４０１から、顧客検証用環境のプログラムを格納するメインブランチである顧客検証用ブランチ４０２（ブランチ名“ｄｅｖｅｌｏｐ”）が分岐して作成された状態を示している。さらに、顧客検証用ブランチ４０２から、環境Ａについての開発用のブランチである環境Ａ用ブランチ４０３（ブランチ名“ｆｅａｔｕｒｅ＿Ａ”）が分岐して作成され、同じく、顧客検証用ブランチ４０２から、環境Ｂについての開発用のブランチである環境Ｂ用ブランチ４０４（ブランチ名“ｆｅａｔｕｒｅ＿Ｂ”）が分岐して作成された状態を示している。 FIG. 3 shows a state in which a customer verification branch 402 (branch name “develop”), which is the main branch for storing the program for the customer verification environment, is created by branching from the master branch 401 . Further, from the customer verification branch 402, an environment A branch 403 (branch name "feature_A"), which is a development branch for the environment A, is created by branching. A branch for environment B 404 (branch name "feature_B"), which is a branch for development of the environment B, is branched and created.

また、作成されたブランチは、例えば開発対象のプログラムを他環境へ反映／同期させるなど、任意のタイミングで分岐元のブランチに統合（マージ）することができる。図４は、環境Ａ及び環境Ｂで開発したプログラムを顧客検証用環境に反映する際のブランチの統合例について概要を示した図である。図４では、分岐元である顧客検証用ブランチ４０２に対して、分岐して作成された環境Ａ用ブランチ４０３と、分岐して作成された環境Ｂ用ブランチ４０４とが、マージされる状態を示している。このマージにより、顧客検証用ブランチ４０２に対して、環境Ａ用ブランチ４０３に登録されたプログラムの内容が行単位で差分が判断され、挿入される。このように、開発の進展に伴って、複数のブランチに分岐したり、複数のブランチを統合したりしながら開発が進められる。 Also, the created branch can be integrated (merged) into the original branch at any timing, such as reflecting/synchronizing the program to be developed with another environment. FIG. 4 is a diagram showing an overview of an example of integration of branches when programs developed in environment A and environment B are reflected in the customer verification environment. FIG. 4 shows a state in which a branch 403 for environment A created by branching and a branch 404 for environment B created by branching are merged with respect to a customer verification branch 402 which is a branch source. ing. As a result of this merging, the contents of the program registered in the environment A branch 403 are inserted into the customer verification branch 402 after judging the difference line by line. In this way, as the development progresses, the development progresses while branching into a plurality of branches or integrating a plurality of branches.

前述のように、環境などの単位で個別に設けられたブランチ上で管理されるプログラムは、サーバ内に格納される。図５は、サーバ内開発の処理について概要を示した図である。図５では、プログラム修正によって開発用サーバ２００に格納されているプログラム２０３が、コンパイルの実施（コンパイラ２０２の実行）によってモジュール２０１が生成される状態を示している。 As described above, programs managed on branches individually provided for each environment or the like are stored in the server. FIG. 5 is a diagram showing an outline of processing for development within the server. FIG. 5 shows a state in which a program 203 stored in the development server 200 by program modification is compiled (executed by the compiler 202) to generate a module 201. FIG.

＜システム構成＞
図１は、本発明の実施形態に係る開発支援システム１の構成例について概要を示した図である。本実施形態の開発支援システム１は、例えば、プログラム管理装置である開発支援サーバ１００に対して、ＬＡＮ（Local Area Network）などのネットワークを介して、各ユーザがそれぞれ使用する開発用サーバ(うち1台の開発用サーバは顧客検証用)２００が複数接続され、相互に通信可能な構成を有する。各ユーザは開発用クライアント３００よりネットワークを介して開発支援サーバ１００及び開発用サーバ２００へ通信可能な構成を有する。なお、開発支援サーバ１００、開発用サーバ２００及び開発用クライアント３００の間の通信は、有線、無線を問わず、一般的な公衆回線網、例えば「多数同時接続」、「超低遅延」を可能とした第５世代移動通信システム、いわゆる５Ｇ（５th Generation）を用いることができる。 <System configuration>
FIG. 1 is a diagram showing an overview of a configuration example of a development support system 1 according to an embodiment of the present invention. The development support system 1 of the present embodiment connects, for example, a development support server 100, which is a program management device, via a network such as a LAN (Local Area Network) to a development server (one of which is used by each user). A plurality of development servers (for customer verification) 200 are connected to each other and have a configuration capable of communicating with each other. Each user has a configuration that enables communication from the development client 300 to the development support server 100 and the development server 200 via the network. Communication between the development support server 100, the development server 200, and the development client 300 can be made through a general public network, such as "multiple simultaneous connections" and "ultra-low delay", regardless of whether it is wired or wireless. 5G (5th Generation) can be used.

開発支援サーバ１００は、例えば、プログラムソースのバージョン管理や各環境情報の管理などの機能を有するサーバシステムであり、一般的なサーバ機器やクラウドコンピューティング環境上に構築された仮想サーバなどにより実装され、図示しないＯＳ（Operating System）やＤＢＭＳ（DataBase Management System）、Ｗｅｂサーバプログラムなどのミドルウェア上で稼働するソフトウェアプログラムなどにより実装される管理端末装置１１０及び開発支援サーバリポジトリ１２０などの各部を有する。 The development support server 100 is, for example, a server system having functions such as program source version management and environmental information management, and is implemented by a general server device or a virtual server built on a cloud computing environment. , an OS (Operating System), a DBMS (DataBase Management System), and a software program running on middleware such as a Web server program (not shown).

管理端末装置１１０は、３つの処理部（第一処理部１１１、第二処理部１１２、関係処理部１１３）と、処理実施時に活用されるワークスペース１１７と、管理端末記憶部１１４と、を有する。管理端末装置１１０は、複数の開発者がそれぞれ開発したモジュール２０１及びプログラム２０３を、顧客検証用サーバ２１０からワークスペース１１７へ複製するとともに、開発支援サーバリポジトリ１２０にある、現在のモジュールやプログラム、環境情報を参照した上で、３つの処理部にて処理がされる。また、管理端末記憶部１１４は、マージルール１１５と、親子定義１１６と、差分結果１１８と、を有している。 The management terminal device 110 has three processing units (a first processing unit 111, a second processing unit 112, and a relation processing unit 113), a workspace 117 that is utilized when performing processing, and a management terminal storage unit 114. . The management terminal device 110 copies the modules 201 and programs 203 developed by a plurality of developers from the customer verification server 210 to the workspace 117, and also copies the current modules, programs, and environments in the development support server repository 120. After referring to the information, processing is performed by the three processing units. The management terminal storage unit 114 also has merge rules 115 , parent-child definitions 116 and difference results 118 .

第一処理部１１１は、複数の開発者がそれぞれ開発したプログラムと、検証環境に格納されている現在のプログラムとの差分であるプログラム差分を抽出する。第二処理部１１２は、複数の開発者がそれぞれ開発したモジュールと、検証環境に格納されている現在のモジュールとの差分であるモジュール差分を抽出する。また、第二処理部１１２は、抽出したモジュール差分を差分結果１１８として管理端末記憶部１１４に出力する。さらに、第二処理部１１２は、モジュール差分が抽出されない場合、プログラム差分を棄却し、マージルール１１５を参照して、開発したプログラムと現在のプログラムとをマージ処理することで検証環境のプログラムを更新する。関係処理部１１３は、モジュール差分が抽出され、かつ、プログラム差分が抽出されなかった場合、モジュールとプログラムの関係を調査し、親子定義１１６を更新（上書き）する。なお、各処理部から出力されたコマンドは、開発支援サーバリポジトリ１２０の対象リポジトリにて実行される。 The first processing unit 111 extracts program differences, which are differences between programs developed by a plurality of developers and the current program stored in the verification environment. The second processing unit 112 extracts module differences, which are differences between modules developed by a plurality of developers and current modules stored in the verification environment. The second processing unit 112 also outputs the extracted module difference as a difference result 118 to the management terminal storage unit 114 . Furthermore, when the module difference is not extracted, the second processing unit 112 rejects the program difference, refers to the merge rule 115, and updates the program in the verification environment by merging the developed program and the current program. do. If the module difference is extracted but the program difference is not extracted, the relationship processing unit 113 investigates the relationship between the module and the program, and updates (overwrites) the parent-child definition 116 . Commands output from each processing unit are executed in the target repository of the development support server repository 120 .

ここで、親子定義１１６とは、モジュールとプログラムの関係を規定するものであり、後述する図８のようにプログラムをコンパイルした結果生成されるモジュールが相対するように明示されているものである。複数のプログラムから１つのモジュールが生成される場合、同名のモジュールが複数のプログラムに相対するものとして繰り返し表記される。
また、マージルール１１５とは、プログラム差分に応じたマージ処理のルールが予め定められた外部ファイルであり、第二処理部１１２がマージ処理する際に参照される。このマージルール１１５では、マージ処理中に無視して良い箇所が定義されている。例えば、ファイルの各行の先頭６文字を差分として認識しないというルールの場合、改行コードから６文字分をXXXXXXとダミーの値に変換するルールを設定することでマージ処理時には同一部分として認識される。 Here, the parent-child definition 116 defines the relationship between a module and a program, and as shown in FIG. 8, which will be described later, the modules generated as a result of compiling the program are specified so as to face each other. When one module is generated from multiple programs, the module with the same name is repeatedly represented as corresponding to multiple programs.
The merge rule 115 is an external file in which rules for merge processing according to program differences are predetermined, and is referred to when the second processing unit 112 performs merge processing. The merge rule 115 defines portions that can be ignored during the merge process. For example, if the rule is not to recognize the first 6 characters of each line of a file as a difference, by setting a rule that converts the 6 characters from the line feed code to XXXXXX and dummy values, it will be recognized as the same part during merge processing.

開発支援サーバリポジトリ１２０は、複数の開発者により開発されたプログラムや各種成果物、環境情報を記憶して集中的に管理するデータベース等の記憶領域である。プログラムや各種成果物を管理するのがアプリソースコードリポジトリ１２１であり、バージョン管理などを実施し、例えば後述する、コミット履歴テーブル１２４、ユーザマスタテーブル１２６及びブランチ管理テーブル１２７を保持する。アプリソースコードリポジトリ１２１に保持されたこれらの情報が、管理端末装置１１０の各処理部で生成されるコマンドによって、更新される。IaCコードリポジトリ１２２は、各環境の構築もしくはプログラムの自動リリースに必要なパラメータ情報に加え、後述する環境バージョン管理テーブル１２５などを保持する。モジュールバックアップリポジトリ１２３は、アプリソースコードリポジトリ１２１で保持すると容量が大きくなってしまうバイナリデータを保持し、例えばモジュールのバージョン管理を実施する。 The development support server repository 120 is a storage area such as a database that stores programs developed by a plurality of developers, various products, and environment information and centrally manages them. The application source code repository 121 manages programs and various products, implements version management, and holds, for example, a commit history table 124, a user master table 126, and a branch management table 127, which will be described later. These pieces of information held in the application source code repository 121 are updated by commands generated by each processing unit of the management terminal device 110 . The IaC code repository 122 holds an environment version management table 125, which will be described later, and the like, in addition to parameter information necessary for building each environment or automatically releasing a program. The module backup repository 123 holds binary data whose capacity would be large if held in the application source code repository 121, and implements module version management, for example.

開発用サーバ２００は、例えば、開発者等の各ユーザがプログラム２０３の開発を実施するサーバであり、図示しないＯＳなどのミドルウェア上で稼働するソフトウェアプログラムにより実装されるコンパイラ２０２、モジュール２０１を有する。開発用サーバの中の1台は顧客検証用サーバ２１０として、他の開発用サーバで開発したプログラムの組み合わせテストなどを実施する環境とするが、構成としては開発用サーバ２００と同等である。 The development server 200 is, for example, a server where each user such as a developer develops a program 203, and has a compiler 202 and a module 201 implemented by a software program running on middleware such as an OS (not shown). One of the development servers is used as a customer verification server 210, and is used as an environment for executing a combination test of programs developed by other development servers.

開発用クライアント３００は、開発者等の各ユーザが開発支援サーバ１００及び開発用サーバ２００へネットワークを介して相互通信し、開発用サーバ２００の中で開発作業を行うＰＣ（Personal Computer）等の情報処理端末であり、図示しないＯＳなどのミドルウェア上で稼働するソフトウェアプログラムを有する。 The development client 300 communicates with the development support server 100 and the development server 200 via a network by each user such as a developer, and stores information such as a PC (Personal Computer) on which development work is performed in the development server 200. It is a processing terminal and has a software program running on middleware such as an OS (not shown).

＜処理フロー（開発用サーバ内のモジュール反映）＞
以下では、本実施形態における開発用サーバ２００内のモジュール反映の際の各処理について説明する。図６は、開発用サーバ２００内のモジュール反映の処理の流れの例について概要を示したフローチャートである。 <Processing flow (reflection of module in development server)>
Below, each process at the time of module reflection in the development server 200 in this embodiment will be described. FIG. 6 is a flowchart showing an overview of an example of the flow of module reflection processing in the development server 200. As shown in FIG.

まず、開発用サーバ２００でコンパイルを実施し、同タイミングで管理端末装置１１０の中にあるワークスペース１１７へ開発用サーバ２００に格納されているモジュール２０１及びプログラム２０３が複製され、モジュール２０５及びプログラム２０４として設置される。コンパイルの実施後、開発用サーバ２００内にあるモジュール２０１が開発環境に反映される（Ｓ０１）。なお、ワークスペース１１７へ複製する際には、以前の処理等で生成されたファイルがある場合は削除を実施し、本処理に影響がないようにする。この処理により、以前の処理で生成されたファイルの影響を受けることなく、別環境への反映処理が再帰的に実行できる他、エラーが発生して再実行することが可能になる。 First, the development server 200 compiles, and at the same timing, the module 201 and program 203 stored in the development server 200 are copied to the workspace 117 in the management terminal device 110, and the module 205 and program 204 are copied. is installed as After compiling, the module 201 in the development server 200 is reflected in the development environment (S01). Note that when copying to the workspace 117, if there is a file generated by previous processing or the like, it is deleted so as not to affect this processing. By this processing, it is possible to recursively execute the reflection processing to another environment without being affected by the files generated by the previous processing, and to re-execute it even if an error occurs.

その後、ワークスペース１１７にあるプログラム２０４がアプリソースコードリポジトリ１２１に移動し、同リポジトリにあるユーザマスタテーブル１２６からユーザ情報を受け取った上でプログラムの登録処理コマンドが実行され、リポジトリ内にあるコミット履歴テーブル１２４及びブランチ管理テーブル１２７の更新処理が実施される（Ｓ０２）。前述のプログラム登録と同様にモジュール２０５に関してもモジュールバックアップリポジトリ１２３に移動し、登録処理コマンドが実行され、アプリソースコードリポジトリ１２１内にあるコミット履歴テーブル１２４の更新処理が実施される（Ｓ０３）。 After that, the program 204 in the workspace 117 moves to the application source code repository 121, receives user information from the user master table 126 in the same repository, executes the program registration processing command, and commits the commit history in the repository. Update processing of the table 124 and the branch management table 127 is performed (S02). Similar to the program registration described above, the module 205 is also moved to the module backup repository 123, the registration processing command is executed, and the commit history table 124 in the application source code repository 121 is updated (S03).

プログラム及びモジュールの登録後は、IaCコードリポジトリ１２２に格納される環境バージョン管理テーブル１２５に対して更新処理が実施される（Ｓ０４）。なお、コミット履歴テーブル１２４は後述の図９、環境バージョン管理テーブル１２５は後述の図１０、ユーザマスタテーブル１２６は後述の図１１、ブランチ管理テーブル１２７は後述の図１２、にて説明する。 After the registration of the programs and modules, the environment version management table 125 stored in the IaC code repository 122 is updated (S04). The commit history table 124 will be described in FIG. 9, the environment version management table 125 in FIG. 10, the user master table 126 in FIG. 11, and the branch management table 127 in FIG.

＜処理フロー（別サーバへの開発内容同期）＞
以下では、本実施形態における別サーバへの開発内容同期の際の各処理について説明する。図７は、別サーバへの開発内容同期の処理の流れの例について概要を示したフローチャートである。まず、前述の開発用サーバ内モジュール反映と同様に、管理端末装置１１０の第一処理部１１１は、同期元のサーバに格納されているプログラムをワークスペース１１７へ複製する（Ｓ１０１）。次に、第一処理部１１１は、同期先のサーバにあるプログラムをIaCコードリポジトリ１２２に格納されている環境バージョン管理テーブル１２５を参照し、アプリソースコードリポジトリ１２１から取得する（Ｓ１０２）。なお、ワークスペース１１７へ複製する際に、以前の処理等で生成されたファイルがある場合は削除が実施され、本処理に影響がないようにする。この処理により、以前の処理で生成されたファイルの影響を受けることなく、別環境への反映処理が再帰的に実行できる他、エラーが発生して再実行することが可能になる。 <Process flow (synchronization of development content to another server)>
In the following, each process when synchronizing development content with another server in this embodiment will be described. FIG. 7 is a flowchart showing an overview of an example of the flow of processing for synchronizing development content with another server. First, the first processing unit 111 of the management terminal device 110 duplicates the program stored in the synchronization source server to the workspace 117 (S101), in the same manner as the module reflection in the development server described above. Next, the first processing unit 111 refers to the environment version management table 125 stored in the IaC code repository 122 and acquires the program in the synchronization destination server from the application source code repository 121 (S102). When duplicating to the workspace 117, if there is a file generated by previous processing or the like, it is deleted so as not to affect this processing. By this processing, the reflection processing to another environment can be recursively executed without being affected by the files generated by the previous processing, and it is also possible to re-execute when an error occurs.

その上で、第一処理部１１１は、前述の処理で取得したプログラムを機械的に合体させる、プログラムマージ処理を実施する（ステップＳ１０３）。その後、第一処理部１１１は、マージ処理判定を実施し（ステップＳ１０４）、処理が成功した場合は、後続のプログラムの登録（ステップＳ１０５）が実施される。マージ処理判定の結果、ネットワークやサーバなどインフラ側のエラー及び同期先サーバへの同期実行権限が不足している場合は、エラーコードが生成され（ステップＳ１０６）、ログを作成して（ステップＳ１０７）処理が終了する。 After that, the first processing unit 111 performs program merge processing for mechanically merging the programs acquired in the above-described processing (step S103). After that, the first processing unit 111 performs merge processing determination (step S104), and when the processing is successful, registration of the subsequent program is performed (step S105). As a result of the merge processing determination, if there is an error on the infrastructure side such as the network or server, or if the synchronization execution authority for the synchronization destination server is insufficient, an error code is generated (step S106) and a log is created (step S107). Processing ends.

また、マージ処理判定の結果、マージコマンドエラーの場合は、管理端末装置１１０の第二処理部１１２が、管理端末記憶部１１４に格納されているマージルール１１５を参照し、マージルールをオプションでコマンド指定した上で、再度マージ処理（ルール参照マージ処理）のコマンドを実行する（ステップＳ１０８）。その後、マージ処理判定が再度実施され（ステップＳ１０９）、前述と同様、処理が成功した場合は、後続のプログラムの登録（Ｓ１０５）が実施され、インフラ側のエラー及び同期先サーバへの同期実行権限が不足している場合は、エラーコード生成（ステップＳ１１０）とログ作成（ステップＳ１０７）後に処理が終了する。 If the result of the merge processing determination is a merge command error, the second processing unit 112 of the management terminal device 110 refers to the merge rule 115 stored in the management terminal storage unit 114, and selects the merge rule as an option. After designation, the merge processing (rule reference merge processing) command is executed again (step S108). After that, the merge process determination is performed again (step S109), and if the process is successful in the same manner as described above, the subsequent program is registered (S105). is insufficient, the process ends after error code generation (step S110) and log creation (step S107).

再度のマージ処理判定の結果、マージコマンドエラーの場合、第二処理部１１２は、ステップＳ１１での同期元プログラムの取得と同様に、同期元のサーバに格納されているモジュールをワークスペース１１７へ複製する（ステップＳ１１１）。次に、第二処理部１１２は、同期先のサーバにあるモジュールをIaCコードリポジトリ１２２に格納されている環境バージョン管理テーブル１２５を参照し、モジュールバックアップリポジトリ１２３から取得する（ステップＳ１１２）。その上で、第二処理部１１２は、前述の処理で取得したモジュールについてバイナリ比較を実施し、差分があったモジュールファイル一覧を差分結果１１８として管理端末記憶部１１４に格納する（ステップＳ１１３）。なお、差分結果１１８を管理端末記憶部１１４へ格納する際に、以前の処理等で生成されたファイルがある場合は削除が実施され、本処理に影響がないようにする。この処理により、以前の差分結果の影響を受けることなく、別環境への反映処理が再帰的に実行できる他、エラーが発生して再実行することが可能になる。 If a merge command error is found as a result of the merge process determination again, the second processing unit 112 copies the module stored in the synchronization source server to the workspace 117 in the same manner as the acquisition of the synchronization source program in step S11. (step S111). Next, the second processing unit 112 refers to the environment version management table 125 stored in the IaC code repository 122 and acquires the module in the synchronization destination server from the module backup repository 123 (step S112). After that, the second processing unit 112 performs binary comparison on the modules acquired in the above-described process, and stores a list of module files with differences in the management terminal storage unit 114 as the difference result 118 (step S113). Note that when the difference result 118 is stored in the management terminal storage unit 114, if there is a file generated by a previous process or the like, it is deleted so as not to affect this process. By this processing, the reflection processing to another environment can be executed recursively without being affected by the previous difference result, and it is also possible to re-execute the processing when an error occurs.

その後、第二処理部１１２は、親子定義１１６を管理端末記憶部１１４から取得（ステップＳ１１４）し、差分結果１１８に差分の記載がないモジュールに（親子定義上）関係するプログラムの中に差分が発生している場合、同期元プログラムの変更を棄却し、同期先プログラムを正として扱う（ステップＳ１１５）。この第二処理部１１２の関係プログラム差分棄却処理により、第一処理部１１１で実施されたマージ処理判定（ステップＳ１０４及びステップＳ１０９）で過剰に摘出された差分の一部が自動的に棄却され、これまで手動で修正してマージ処理していた作業が不要となる。なお、差分結果１１８に差分の記載があるモジュールに関係するプログラムの中に差分が発生していない場合は、後続のマージ処理判定（ステップＳ１１７）でマージエラーとなる。 After that, the second processing unit 112 acquires the parent-child definition 116 from the management terminal storage unit 114 (step S114), and the difference is found in the program related to the module for which the difference is not described in the difference result 118 (in terms of the parent-child definition). If it has occurred, the change of the synchronization source program is rejected, and the synchronization destination program is treated as positive (step S115). By this related program difference rejection processing of the second processing unit 112, a part of the difference excessively extracted in the merge processing determination (steps S104 and S109) performed by the first processing unit 111 is automatically rejected, This eliminates the need for manually correcting and merging work. Note that if no difference occurs in the program related to the module for which the difference is described in the difference result 118, a merge error will occur in the subsequent merge processing determination (step S117).

このように、ステップＳ１１５にて、モジュールに差分がないプログラムを廃棄した上で、第二処理部１１２は、マージルール１１５を参照し、マージルールをオプションで指定して再度マージ処理（ルール参照マージ処理）のコマンドを実行する（ステップＳ１１６）。その後、マージ処理判定が再度実施され（ステップＳ１１７）、前述と同様、処理が成功した場合は、後続のプログラムの登録（Ｓ１０５）が実施され、インフラ側のエラー及び同期先サーバへの同期実行権限が不足している場合は、エラーコード生成（ステップＳ１１８）とログ作成（ステップＳ１０７）後に処理が終了する。 In this way, in step S115, after discarding programs with no difference in modules, the second processing unit 112 refers to the merge rule 115, designates the merge rule as an option, and performs merge processing again (rule reference merge). process) is executed (step S116). After that, the merge process determination is performed again (step S117), and if the process is successful in the same manner as described above, the registration of the subsequent program is performed (S105). is insufficient, the process ends after error code generation (step S118) and log creation (step S107).

再度のマージ処理判定の結果、マージコマンドエラーの場合は、関係処理部１１３による親子定義見直し処理（ステップＳ１１９～ステップＳ１２２）を実施する。マージコマンドエラーが発生すると、関係処理部１１３は、まず、アプリソースコードリポジトリ１２１に対してテスト用のブランチを作成し（ステップＳ１１９）、同期元のサーバにて、プログラムとモジュールの親子関係調査スクリプトを実施する（ステップＳ１２０）。ここで実行するスクリプトは、プログラムを１つずつテスト用のブランチでコンパイルし、生成されたモジュールが、ワークスペース１１７にある（ステップＳ１１１等で取得した）モジュールと合致するかを再帰的に検証するものである。合致しない場合は、プログラムとモジュールの親子関係が間違っているため、別のプログラムに入れ替えてモジュールが合致するかを確認し、正しい親子関係を調査していく。次に、関係処理部１１３は、スクリプトの実行結果を、管理端末記憶部１１４に格納されている親子定義１１６へ上書きする（ステップＳ１２１）。この際、実行するスクリプトは単一のプログラムを同期元環境でコンパイルを実施し、生成されたモジュールがワークスペース１１７と合致するかを検証するものであり、全てのプログラムに対して再帰的に実行されるものとする。その後、関係処理部１１３が、IaCコードリポジトリ１２２の環境情報とアプリソースコードリポジトリ１２１を参照し、同期元環境のリストアを実施すると（ステップＳ１２２）、ステップＳ１１４に戻って、第二処理部１１２が、親子定義を取得し、再度ルール参照マージ処理を実行する。なお、関係処理部１１３による親子定義見直し後に、ステップＳ１１７のマージ処理判定で再びマージエラーが再度発生した場合には、親子定義見直し処理が何度も繰り返されるのを防止するため、その他エラーとして、エラーコード生成（ステップＳ１１８）とログ作成（Ｓ１０７）がされる。 If the merge command error is determined as a result of re-merge processing determination, parent-child definition review processing (steps S119 to S122) is performed by the relationship processing unit 113 . When a merge command error occurs, the relationship processing unit 113 first creates a branch for testing in the application source code repository 121 (step S119), and executes a parent-child relationship investigation script between the program and the module on the synchronization source server. (step S120). The script executed here compiles the program one by one in the test branch, and recursively verifies whether the generated module matches the module in the workspace 117 (obtained in step S111, etc.). It is. If they do not match, the parent-child relationship between the program and the module is wrong, so replace with another program and check if the module matches, and investigate the correct parent-child relationship. Next, the relationship processing unit 113 overwrites the parent-child definition 116 stored in the management terminal storage unit 114 with the execution result of the script (step S121). At this time, the script to be executed compiles a single program in the synchronization source environment, verifies whether the generated module matches the workspace 117, and executes it recursively for all programs. shall be Thereafter, the relationship processing unit 113 refers to the environment information of the IaC code repository 122 and the application source code repository 121, and restores the synchronization source environment (step S122). , get the parent-child definition and execute the rule reference merge process again. After the parent-child definition is reviewed by the relationship processing unit 113, if a merge error occurs again in the merge processing determination in step S117, in order to prevent the parent-child definition review processing from being repeated many times, other errors are as follows: An error code is generated (step S118) and a log is created (S107).

マージ処理判定で処理が成功したと判定された場合は、プログラムの登録処理（ステップＳ１０５）及びIaCリポジトリの処理更新（ステップＳ１２３）が実行され、リポジトリ内同期元のプログラム改修が同期先環境へ反映される（ステップＳ１２４）。マージ処理判定でその他のエラーが発生した場合は、エラーログが生成されるため、ログを調査し、原因を取り除いた上で再実行することにより、同期元のプログラム改修が同期先環境へ反映される。 If it is determined that the merge process has succeeded, the program registration process (step S105) and the IaC repository process update (step S123) are executed, and the synchronization source program modification in the repository is reflected in the synchronization destination environment. (step S124). If any other error occurs in the merge process judgment, an error log will be generated. By investigating the log, removing the cause, and re-executing, the synchronization source program modification will be reflected in the synchronization destination environment. be.

＜データ構成＞
図８は、開発支援サーバ１００の管理端末装置１１０の管理端末記憶部１１４上に保持される親子定義１１６のデータ構成と具体的なデータの例について概要を示した図である。親子定義１１６は、プログラムとモジュールの関係性についての情報などを保持するテーブルであり、例えば、SRC、MODULなどの各項目を有している。この親子定義１１６は、別環境への反映時に図７におけるステップＳ１１４の親子定義取得処理にて第二処理部１１２に取り込まれ、図７におけるステップＳ１１５の関係プログラム差分棄却処理のインプットとして活用される。また、図７におけるステップＳ１２１の親子定義更新処理にて、SRC及びMODULの各項目が関係処理部１１３によって更新され、更新された親子定義１１６が、前述の親子定義取得処理にて第二処理部１１２に再度取り込まれて、関係プログラム差分棄却処理のインプットとして活用される。 <Data structure>
FIG. 8 is a diagram showing an overview of the data structure of the parent-child definition 116 held in the management terminal storage unit 114 of the management terminal device 110 of the development support server 100 and an example of specific data. The parent-child definition 116 is a table that holds information about the relationship between programs and modules, and has items such as SRC and MODUL, for example. This parent-child definition 116 is taken into the second processing unit 112 in the parent-child definition acquisition process of step S114 in FIG. 7 when reflected to another environment, and is used as an input for the related program difference rejection process of step S115 in FIG. . Also, in the parent-child definition update processing of step S121 in FIG. 7, the items of SRC and MODUL are updated by the relationship processing unit 113, and the updated parent-child definition 116 is transferred to the second processing unit in the above-described parent-child definition acquisition processing. 112 and utilized as an input for the related program difference rejection process.

図９は、開発支援サーバ１００の開発支援サーバリポジトリ１２０のアプリソースコードリポジトリ１２１上に保持されるコミット履歴テーブル１２４のデータ構成と具体的なデータの例について概要を示した図である。コミット履歴テーブル１２４は、プログラム及びモジュールが更新された際のバージョンや更新されたブランチに加え、更新者や更新日付及び登録処理状況についての情報などを保持するテーブルであり、例えば、VER、PREVER、SRCVER、ID、IP、DATE及びSTATUSなどの各項目を有している。このコミット履歴テーブル１２４は、サーバ内開発を実施する際、図６におけるステップＳ０２のプログラムの登録及びステップＳ０３のモジュールの登録時に、VERなどのバージョン情報、BRANAMEなどのブランチ情報を明記した新たなレコードが生成され、更新に関するIDやDATE、処理結果のSTATUSに加えて更新環境のIPなどの情報も明記される。また、レコード生成時には後述する図１０に示す環境バージョン管理テーブル１２５も参照され、コミット履歴テーブル１２４のレコードのIPに対応したバージョン情報（VER）が、図９に示すコミット履歴テーブル１２４のPREVERとして更新される。この処理により、前世代のバージョンが新規バージョンと同レコードに明記されるため、障害発生時の切り戻し先が明確になり、リカバリ工数を抑制できる。また、別環境に反映する際には、図７におけるステップＳ１２４の環境反映処理のインプットとして、後述する図１０で保持しているバージョン情報（VERなど）と関連するBRANAMEなどのブランチ情報が活用されている。 FIG. 9 is a diagram showing an overview of the data structure of the commit history table 124 held on the application source code repository 121 of the development support server repository 120 of the development support server 100 and an example of specific data. The commit history table 124 is a table that holds information such as the updater, update date, and registration processing status, in addition to the versions and updated branches when programs and modules are updated. It has items such as SRCVER, ID, IP, DATE and STATUS. This commit history table 124 creates a new record specifying version information such as VER and branch information such as BRANAME at the time of program registration in step S02 and module registration in step S03 in FIG. is generated, and information such as the IP of the update environment is specified in addition to the ID and DATE related to the update and the STATUS of the processing result. Also, when generating a record, the environment version management table 125 shown in FIG. 10, which will be described later, is also referenced, and the version information (VER) corresponding to the IP of the record in the commit history table 124 is updated as PREVER in the commit history table 124 shown in FIG. be done. With this process, the previous generation version and the new version are specified in the same record, so the switchback destination in the event of a failure becomes clear, and the number of man-hours required for recovery can be reduced. Also, when reflecting to another environment, version information (such as VER) and branch information such as BRANAME related to the version information (such as VER) held in FIG. ing.

図１０は、開発支援サーバ１００の開発支援サーバリポジトリ１２０のIaCコードリポジトリ１２２上に保持される環境バージョン管理テーブル１２５のデータ構成と具体的なデータの例について概要を示した図である。環境バージョン管理テーブル１２５は、各サーバ環境に格納され稼働しているモジュールの最新のバージョン及び各サーバのIPやDBIDなど環境情報を含む情報を保持するテーブルであり、例えば、IP、SVRNAME、DBID、MODE、VER及びDATEなどの各項目を有している。この環境バージョン管理テーブル１２５は、サーバ内開発を実施する際、図６におけるステップＳ０４のIaCリポジトリの更新時に対象環境のIPのレコードにあるVERなどのバージョン情報や、DATEといった更新日時が更新される。また、別環境に反映する際にも、前述のIaCリポジトリの更新が実施され、図７におけるステップＳ１２４の環境反映処理に活用される。 FIG. 10 is a diagram showing an overview of the data structure of the environment version management table 125 held on the IaC code repository 122 of the development support server repository 120 of the development support server 100 and an example of specific data. The environment version management table 125 is a table that holds information including environment information such as the latest versions of modules stored and running in each server environment and the IP and DBID of each server. It has items such as MODE, VER and DATE. In this environment version management table 125, version information such as VER in the IP record of the target environment and update date and time such as DATE are updated when the IaC repository is updated in step S04 in FIG. . Also, when reflecting to another environment, the above-mentioned IaC repository is updated and utilized for the environment reflecting process in step S124 in FIG.

図１１は、開発支援サーバ１００の開発支援サーバリポジトリ１２０のアプリソースコードリポジトリ１２１上に保持されるユーザマスタテーブル１２６のデータ構成と具体的なデータの例について概要を示した図である。ユーザマスタテーブル１２６は、プログラムが更新された際の担当者や担当者の持つ権限についての情報などを保持するテーブルであり、例えば、ID、ID_NAME、PERMISSIONなどの各項目を有している。このユーザマスタテーブル１２６は、サーバ内開発を実施する際、図６におけるステップＳ０２のプログラム登録時に、インプットとして活用される。また、別環境に反映する際にも、図７におけるステップＳ１０４等のマージ処理判定のインプットとして、権限が足りない場合はステップＳ１０６等のエラーコードの生成へと分岐させる処理の判断元として活用される。 FIG. 11 is a diagram showing an overview of the data structure of the user master table 126 held on the application source code repository 121 of the development support server repository 120 of the development support server 100 and an example of specific data. The user master table 126 is a table that holds information about the person in charge when the program is updated and the authority of the person in charge, and has items such as ID, ID_NAME, and PERMISSION, for example. This user master table 126 is utilized as an input during program registration in step S02 in FIG. 6 when executing development within the server. Also, when reflecting in another environment, it is used as an input for determining merge processing in step S104 in FIG. be.

図１２は、開発支援サーバ１００の開発支援サーバリポジトリ１２０のアプリソースコードリポジトリ１２１上に保持されるブランチ管理テーブル１２７のデータ構成と具体的なデータの例について概要を示した図である。ブランチ管理テーブル１２７は、プログラムが更新された際のブランチの最新バージョンや更新日についての情報などを保持するテーブルであり、例えば、BRANAME、HEAD、DATEなどの各項目を有している。このブランチ管理テーブル１２７は、サーバ内開発を実施する際、図６におけるステップＳ０２のプログラム登録時に更新対象のBRANAMEのレコードにある最新のバージョン情報をHEADとして更新し、更新日時を表すDATEを同時に更新する。また、別環境に反映する際にも、図６におけるステップ０２のプログラム登録が実施され、図７におけるステップＳ１２４の環境反映処理に活用される。 FIG. 12 is a diagram showing an overview of the data configuration of the branch management table 127 held on the application source code repository 121 of the development support server repository 120 of the development support server 100 and an example of specific data. The branch management table 127 is a table that holds information such as the latest version and update date of the branch when the program is updated, and has items such as BRANAME, HEAD, and DATE, for example. This branch management table 127 updates HEAD with the latest version information in the record of BRANAME to be updated at the time of program registration in step S02 in FIG. do. Also, when reflecting in another environment, the program registration in step 02 in FIG. 6 is performed, and is utilized in the environment reflection processing in step S124 in FIG.

１ 開発支援システム
１００ 開発支援サーバ
１１０ 管理端末装置
１１１ 第一処理部
１１２ 第二処理部
１１３ 関係処理部
１１４ 管理端末記憶部
１１５ マージルール
１１６ 親子定義
１１７ ワークスペース
１１８ 差分結果
１２０ 開発支援サーバリポジトリ
１２１ アプリソースコードリポジトリ
１２２ IaCコードリポジトリ
１２３ モジュールバックアップリポジトリ
１２４ コミット履歴テーブル
１２５ 環境バージョン管理テーブル
１２６ ユーザマスタテーブル
１２７ ブランチ管理テーブル
２００ 開発用サーバ
２０１ モジュール
２０２ コンパイラ
２０３ プログラム
２０４ プログラム
２０５ モジュール
２１０ 顧客検証用サーバ
３００ 開発用クライアント
４０１ マスタブランチ
４０２ 顧客検証用ブランチ
４０３ 環境Ａ用ブランチ
４０４ 環境Ｂ用ブランチ 1 Development support system 100 Development support server 110 Management terminal device 111 First processing unit 112 Second processing unit 113 Relationship processing unit 114 Management terminal storage unit 115 Merge rule 116 Parent-child definition 117 Workspace 118 Difference result 120 Development support server repository 121 Application Source code repository 122 IaC code repository 123 Module backup repository 124 Commit history table 125 Environment version management table 126 User master table 127 Branch management table 200 Development server 201 Module 202 Compiler 203 Program 204 Program 205 Module 210 Customer verification server 300 For development Client 401 Master branch 402 Customer verification branch 403 Environment A branch 404 Environment B branch

Claims (5)

複数の開発者によるサーバ内におけるプログラムの開発作業を管理するプログラム管理装置において、
前記複数の開発者がそれぞれ開発したプログラムと、検証環境に格納されている現在のプログラムとの差分であるプログラム差分を抽出する第一処理部と、
前記プログラム差分に応じたマージ処理のルールが予め定められたマージルールを有する記憶部と、
前記複数の開発者がそれぞれ開発したモジュールと、検証環境に格納されている現在のモジュールとの差分であるモジュール差分を抽出する第二処理部と、
を備え、
前記第二処理部は、前記モジュール差分が抽出されない場合、前記プログラム差分を棄却し、前記マージルールを参照して、前記開発したプログラムと前記現在のプログラムとをマージ処理することで前記検証環境のプログラムを更新することを特徴とするプログラム管理装置。 In a program management device that manages program development work in a server by a plurality of developers,
a first processing unit for extracting a program difference, which is a difference between a program developed by each of the plurality of developers and a current program stored in a verification environment;
a storage unit having a merge rule in which a merge process rule corresponding to the program difference is predetermined;
a second processing unit for extracting a module difference, which is a difference between the module developed by each of the plurality of developers and the current module stored in the verification environment;
with
When the module difference is not extracted, the second processing unit discards the program difference, refers to the merge rule, and merges the developed program and the current program to create the verification environment. A program management device characterized by updating a program. 請求項１に記載のプログラム管理装置において、
前記モジュール差分が抽出され、かつ、前記プログラム差分が抽出されなかった場合、モジュールとプログラムの関係を調査し、前記記憶部が有するモジュールとプログラムの親子定義を更新する関係処理部、を更に備えたことを特徴とするプログラム管理装置。 In the program management device according to claim 1,
a relationship processing unit that, when the module difference is extracted and the program difference is not extracted, investigates the relationship between the module and the program, and updates the parent-child definition of the module and the program stored in the storage unit. A program management device characterized by: 請求項２に記載のプログラム管理装置において、
前記関係処理部は、テスト用のブランチでプログラムをコンパイルして生成されたモジュールが、前記開発したモジュールと合致するかを再帰的に検証し、合致した場合のモジュールとプログラムの関係に基づいて、前記親子定義を更新することを特徴とするプログラム管理装置。 In the program management device according to claim 2,
The relationship processing unit recursively verifies whether the module generated by compiling the program in the test branch matches the developed module, and based on the relationship between the module and the program when they match, A program management device, wherein the parent-child definition is updated. 請求項１に記載のプログラム管理装置において、
プログラム及びモジュールが更新された際の、新規のバージョン、前世代のバージョン、更新対象のサーバ環境のＩＰ、が同一レコードで明記されたコミット履歴テーブルと、
各サーバ環境のＩＰ、各サーバ環境に格納され稼働している最新のバージョンと、を含む情報を保持するバージョン管理テーブルと、を更に備えたことを特徴とするプログラム管理装置。 In the program management device according to claim 1,
a commit history table in which the new version, the previous generation version, and the IP of the server environment to be updated are specified in the same record when the program and module are updated;
A program management apparatus, further comprising: a version management table holding information including an IP of each server environment and the latest version stored and running in each server environment. 複数の開発者によるサーバ内におけるプログラムの開発作業を管理するプログラム管理方法において、
前記複数の開発者がそれぞれ開発したプログラムと、検証環境に格納されている現在のプログラムとの差分であるプログラム差分を抽出するステップと、
前記複数の開発者がそれぞれ開発したモジュールと、検証環境に格納されている現在のモジュールとの差分であるモジュール差分を抽出するステップと、
前記モジュール差分が抽出されない場合、前記プログラム差分を棄却するステップと、
前記プログラム差分に応じたマージ処理のルールを参照して、前記開発したプログラムと前記現在のプログラムとをマージ処理するステップと、
を備えたことを特徴とするプログラム管理方法。 In a program management method for managing program development work in a server by a plurality of developers,
a step of extracting a program difference, which is a difference between a program developed by each of the plurality of developers and a current program stored in a verification environment;
a step of extracting a module difference, which is a difference between a module developed by each of the plurality of developers and a current module stored in a verification environment;
if the module difference is not extracted, rejecting the program difference;
a step of merging the developed program and the current program with reference to a merge processing rule according to the program difference;
A program management method comprising:

Images