JP2014063352A - Program development integrated management system - Google Patents

Abstract

PROBLEM TO BE SOLVED: To use the same source code in a plurality of system environments, manage modules created in the system environments in a library, and properly distribute or release them to a corresponding system environment.SOLUTION: A program development integrated management system includes: a management table in library 10, which holds a management object specification information including a system environment of application object, a server type in the location, a path in the location, and a file name of the management object for each object to be managed; a module management part 17 which checks out the same source code from the library 10 for a development environment 2 of application object, on the basis of the management object specification information, and checks in a generated execution module to the library 10 for each system environment, to update the management table; and a release part 19 which releases the execution module generated in each development environment 2 to performance execution environments 4 having corresponding system environment.

Description

  The present invention relates to a management technique for source code and modules in the development of application programs, and more particularly to a technique effective when applied to a program development integrated management system that manages libraries and releases in a plurality of types of system environments. .

  In software development for information processing systems and application programs, especially large-scale software development, the number of source codes and modules, the number of developers, etc. are large, and the management load increases, so the version of source code and modules A mechanism for supporting so-called library management including management and release management to a production environment as an information processing system has been studied and proposed.

  As a technology related to library management, in addition to products provided by each vendor, for example, Japanese Patent Laid-Open No. 11-110195 (Patent Document 1) describes a check-in request for a source file by a registration request command. Asks the person in charge for integrity verification, and for the authentication request by the source file reference request command, the latest version of the source file whose integrity with the other source file has been certified by the person in charge by the authentication command. A version number management system that controls to pass from the group is described. As a result, it is possible to avoid a failure due to a mismatch between source files when a change occurs after each developer individually checks in the source file.

  Further, as a technology related to release management, for example, Japanese Patent Application Laid-Open No. 2009-244974 (Patent Document 2) discloses 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. A program having a directory generation unit that references a table, extracts a program having the same release condition as one release unit, generates a release unit directory in the release storage area, and stores the extracted release unit program in the directory. A development management device is described. This makes it possible to manage programs according to release conditions, such as forgetting to release some of the programs to be released, or releasing a program that is a release target and a program that is not a release target. Can be prevented.

  In addition, for example, in Japanese Patent Application Laid-Open No. 2011-59847 (Patent Document 3), a network-connected storage including a storage device and a control unit partitioned into a development side area and a production side area, a developer terminal, and an approver A release management system including a terminal, a librarian terminal, a release terminal, a production machine, a transfer server, and a release server is described. Here, based on the command input from the librarian terminal, the transfer server issues a command for transferring a specific program stored in the development side area to the production side area, and the release server from the release terminal. Based on the command input, a command for acquiring the program stored in the production-side area is issued to the control unit, and the acquired program is transferred to the production machine. This makes it possible to effectively prevent unauthorized release by a malicious developer while entrusting the final release operation to the developer.

JP-A-11-110195 JP 2009-244974 A JP 2011-59847 A

  In recent years, companies have been considering standardizing business processing provided by information processing systems within the industry, etc. from the viewpoint of efficiency and cost reduction in the construction and operation of information processing systems, and convenience for customers. May be. In such a situation, for example, from the form that each company develops and operates an information processing system independently, a plurality of similar companies in the industry can share the same or similar information processing system, It is possible to provide standardized business processing with only minor customizations, such as by developing and operating application programs, or by IT vendors developing such systems and applications and providing them as services. May be.

  In order to construct such an information processing system and application program, for example, the source code is unified, and the same module generated from the source code is released and executed in each company's own environment. The method can be considered. However, in this case, it is assumed that each company's own system environment is the same or compatible at the platform level such as OS (Operating System) and middleware, so there are many companies (system environments) to apply. It will be difficult to achieve such unification.

  When the number of companies (system environments) that build information processing systems and application programs with the same or similar programs increases, for example, there are different versions of platforms due to differences in hardware and software replacement cycles between system environments. A mixed case may occur. On the other hand, it is also possible to adopt a configuration in which unified source code is individually built in each system environment (development environment), an execution module is generated, and released to each production environment.

  At this time, although there is only one source code in terms of library management, this is checked out for each different development environment, individually built in each development environment, created, and then checked in. Become. Each checked-in module is generated from the same source code, so the appearance of the file name and the like is the same, but the contents at the binary level are different.

  The modules generated in this way are managed to be properly distributed and released to the corresponding system environment (test environment, production environment), and access control is performed so that only users belonging to the corresponding system environment can access. Although there is a need to do this, the conventional library management and release management mechanisms are not intended for management and control in such an environment. In addition, the system linkage between the library management mechanism for the source code at the time of development and the mechanism such as process management of the development project and release management of the generated module will be fully considered. Not.

  Therefore, an object of the present invention is to use the same source code in a plurality of system environments, manage a module created in each system environment together with the source code in a library, and a system corresponding to each module to be managed An object is to provide a program development integrated management system that can be appropriately distributed or released to the environment.

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

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

  In the program development integrated management system according to the representative embodiment of the present invention, an execution module to be released for a production environment composed of a plurality of types of system environments is created in a development environment having a corresponding system environment. , A program development integrated management system that performs library management for a managed property that is a source code or a related file or the generated execution module, and release management of the execution module for the production environment, and has the following features Is.

  That is, the program development integrated management system, in the library for managing each managed property, the system environment to be applied to each managed property, the server type of the location, the path of the location, and the file name of the managed property Based on the contents of the management property specifying information in the management table and the management table holding the management property specifying information including each information, the same source code from the library is checked against each development environment to be applied Module management unit that updates the management table by checking the execution module generated from the source code in the development environment into the library for each system environment, and generated in each development environment Before the execution module has a corresponding system environment It is characterized in that it has a production release unit which respectively release into production.

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

  That is, according to the representative embodiment of the present invention, the same source code is used in a plurality of system environments, and the modules created in each system environment are managed in the library together with the source code, Each managed module can be appropriately distributed or released to the corresponding system environment.

It is the figure which showed the outline | summary about the structural example of the program development integrated management system which is one embodiment of this invention. It is the figure which showed the outline | summary about the example of the process at the time of creating the module each corresponding to several system environment from the same source code in one embodiment of this invention. It is the figure which showed the outline | summary about the example of the data structure of the table which hold | maintains management information in the library in one embodiment of this invention. It is the figure which showed the outline | summary about the example of unification of the source code etc. in the some system environment in one embodiment of this invention. It is the figure which showed the outline | summary of the process about the example of unification of a source code etc. in the some system environment in one embodiment of this invention. It is the figure which showed the outline | summary about the example of the process at the time of creating the module each corresponding to several system environment in a prior art. It is the figure which showed the outline | summary about the example of the process at the time of creating the module each corresponding to several system environment from the same source code in a prior art.

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

<Overview>
For example, when IT vendors construct and provide a system environment that provides similar business processing to multiple companies, etc., in order to cope with differences in requirements and specifications in each company, conventionally, individual It was common to create a source code to maintain independence.

  FIG. 6 is a diagram showing an overview of an example of processing when creating modules respectively corresponding to a plurality of system environments in the prior art. In the example of FIG. 6, first, from the library 10 that holds and manages source code, execution modules, etc., the target source code 21 and related files such as Makefile (not shown) are transferred to each development environment 2 (FIG. 6) of the target company. In this example, the development environments A (2A) to C (2C) are each checked out (in the case of new development, a new creation is made).

  In each development environment 2, the execution module 22 is processed by compiling and linking in accordance with a predetermined procedure from the source code 21 (in the example of FIG. 6, source code A (21A) to C (21C)) using Makefile or the like. (Execution modules A (22A) to C (22C) in the example of FIG. 6) are generated (built). Thereafter, a unit test, a connection test, and the like are performed, and when completed, the updated source code 21, the related file, the execution module 22, and the like are checked into the library 10 (not shown).

  Thereafter, the execution module 22 generated in the corresponding development environment 2 is applied in a test environment (not shown) corresponding to each of the plurality of production environments 4 (production environments A (4A) to C (4C) in the example of FIG. 6). Then, after performing a comprehensive test or the like, the execution module 22 is released to each corresponding production environment 4. In such a method, it is possible to flexibly cope with differences in requirements and specifications in each system environment, but it is necessary to hold a plurality of types of source code 21 in a form corresponding to each system environment. In addition, the maintenance cost for maintaining and managing a plurality of types of source code 21 for the same function, and the risk of failure induction due to the omission of reflection of development, etc., increase.

  Therefore, as described above, for example, in order to improve the efficiency of development and maintenance, reduce costs, and to provide business processing standardized in the industry in a plurality of system environments, the source code 21 is unified, A method of generating execution modules 22 corresponding to a plurality of system environments and releasing them to each system environment can be considered.

  FIG. 7 is a diagram showing an outline of an example of processing in creating a module corresponding to each of a plurality of system environments from the same source code in the prior art. In the example of FIG. 7, first, the target source code 21 and related files such as Makefile (not shown) are checked out from the development environment 2 from the library 10 (in the case of new development, new files are created). In the development environment 2, the execution module 22 is generated (built) by performing processing such as compiling and linking in accordance with a predetermined procedure from the source code 21 using Makefile or the like. Thereafter, a unit test, a connection test, and the like are performed, and when completed, the updated source code 21, the related file, the execution module 22, and the like are checked into the library 10 (not shown).

  Thereafter, as in the example of FIG. 6, the test environment is generated in the development environment 2 in a test environment (not shown) corresponding to each of the plurality of production environments 4 (production environments A (4A) to C (4C) in the example of FIG. 7). The execution module 22 is applied to perform a comprehensive test and then the execution module 22 is released to each production environment 4. As described above, in such a method, since the same execution module 22 is copied to each production environment 4, the system environment of each production environment 4 is the same or compatible. This is a prerequisite. However, it is actually difficult to unify such a system environment.

  Therefore, in the integrated program development management system according to the embodiment of the present invention, the same integrated source code 21 is individually built in the development environment 2 corresponding to each system environment to generate the execution module 22. In addition, the configuration is such that each is released to the corresponding production environment 4.

  FIG. 2 is a diagram schematically showing an example of processing when creating modules respectively corresponding to a plurality of system environments from the same source code in the present embodiment. In the example of FIG. 2, first, from the library 10, an associated source code 21 or a related file such as Makefile (not shown) may be different depending on each development environment 2. Check out each of the development environments A (2A) to C (2C)) (in the case of new development, create a new one).

  In each development environment 2, the execution module 22 (execution modules A (22A) to C (22C in the example of FIG. 2) is performed by performing processing such as compiling and linking in accordance with a predetermined procedure using Makefile or the like from the same source code 21. )) Is generated (built). Here, although the source code 21 is the same, the execution modules 22A to 22B generated as a result of being individually built in the development environments 2A to 2C having different platforms such as the OS have the same appearances such as file names, but are binary. Different levels are generated.

  Thereafter, a unit test, a connection test, and the like are performed. When completed, the updated source code 21, related files, execution module 22, and the like are checked into the library 10. In terms of management in the library 10, the source code 21 is managed as being the same independent of the system environment, but the execution module 22 is managed as being different for each system environment. In addition, since the source code 21 is unified between different system environments, when it is necessary to realize different processing between the system environments, for example, the code or instruction described in the source code 21 or Makefile is executed. Sometimes it takes a method to acquire information (for example, environment variables etc.) for identifying the system environment in which it operates, and to write codes, instructions, etc. so as to distribute the processing contents according to the contents it can.

  With such a configuration, the same source code 21 is provided to a plurality of system environments, and in each system environment, an execution module 22 suitable for the system environment is generated, and the generated execution module 22 is stored in the source code. 21 can be managed by the library 10 together.

<System configuration>
FIG. 1 is a diagram showing an outline of a configuration example of a program development integrated management system according to an embodiment of the present invention. The program development integrated management system 1 is a system that supports the development and maintenance of application programs for providing standardized business processes to companies and the like, for example, information on PCs (Personal Computers), server devices, and the like. A librarian terminal 5 that is an information processing apparatus used by a librarian that manages a library 10 via a closed network 7 such as an in-house LAN (Local Area Network), etc., and is used by a developer or the like. The user terminal 6 which is an information processing apparatus to be connected is connected.

  Further, it is possible to connect to a device such as a server that deploys the execution module 22 in the development environment 2, the test environment 3, and the production environment 4 via individual networks, relay servers, and the like (not shown). Note that, as described above, a plurality of types of these environments can exist depending on the system environment of the company or the like to be used.

  The program development integrated management system 1 includes, for example, a user management unit 11, a theme management unit 12, a process management unit 13, an operation management unit 14, a user interface unit 15, a repository management unit 16, a module management unit 17, which are implemented by software. Each unit includes a test environment distribution unit 18 and a production release unit 19. In addition, it has a library 10 as a repository made up of a database and files that hold and manage the source code 21, related files, execution modules 22, and the like.

  The user management unit 11 has a function of managing information about users (librarians, developers, etc.) who access the program development integrated management system 1. This includes, for example, account information management for each user and group linked with an in-house system, user authentication, information linkage function between groups and teams, and the like.

  The theme management unit 12 has a function of individually managing application program development items (themes). For example, when starting a development project, information such as the specification of the source code 21 managed as the library 10 and the like related to the theme is combined with the specification of the function and service of the target application program. In response, this is registered as a theme in a database (not shown). Moreover, it is possible to assign a developer, a group, or the like who performs work on the target theme, the subsystems, functions, source code 21 included therein, and the like. Thereby, as described later, at the time of development work or release, it is possible to perform access control such as specifying the source code 21 and the execution module 22 corresponding to each theme and making them accessible only.

  The process management unit 13 has a function of realizing a business flow related to project management in each development process for a project (theme) under development and adjusting the development process among a plurality of system environments. The processing in each development process includes, for example, progress management, event management such as review execution, release approval process, and the like. In addition, in order to unify and manage the source code 21 in a unified manner, for example, processes such as management of parallel development for a plurality of system environments and adjustment of release timing are included. For sharing information and transferring processes among a plurality of developers, for example, a mechanism such as a known groupware can be applied.

  The operation management unit 14 has a function of managing the overall operation of the program development integrated management system 1. For example, a function for registering and updating data used on the program development integrated management system 1 and a management function for execution of a program executed periodically or at a predetermined timing are included.

  The user interface unit 15 has a function of providing a user interface for referring to information and performing various operations on the librarian terminal 5 and the user terminal 6 that access the program development integrated management system 1. For example, a web server program (not shown) is provided, and the user can access each function of the program development integrated management system 1 via a web browser (not shown) on the librarian terminal 5 or the user terminal 6.

  The repository management unit 16 has a repository management function for the library 10. For example, using a known technique, a function for performing high-speed backup, efficient access, and the like assuming that the library 10 is enlarged is included. The repositories include, for example, a development repository that manages deliverables at the development stage and a production repository that manages objects to be released to the production environment.

  The module management unit 17 has a module management function in the development environment 2 such as check-out / check-in processing of the source code 21 and the execution module 22 for the library 10 from each development environment 2. As shown in FIG. 2, as a general rule, the same source code 21 can be checked out for all of the plurality of development environments 2, and each development environment is based on the source code 21 and the like. 2, each execution module 22 is built / generated. There may be source code 21 or the like that is checked out only in a specific development environment 2.

  In this embodiment, when the user (developer) of each development environment 2 tries to check out / check in the source code 21 or the like, the module management unit 17 checks out the source code 21 or the like. / Access control is performed to determine whether the user has the authority to check in. Here, for example, as access control based on the target source code 21 or the like, it is determined whether or not the source code 21 or the like is related to a theme under development registered by the theme management unit 12.

  Further, as access control based on the target user, whether or not the user is assigned as the target theme or the target object (for example, subsystem or function, source code 21), or a developer in the target development environment 2 It is determined. Accordingly, it is possible to allow the user to check out / check in only the source code 21 or the like that can be accessed by the user. In each development environment 2, the user (developer) modifies the source code 21 checked out from the library 10 via the user terminal 6, etc., builds based on Makefile etc., and executes the execution module 22. Generate. Further, a unit test or a connection test of the generated execution module 22 is performed, and the completed source code 21 or the like is checked into the library 10.

  For the development work in the development environment 2, the test execution in the test environment 3 to be described later, and the release work in the production environment 4, the contents of the execution are recorded as log data in a database (not shown). As a result, these data can be used as trail information at the time of auditing or the like, and can also be used as performance data when performing management by the process management unit 13.

  The test environment distribution unit 18 has a function of distributing the execution module 22 and related files generated in each development environment 2 to the corresponding test environment 3. Here, for example, when the user designates an item (theme) to be distributed, a distribution date or day of the week, and a test environment 3 (or a server) as a distribution destination, the test environment distribution unit 18 enters the predetermined area. An execution module 22 or the like to be distributed can be arranged and distributed automatically.

  It should be noted that access control can be performed in the same manner as the module management unit 17 for paying out the distribution target execution module 22 or the like from the library 10 or distributing it to the test environment 3. Similarly to the release to the production environment 4 which will be described later, only those that have undergone the approval process in the process management unit 13 may be distributed. In each test environment 3, based on the execution module 22 distributed via the test environment distribution unit 18, a comprehensive test for the entire system and a test for connection between subsystems are performed.

  The production release unit 19 has a function of releasing the execution module 22 and related files that have been tested in each test environment to the corresponding production environment 4. Here, for example, for a matter (theme) that has undergone an approval process by a predetermined manager in the process management unit 13, only a specific librarian that manages the release to the production environment 4 has the theme and the release date, day of the week, etc. Specify the release-target production environment 4 (or server, etc.). As a result, as in the prior art, the production release unit 19 can place the release target execution module 22 or the like in a predetermined area such as a relay server (not shown) and automatically release it.

  In this way, by separating the responsibility and authority of the developer and the person in charge (specific librarian) who performs the release to the production environment 4 in a systematic manner, security can be ensured and internal control can be achieved. It is desirable that not only the release to the production environment 4 but also the distribution to the test environment 3 and the check-out / check-in from the development environment 2 be performed via a specific librarian.

<Data structure>
FIG. 3 is a diagram showing an outline of an example of a data structure of a table that holds management information in the library 10. The management table 10a is a table that holds management information about managed properties such as the source code 21 and the execution module 22 managed by the library 10, and includes, for example, a subsystem ID, a managed property specifying key, a managed property ID, and a managed property. It has items such as name, distribution destination system, distribution destination environment, and distribution destination server. The key item is a composite key of a managed property specifying key and a managed property ID.

  The item of subsystem ID holds ID information for identifying the subsystem in the application program to which the target managed property (source code 21 or the like) belongs. The item of the managed property specifying key holds information for identifying the location of the target managed property and the system environment information to be applied. For example, in the data “CMN: MAKE / src / bt / main” in the first entry, the system environment to be applied is “CMN” indicating that the system environment can be commonly applied to a plurality of system environments. This indicates that the server type is “MAKE” and the location path is “/ src / bt / main”. In the data “EnvA: DB / MAKE / src” in the next entry, “EnvA” indicating that the system environment to be applied is “environment A”, the server type of the location is “DB”, and the location This indicates that the location path is “/ MAKE / src”.

  The item of managed property ID holds information of an ID (file name in the present embodiment) for identifying the target managed property. In the present embodiment, as described above, since the source code 21 and the like are common in each system environment, the appearance (file name) of the execution module 22 that is built and generated is different at the binary level. It will be the same. Therefore, in the example of FIG. 3, for convenience of explanation, the file name is surrounded by a figure of a different type depending on the type of system environment to be applied (specified in the item of the managed property specifying key described above). Even if the name is the same, the entity is different. The managed property name item holds wording information that briefly explains the content of the managed property, such as the name of the target managed property.

  Of the above items, the three items of the subsystem ID, the managed property specifying key, and the managed property ID have significance as managed property specifying information that can uniquely specify the managed property. Therefore, even if the managed property ID (file name) is the same for the execution modules 22 having different entities at the binary level, it is possible to grasp that the managed property specifying information is different.

  The item of the distribution destination system holds information indicating a system environment that is a target of distribution to the test environment 3 or release to the production environment 4. Therefore, the data is set / held only for the execution module 22 or the like to be distributed or released. In the example of FIG. 3, for the execution module 22 (“ABC100.exe” in the third entry) for “environment A”, “EnvA” indicating “environment A” and “EnvC” indicating “environment C”. "Is set (that is, in" environment C ", the execution module 22 similar to" environment A "can operate). In addition, “EnvB” indicating “Environment B” is set for the execution module 22 (“ABC100.exe” of the fifth entry) for “Environment B”.

  The item of distribution destination environment holds information on the target operation environment when there are a plurality of types of operation environments in the system environment of the distribution destination of the target managed property. For example, in the example of FIG. 3, when the access destination operating environment differs depending on whether the access day is a weekday or a holiday, the target managed property is a weekday operation environment and a holiday operation environment. This indicates that information on which (or both) of the information is distributed is set. The item of distribution destination server holds information of a distribution destination server (logical server or physical server) of the target managed property.

  Note that the above three items of the distribution destination system, distribution destination environment, and distribution destination server have significance as distribution-related information related to the control when distributing the managed property to the test environment 3 and the production environment 4. . These pieces of information are set / approved by, for example, a release approval process by the process management unit 13, adjustment processing between themes, and the like, and the test environment distribution unit 18 and the production release unit 19 distribute / It becomes possible to automatically control the release destination.

  The data configuration (items) of the table shown in FIG. 3 is merely an example, and other table configurations and data configurations may be used as long as similar data can be held and managed. For example, the distribution related information may further include information such as a release date and a date scheduled to be reflected in the production repository so that the timing of distribution and release to each system environment can be controlled.

<Unification method of source code>
FIG. 4 is a diagram showing an outline of an example of unification of the source code 21 and the like in a plurality of system environments in the present embodiment. For development projects (themes) registered via the theme management unit 12, a developer or other user uses the user terminal 6 to manage the development item with respect to the librarian via the user management unit 11 or the process management unit 13. When a request for updating (modifying or newly adding) a certain source code 21 (“ABC100.cbl”) is made, the librarian performs update registration for the target managed property via the module management unit 17 by the librarian terminal 5. Do.

  At this time, the theme management unit 12 or the like has the authority to access the target managed property as a developer of the target theme as to whether the target managed property is included in the target theme. Access control may be performed to determine whether or not the target managed property is accessible by determining whether or not the target user has the authority to perform development work in the target system environment.

  The module management unit 17 generates a source code 21 (“ABC100.cbl”) that is a management property designated by the user and a file (Makefile (“ABC100.mk”) related to this in the target theme, The execution module 22 (“ABC100.exe”) is checked out to the target development environment 2 based on the contents of the management table 10a shown in FIG.

  In the example of FIG. 4, since the payout is made to the development environments A (2A) and B (2B), the management environment 10a is referred to, and the development environment A (2A) has the source code 21 (common to each system environment). “ABC100.cbl”), Makefile (“ABC100.mk”) and development module 22 (“ABC100.exe”) for development environment A (2A) are issued, and development environment B (2B) The common source code 21 (“ABC100.cbl”), the Makefile (“ABC100.mk”) and the execution module 22 (“ABC100.exe”) for the development environment B (2B) are paid out. That is, the source code 21 (“ABC100.cbl”) is paid out in common to each system environment.

  Thereafter, development (creation / update of the source code 21 and the like), build, unit test, connection test, and the like are performed in each development environment 2. When these operations are completed, the module management unit 17 checks in the library 10 based on the managed property identification key and the managed property ID items specified for each module based on an instruction from the user. At this time, for example, when the created execution module 22 is not registered in the management table 10a, the contents of the management table 10a are updated.

  In tests such as unit tests and connection tests, the source code 21 is common to each system environment, that is, the business logic is the same, so for example, duplicate test items should be confirmed in one test execution. This makes it possible to greatly reduce the man-hours required for testing and improve efficiency. Further, since the latest source code 21 unified in each system environment is stored in the library 10, it is easy to prevent correction errors of the source code 21 and quality deterioration such as turnaround.

  FIG. 5 is a diagram showing an outline of processing for an example of unification of the source code 21 and the like in a plurality of system environments in the present embodiment. The module management unit 17 manages the source code 21 (“ABC100.cbl”) that is a managed property from the library 10 and a file (Makefile (“ABC100.mk”) related thereto and the generated execution module 22 (“ABC100.exe”). ")) Is paid out, for example, by copying each file to a predetermined area on a NAS (Network Attached Storage) 8 accessible from each development environment 2.

  Specifically, for example, when paying out to development environments A (2A) and B (2B), an area for development environment A (2A), an area for B (2B), and each system environment on NAS 8 Set a common area for. Copy the Makefile ("ABC100.mk") and the execution module 22 ("ABC100.exe") for the development environment A (2A) to the area for the development environment A (2A). Makefile (“ABC100.mk”) and execution module 22 (“ABC100.exe”) for development environment B (2B) are copied to the area. The common source code 21 (“ABC100.cbl”) is copied to the common area.

  At this time, only the area common to the area for the development environment A (2A) can be mounted from the user terminal 6 of the development environment A (2A), and the development environment B can be mounted from the user terminal 6 of the development environment B (2B). Only the area common to the area for (2B) can be mounted. Accordingly, the common source code 21 (“ABC100.cbl”), the Makefile (“ABC100.mk”) for the development environment A (2A), and the execution module 22 (““ Only the ABC100.exe ") can be referred to, and the user of the development environment B (2B) can make a common source code 21 (" ABC100.cbl ") and the Makefile (" ABC100.mk ") for the development environment B (2B). ) And the execution module 22 (“ABC100.exe”) can be controlled to be referable.

  When the development, unit test, connection test, etc. in each development environment 2 are completed, the target module on the NAS 8 is checked into the library 10 and the mount from each user terminal 6 to each area on the NAS 8 is released. Post-processing such as clearing the contents of each area is performed.

  As described above, according to the program development integrated management system 1 which is an embodiment of the present invention, the same unified source code 21 is individually provided in the development environment 2 corresponding to each system environment. The execution module 22 is generated by building, and after being tested in the test environment 3, the execution module 22 is released to the corresponding production environment 4. As a result, by providing the same source code 21 to a plurality of system environments in common, it is possible to reduce the load on development and testing. Further, by generating the execution module 22 suitable for the system environment in each system environment, for example, in a configuration in a data center having a large number of large-scale system environments that provide standard functions and services. However, it is possible to flexibly cope with each system environment.

  In addition, the developer and librarian who can release to the development environment and production environment systematically separate responsibilities and authority, and in the development environment 2 corresponding to each system environment, only the developers who can support it can access Access control can be performed as possible. In addition, it is possible to manage the generated execution module 22 so that a librarian having an appropriate authority is distributed and released at an appropriate timing to an appropriate server in the corresponding test environment 3 and production environment 4. In addition, while strengthening the internal control, it is possible to integrate and manage the library management mechanism and the development project (theme) process management and release management of the generated execution module 22.

  As mentioned above, the invention made by the present inventor has been specifically described based on the embodiment. However, the present invention is not limited to the embodiment, and various modifications can be made without departing from the scope of the invention. Needless to say.

  The present invention can be used in a program development integrated management system that manages libraries and releases in a plurality of types of system environments.

DESCRIPTION OF SYMBOLS 1 ... Program development integrated management system 2, 2A-C ... Development environment (A-C), 3 ... Test environment 4, 4A-C ... Production environment (A-C), 5 ... Librarian terminal, 6 ... User Terminal, 7 ... network, 8 ... NAS,
DESCRIPTION OF SYMBOLS 10 ... Library, 10a ... Management table, 11 ... User management part, 12 ... Theme management part, 13 ... Process management part, 14 ... Operation management part, 15 ... User interface part, 16 ... Repository management part, 17 ... Module management part , 18 ... Test environment distribution department, 19 ... Production release department,
21, 21A to C ... source code (A to C), 22, 22A to C ... execution modules (A to C).

Claims (6)

Managed items that are source code or related files or generated execution modules in program development that creates execution modules that are released to a production environment consisting of multiple types of system environments in a development environment having a corresponding system environment A program development integrated management system that performs library management for and the release management of the execution module for the production environment,
In the library for managing each managed property, managed property specifying information including information on a system environment to be applied to each managed property, a server type of the location, a path of the location, and a file name of the managed property A management table to hold,
Based on the content of the managed property specifying information in the management table, the same source code is checked out from the library to each development environment to be applied, and the source code generated from the source code in the development environment A module management unit that checks in an execution module to the library for each system environment and updates the management table;
A program development integrated management system comprising: a production release unit that releases the execution module generated in each development environment to the production environment having a corresponding system environment. In the program development integrated management system according to claim 1,
The management table further includes distribution-related information including information on a distribution-destination system environment for each managed property, a type of operating environment in the distribution-destination system environment, and a type of server in the distribution-destination system environment. Hold
Based on the content of the distribution related information in the management table, the module management unit distributes the managed property to the corresponding development environment, and the production release unit distributes the managed property to the corresponding production environment. An integrated management system for program development. In the program development integrated management system according to claim 1 or 2,
Further, the program development case is registered as a theme, information including the managed property and developer who can work with the theme is registered, and when the developer tries to access the managed property, the management is performed. A program having a theme management unit that performs access control for determining whether access is possible depending on whether a property is included in the subject and whether the developer can work on the theme Development integrated management system. In the program development integrated management system according to any one of claims 1 to 3,
Furthermore, it has a process management unit for executing a release approval process for accepting information including approval information about whether or not the execution module can be released for each production environment, a system environment and an operation environment of a release destination, and a release date,
The production release integrated management system, wherein the production release unit releases only the execution modules that can be released by the release approval process by the process management unit to the production environment. In the program development integrated management system according to any one of claims 1 to 4,
And a test environment distribution unit that distributes the execution modules generated in the development environment having a corresponding system environment to a plurality of types of test environments each having a system environment corresponding to the production environment. An integrated management system for program development. In the program development integrated management system according to any one of claims 1 to 5,
Further, both the module management unit and the user terminal used by the user in each development environment are accessible, and a first storage area provided for each type of system environment and a common in each system environment A storage device having a second storage area,
The module management unit includes the source code when checking out the managed property with respect to each of the development environments. The management property that is copied to the storage area of 2 and applied specifically to each system environment is copied to the first storage area for the corresponding system environment on the storage device, respectively.
The first management area and the second storage area for the corresponding system environment on the storage device are mounted on the user terminal, respectively, and each managed property located on the mounted storage area Is a program development integrated management system characterized in that it can be referred to by a user.

Images