WO2024038944A1 - 소스 코드를 업로드하는 방법 및 장치 - Google Patents

소스 코드를 업로드하는 방법 및 장치 Download PDF

Info

Publication number
WO2024038944A1
WO2024038944A1 PCT/KR2022/012967 KR2022012967W WO2024038944A1 WO 2024038944 A1 WO2024038944 A1 WO 2024038944A1 KR 2022012967 W KR2022012967 W KR 2022012967W WO 2024038944 A1 WO2024038944 A1 WO 2024038944A1
Authority
WO
WIPO (PCT)
Prior art keywords
branch
source code
request
master
private branch
Prior art date
Application number
PCT/KR2022/012967
Other languages
English (en)
French (fr)
Inventor
히리앙웨이
Original Assignee
쿠팡 주식회사
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 쿠팡 주식회사 filed Critical 쿠팡 주식회사
Publication of WO2024038944A1 publication Critical patent/WO2024038944A1/ko

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/41—Compilation
    • G06F8/48—Incremental compilation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/362—Software debugging
    • G06F11/3624—Software debugging by performing operations on the source code, e.g. via a compiler
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G06F11/3672—Test management
    • G06F11/3688—Test management for test execution, e.g. scheduling of test suites
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/3668—Software testing
    • G06F11/3672—Test management
    • G06F11/3692—Test management for test results analysis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G06F8/33—Intelligent editors
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G06F8/35—Creation or generation of source code model driven
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G06F8/35—Creation or generation of source code model driven
    • G06F8/355—Round-trip engineering
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/30—Creation or generation of source code
    • G06F8/36—Software reuse
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/41—Compilation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/40—Transformation of program code
    • G06F8/41—Compilation
    • G06F8/49—Partial evaluation
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/10—Office automation; Time management
    • G06Q10/103—Workflow collaboration or project management

Definitions

  • Embodiments of this specification relate to a method and device for uploading source code.
  • An embodiment of the present specification is a method of merging a personal branch containing source code to the master branch and uploading the source code by determining whether to approve a request to merge the personal branch to the master branch based on bug information about the private branch. and a device for the same.
  • source code management systems are used to manage source code written by developers.
  • Source code management systems such as Git may be characterized by not storing all versions of source code on a centralized server computer.
  • the source code management system can save the modifications to the source code by overwriting the existing version of the source code file with the new version of the source code file.
  • buggy source code written by a developer is stored in a source code management system, there may be a risk that the buggy source code will be shared with other developers. Accordingly, methods and devices for solving this problem are required.
  • the present disclosure is proposed to solve the above-described problems, and aims to provide a method and device for providing a page.
  • the present disclosure determines whether to approve a request to merge a private branch into the master branch based on bug information about the private branch, merges the private branch confirmed to be bug-free into the master branch, and merges the private branch confirmed to have a bug into the master branch.
  • the purpose is to provide a method and device for uploading error-free source code by blocking the merge of a private branch into the master branch.
  • a method for uploading source code in an electronic device includes: confirming a request to merge a private branch containing the source code into a master branch; Verifying the identification information of the private branch; checking bug information on the private branch corresponding to the identification information of the private branch; Based on bug information, determining whether to approve the request; and merging the personal branch to the master branch if the request is approved, and blocking the merge of the personal branch to the master branch if the request is not approved.
  • the personal branch may be a dedicated branch used for developing a user's source code
  • the master branch may be a shared branch used for developing and downloading other users' source code
  • the step of checking bug information about the personal branch may include checking bug information corresponding to the identification information based on the identification information included in the request.
  • the step of determining whether to approve the request may include determining whether to approve the request, depending on whether the bug information is included in a group for set bug information.
  • blocking a merge of a private branch into a master branch includes checking a change in bug information; Re-determining whether to approve the request based on the changed bug information; And if the request is approved, merging the private branch to the master branch may be further included.
  • merging the private branch into the master branch includes verifying changes to the source code; And it may further include blocking the merge of the private branch containing the changed source code to the master branch.
  • blocking a merge of a private branch containing changed source code into the master branch includes resetting bug information as the source code is changed; Based on the reset bug information, determining non-approval of the request; And it may include blocking the merge of the personal branch containing the changed source code to the master branch as the request is not approved.
  • the step of blocking a merge of a private branch containing changed source code into the master branch due to non-approval of the request includes: checking changed bug information corresponding to the changed source code; Re-approving the request based on the changed bug information; and re-approving the request may further include merging the private branch to the master branch.
  • the changed bug information may be characterized as information that changes depending on whether the changed source code is approved through a QA (Quality Assurance) terminal or a terminal of the user who developed the source code.
  • QA Quality Assurance
  • the source code is source code created on the user's terminal
  • the method for uploading the source code on the electronic device includes, when the request is approved, an individual merged from the first terminal of the first user to the master branch.
  • the method may further include providing a personal branch including source code to the first terminal upon receiving a download request for the branch.
  • the source code may be a source code written in the user's terminal, and the change in the source code may be characterized as a change in the first terminal of the first user.
  • An electronic device for uploading source code includes a transceiver; Storage for storing one or more instructions; and verifying a request to merge a private branch containing source code into the master branch, verifying the private branch's identifying information, checking bug information for the private branch corresponding to the private branch's identifying information, and based on the bug information
  • it may include a processor that determines whether to approve the request, and if the request is approved, merges the private branch to the master branch, and if the request is not approved, blocks the merge of the private branch to the master branch.
  • the recording medium according to the third aspect of the present disclosure may be a non-transitory computer-readable recording medium that records a program for execution on a computer.
  • the electronic device may determine whether to approve a request to merge the private branch into the master branch based on bug information about the private branch. Accordingly, the merge of a private branch containing buggy source code into the master branch may be blocked, and a private branch containing bug-free source code may be merged into the master branch. Accordingly, the electronic device can prevent private branches with bugs from merging into the master branch, which can be used by multiple users, by merging private branches containing bug-free source code into the master branch.
  • FIG. 1 is a diagram illustrating a system in which a method for an electronic device to upload source code can be implemented according to various embodiments.
  • Figure 2 is a flowchart showing how an electronic device uploads source code.
  • FIG. 3 is a diagram illustrating a specific embodiment in which an electronic device merges a personal branch into a master branch or blocks a merge of a personal branch into the master branch.
  • Figure 4 is a diagram for explaining a specific embodiment in which bug information is changed.
  • Figure 5 is a diagram to explain changes in a personal branch that are merged into the master branch as source code included in the personal branch is modified or new source code is pushed to the personal branch.
  • Figure 6 is a diagram for explaining a BTS ticket corresponding to a personal branch and bug information included in the BTS ticket.
  • Figure 7 is a block diagram illustrating an electronic device for providing a page according to an embodiment.
  • the “terminal” mentioned below may be implemented as a computer or portable terminal that can connect to a server or other terminal through a network.
  • the computer includes, for example, a laptop, desktop, laptop, etc. equipped with a web browser
  • the portable terminal is, for example, a wireless communication device that guarantees portability and mobility.
  • all types of communication-based terminals such as IMT (International Mobile Telecommunication), CDMA (Code Division Multiple Access), W-CDMA (W-Code Division Multiple Access), and LTE (Long Term Evolution), smartphones, tablet PCs, etc. It may include a handheld-based wireless communication device.
  • each block of the processing flow diagram diagrams and combinations of the flow diagram diagrams can be performed by computer program instructions.
  • These computer program instructions can be mounted on a processor of a general-purpose computer, special-purpose computer, or other programmable data processing equipment, so that the instructions performed through the processor of the computer or other programmable data processing equipment are described in the flow chart block(s). It creates the means to perform functions.
  • These computer program instructions may also be stored in computer-usable or computer-readable memory that can be directed to a computer or other programmable data processing equipment to implement a function in a particular manner, so that the computer-usable or computer-readable memory It is also possible to produce manufactured items containing instruction means that perform the functions described in the flowchart block(s).
  • Computer program instructions can also be mounted on a computer or other programmable data processing equipment, so that a series of operational steps are performed on the computer or other programmable data processing equipment to create a process that is executed by the computer, thereby generating a process that is executed by the computer or other programmable data processing equipment. Instructions that perform processing equipment may also provide steps for executing the functions described in the flow diagram block(s).
  • each block may represent a module, segment, or portion of code that includes one or more executable instructions for executing specified logical function(s).
  • each block may represent a module, segment, or portion of code that includes one or more executable instructions for executing specified logical function(s).
  • FIG. 1 is a diagram illustrating a system in which a method for an electronic device to upload source code can be implemented according to various embodiments.
  • system 10 may be implemented by various types of devices.
  • system 10 may include an electronic device 100, a terminal 110, and a first terminal 120.
  • the system 10 shown in Figure 1 shows only components relevant to this embodiment. Accordingly, those skilled in the art can understand that other general-purpose components may be included in addition to the components shown in FIG. 1.
  • system 10 may include a source code management system such as Git or Bazaar.
  • the electronic device 100, terminal 110, and first terminal 120 may each include a transceiver, storage, and processor.
  • the electronic device 100, the terminal 110, and the first terminal 120 each refer to a unit that processes at least one function or operation, which may be implemented through hardware, software, or a combination of hardware and software. You can.
  • the electronic device 100, the terminal 110, and the first terminal 120 are each referred to as separate devices or servers, but this may have a logically divided structure, and at least some of them are one device. Alternatively, it can be implemented by a separate function on the server.
  • the electronic device 100, the terminal 110, and the first terminal 120 may include a plurality of computer systems or computer software implemented as a network server.
  • the electronic device 100, the terminal 110, and the first terminal 120 are connected to lower level devices capable of communicating with other network servers through a computer network such as an intranet or the Internet to request task performance. It can refer to computer systems and computer software that receive data, perform work on it, and provide performance results.
  • at least some of the electronic device 100, the terminal 110, and the first terminal 120 include a series of application programs that can operate on a network server and various databases built inside or on other connected nodes. It can be understood as a broad concept.
  • at least some of the electronic device 100, the terminal 110, and the first terminal 120 run DOS, Windows, Linux, UNIX, or MacOS, etc. It can be implemented using various network server programs provided depending on the operating system.
  • the electronic device 100, terminal 110, and first terminal 120 may communicate with each other through a network (not shown).
  • Networks include Local Area Network (LAN), Wide Area Network (WAN), Value Added Network (VAN), mobile radio communication network, satellite communication network, and combinations thereof.
  • LAN Local Area Network
  • WAN Wide Area Network
  • VAN Value Added Network
  • It is a data communication network in a comprehensive sense that allows each network constituent shown in FIG. 1 to communicate smoothly with each other, and may include wired Internet, wireless Internet, and mobile wireless communication networks.
  • Wireless communications include, for example, wireless LAN (Wi-Fi), Bluetooth, Bluetooth low energy, ZigBee, WFD (Wi-Fi Direct), UWB (ultra wideband), and infrared communication (IrDA, infrared Data Association). ), NFC (Near Field Communication), etc., but are not limited thereto.
  • the electronic device 100 confirms a request to merge a private branch containing source code into the master branch, verifies the identification information of the private branch, and merges the private branch corresponding to the identification information of the private branch. Check the bug information, and based on the bug information, decide whether to approve the request. If the request is approved, the private branch is merged into the master branch. If the request is not approved, the private branch's merge to the master branch is blocked. You can.
  • the electronic device 100 receives a download request for the personal branch merged into the master branch from the first terminal 120 of the first user and sends the source code to the first terminal 120. You can provide a private branch containing your code.
  • a personal branch may be a dedicated branch used for development of a user's source code
  • a master branch may be a shared branch that may be used for development and downloading of another user's source code.
  • Personal branches merged into the master branch can also be downloaded by other users, so it may be necessary to merge only personal branches that have been verified to be bug-free through a bug tracking system into the master branch. Accordingly, as the electronic device 100 confirms the request to merge the private branch into the master branch, it can check bug information about the private branch corresponding to the request and decide whether to approve the request based on the bug information. .
  • the electronic device 100 can prevent personal branches containing source code with bugs from merging into the master branch shared by other users by merging only private branches that are confirmed to be bug-free. Additionally, when the source code is changed or bug information corresponding to the personal branch is changed, the electronic device 100 may re-determine whether to approve a request to merge the personal branch into the master branch. Specific examples of this will be discussed in detail below.
  • Figure 2 is a flowchart showing how an electronic device uploads source code.
  • each operation in which the electronic device 100 uploads the source code involves some operations being changed, replaced, or modified between operations within the range clearly understood by those skilled in the art to which the present invention pertains. It can be clearly understood that some orders may be changed.
  • step S210 the electronic device 100 may confirm a request to merge a private branch containing source code into the master branch.
  • a user can write and store source code in a local storage through the terminal 110. More specifically, the user can add and save the written source code to the local repository, and by updating and committing the source code previously saved in the local repository, the updated source code is included with information about the time the source code was updated. You can save it.
  • users can save some of the source code stored in the local repository to a private branch in the remote repository. More specifically, users can move some of the source code stored in the local repository to a personal branch stored in a personal remote repository before merging it to the master branch on GitHub. Additionally, the electronic device 100 may pull or clone the source code shared from the master branch to the personal branch and download the corresponding source code to the local storage.
  • the personal branch may be a dedicated branch used for the development of the user's source code
  • the master branch may be characterized as a shared branch used not only for the user but also for the development and download of the source code of other users.
  • the electronic device 100 may confirm a request to merge a private branch containing source code into the master branch. More specifically, the electronic device 100 can check the full list that merges the private branch containing the source code into the master branch.
  • the source code is source code created on the user's terminal and stored in the user's local storage, and may be shared with other users if the request for merge is approved.
  • a verification process may be required to determine whether it can be shared with other users. Accordingly, we will take a closer look below at an embodiment of the present application that checks whether there is an error in the source code based on bug information corresponding to a personal branch including the source code.
  • step S220 the electronic device 100 may check the identification information of the personal branch.
  • the electronic device 100 may check identification information to distinguish the personal branch for which a merge has been requested to the master branch from other private branches.
  • the identification information of the personal branch may be automatically generated as the personal branch is created. Additionally, the identification information of the personal branch may be included in the request, and the identification information between different personal branches may be different even if the personal branch is created through the same user's terminal.
  • the identification information of the personal branch may be a BTS (Bug Tracking System) key for checking bug information corresponding to the personal branch.
  • step S230 the electronic device 100 may check bug information about the personal branch corresponding to the identification information of the personal branch.
  • the electronic device 100 may check bug information, which is information about verifying whether a personal branch has a bug corresponding to the identification information of the personal branch.
  • a BTS ticket containing bug information for a private branch may be automatically created by the system as the private branch is created.
  • a BTS ticket related to bug information can be automatically created.
  • the bug information included in the BTS ticket may indicate that verification of whether there is a bug in the source code is not conducted immediately after the source code is created, but is not limited to this.
  • Bug information included in the BTS ticket may be reset according to the results of verification through a QA (Quality Assurance) terminal, etc.
  • the bug information included in the BTS ticket may be determined before or after the merge request according to the results of verification through a QA (Quality Assurance) terminal, etc., regardless of when the request to merge the personal branch to the master branch is confirmed. there is.
  • Bug information included in the BTS ticket may indicate different status information about whether a personal branch has a bug depending on the verification results through a QA terminal, etc.
  • bug information may be one of Closed, Done, Ready for deploy, Ready for deployment, Ready for release, Open, In Progress, Resolved, In QA, Reopen, but is not limited thereto.
  • 1) Closed may indicate a state in which the work of the corresponding BTS has been finally completed as it has been determined by QA, etc. that there are no bugs according to the process.
  • 2) Done may indicate a state in which intermediate confirmation of bug verification has been completed by QA or personal branch developers.
  • 3) Ready for deploy, Ready for deployment, and Ready for release can mean that a private branch is scheduled to be run or deployed after it has been confirmed that there are no bugs in the private branch.
  • 4) Open may indicate that the process for verifying bugs in the personal branch has been opened by BTS.
  • In Progress may indicate that the personal branch is being reviewed by the developer to determine whether there are bugs.
  • 6) Resolved may indicate that it has been confirmed that there are no bugs at the developer stage.
  • QA may refer to the stage of waiting for confirmation from QA whether there is a bug in the personal branch as it is confirmed that there is no bug in the developer stage.
  • Reopen may indicate that a private branch has been confirmed to have an error by a developer or QA. At this time, Reopen can be changed to Resolved, Closed, etc. by updating the source code or re-verifying whether there are errors in the personal branch by the developer or QA.
  • step S240 the electronic device 100 may determine whether to approve the request based on bug information.
  • the electronic device 100 may determine whether to approve the request depending on whether the confirmed bug information is included in a group for bug information.
  • the group for bug information may refer to a group representing bug information for which verification of the personal branch has been confirmed.
  • the electronic device 100 may decide to approve the request if the confirmed bug information is included in the bug information groups Closed, Done, Ready for deploy, Ready for deployment, and Ready for release.
  • the electronic device 100 may determine not to approve the request if the confirmed bug information is in a state that requires additional processing in the BTS system, such as Open, In Progress, Resolved, In QA, Reopen, etc.
  • step S250 the electronic device 100 may merge the personal branch to the master branch if the request is approved, and may block the merge of the personal branch to the master branch if the request is not approved.
  • step S240 depending on whether to approve the request, the electronic device 100 may allow or block the merge of the private branch into the master branch. However, since bug information may be changed by QA or developers, the electronic device 100 can flexibly change whether to approve the merge of the personal branch to the master branch.
  • the electronic device 100 may block a merge of a private branch to the master branch based on bug information about the private branch. However, as bug information is changed by QA or developer, it may be re-determined whether to approve the request to merge the personal branch into the master branch. At this time, upon determining approval of the request, the electronic device 100 may merge the personal branch into the master branch. 2) For example, the electronic device 100 may merge the personal branch into the master branch based on bug information about the personal branch. However, bug information for personal branches may change. For example, as the source code is updated, the bug information for a private branch containing the changed source code may change.
  • the electronic device 100 may re-determine whether to approve a request to merge the personal branch into the master branch based on the changed bug information. Upon determining that the request is not approved, the electronic device 100 may block the merge of the private branch to the master branch. Specific embodiments related to this will be examined in detail in FIG. 3.
  • FIG. 3 is a diagram illustrating a specific embodiment in which an electronic device merges a personal branch into a master branch or blocks a merge of a personal branch into the master branch.
  • step S301 the electronic device 100 may confirm a request to merge a private branch containing source code into the master branch.
  • the electronic device 100 may check bug information about the personal branch corresponding to the identification information of the personal branch.
  • the bug information for the personal branch is 'In Progress', and whether there is a bug in the current personal branch may be being confirmed by QA or a developer.
  • step S302 the electronic device 100 may determine whether to approve the request based on bug information. For example, since the bug information for the personal branch is 'In Progress', the electronic device 100 may determine that the request for merging the personal branch to the master branch is not approved.
  • step S303 the electronic device 100 may block the merge of the private branch into the master branch as it determines that the request is not approved.
  • step S304 the QA or developer can verify whether the private branch has bugs. For example, since the bug information for a personal branch is 'In Progress', QA or a developer can additionally verify whether there are bugs in the source code included in the personal branch.
  • the electronic device 100 may check the change in bug information.
  • the electronic device 100 may check the changed bug information as 'Closed'.
  • the changed bug information may be information that changes depending on whether the changed source code is approved through a QA (Quality Assurance) terminal or the terminal 110 of the user who developed the source code.
  • step S306 the electronic device 100 may re-determine whether to approve the request for merge based on the changed bug information. For example, the electronic device 100 may decide to approve a request for a merge based on the changed bug information 'Closed'.
  • step S307 as the request is approved, the electronic device 100 may merge the private branch into the master branch. Accordingly, the personal branch containing the source code that has been verified by QA and developers is merged into the master branch, so other users or developers can download and use the personal branch containing the source code.
  • step S308 the electronic device 100 can confirm the change in source code. For example, as the user updates the source code included in the personal branch or pushes new source code, the electronic device 100 may check the change in the source code.
  • the electronic device 100 may reset bug information about the personal branch including the changed source code.
  • the bug information for the private branch containing the source code before the change needs to be changed.
  • Bug information according to reset may be a default value for bug information.
  • the default value for bug information may be 'Reopen', and the electronic device 100 may check the reset bug information as 'Reopen'.
  • step S310 the electronic device 100 may determine whether to approve the request. For example, the electronic device 100 may decide to disapprove the request based on the reset bug information.
  • step S311 the electronic device 100 may block the merge of the private branch to the master branch as it determines that the request is not approved. Accordingly, the electronic device 100 may block the merge of the personal branch containing the changed source code to the master branch.
  • step S312 the QA or developer may verify whether the private branch containing the changed source code has bugs. For example, since the bug information for the personal branch is 'Reopen', QA or developers can additionally verify whether there are bugs in the source code included in the personal branch. Depending on verification by QA or developer, bug information may change. For example, changed bug information may be 'Closed'.
  • the electronic device 100 may re-determine whether to approve the request for merge based on the changed bug information. For example, the electronic device 100 may decide to re-approve a request for a merge based on the changed bug information 'Closed'.
  • step S314 as the request is re-approved, the electronic device 100 may merge the private branch into the master branch. As verification of the changed source code is completed, the electronic device 100 may merge the personal branch containing the changed source code into the master branch.
  • Figure 4 is a diagram for explaining a specific embodiment in which bug information is changed.
  • FIG. 4 shows a BTS system 400 in which bug information included in a BTS ticket changes as developers and QA verify whether there is a bug in the personal branch.
  • the BTS system 400 according to the embodiment of FIG. 4 is characterized in that bug information is 'Closed' after verification of bugs in the order of 1) developer and 2) QA, but is not limited to this.
  • the BTS system 400 may perform verification of bugs from one of a developer and a QA.
  • a BTS ticket containing bug information for a private branch may be automatically created by the system as the private branch is created.
  • the bug information included in the automatically generated BTS ticket may be 'Open' as a default value.
  • the bug information corresponding to the personal branch may be 'In Progress'. 1) If it is confirmed at the developer stage that there are no bugs in the source code included in the personal branch, the bug information corresponding to the personal branch may be 'Resolved'. Conversely, 2) If it is confirmed at the developer stage that there is a bug in the source code included in the personal branch, the bug information corresponding to the personal branch may be 'Reopen'. At this time, if the source code is updated or is subject to a re-verification process for the personal branch included in the source code by the developer, the bug information may become 'In Progress' again.
  • the bug information corresponding to the personal branch may be 'In QA'.
  • QA may refer to the stage of waiting for confirmation from QA whether there is a bug in the personal branch as it is confirmed that there is no bug in the developer stage. 1) If it is confirmed at the QA stage that there are no bugs in the source code included in the personal branch, the bug information corresponding to the personal branch may be 'Ready for release'. Conversely, 2) If it is confirmed at the QA stage that there is a bug in the source code included in the personal branch, the bug information corresponding to the personal branch may be 'Reopen'. At this time, if the source code is updated or is subject to a re-verification process for the personal branch included in the source code by the developer, the bug information may become 'In Progress' again.
  • the private branch may be scheduled to be distributed to other users.
  • the bug information may change from 'Ready for release' to 'Reopen'.
  • the bug information may change directly from 'In QA' to 'Closed' without going through the 'Ready for release' stage.
  • the bug information may indicate that QA, etc., has determined that there is no bug according to the process and the work of the corresponding BTS has been finally completed. However, if the source code is changed or it is confirmed by QA or developer that there is a bug in the source code, the bug information may change from 'Closed' to 'Reopen'.
  • Figure 5 is a diagram to explain changes in a personal branch that are merged into the master branch as source code included in the personal branch is modified or new source code is pushed to the personal branch.
  • Figure 5 shows a screen 500 for explaining a commit according to a change in a personal branch merged into the master branch.
  • the bug information corresponding to the private branch may be reset. If there is a change in the source code included in the personal branch merged into the master branch, the change history of the source code according to the commit may be saved as shown in screen 500. Additionally, identification information to check changed bug information corresponding to changes in source code may also be stored.
  • the identification information of a personal branch may be a BTS key for checking bug information corresponding to the personal branch. Referring to Figure 5, the identification information of the personal branch may be 'FRES-1103'.
  • the first commit 510 may be about 'Video Review Carousel on Fresh Home See More'.
  • the source code included in a personal branch merged into the master branch may not necessarily be changed by a single developer. For example, if a personal branch included in the source code is merged into the master branch according to a pull request through developer A, not only developer A but also other developers can share the personal branch. Accordingly, developer B can download the private branch containing the source code and modify it. For example, referring to Figure 5, it can be seen that changes to the personal branch are executed by developer A or developer B. Accordingly, the source code may be a source code created on the terminal of a user (corresponding to developer A), and the modification of the source code may be characterized as being changed in the first terminal of a first user (corresponding to developer B).
  • Figure 6 is a diagram for explaining a BTS ticket corresponding to a personal branch and bug information included in the BTS ticket.
  • a BTS ticket 600 containing bug information for a private branch may be automatically created by the system as the private branch is created.
  • BTS ticket 600 may include identification information of a private branch.
  • the BTS ticket 600 may include 'FRES-1103' 610, which is the identification information in FIG. 5. Accordingly, the electronic device 100 can check the BTS ticket 600 corresponding to the personal branch among the plurality of BTS tickets based on the identification information 'FRES-1103' 610.
  • the BTS ticket 600 may correspond to the first commit 510 of FIG. 5 regarding 'Video Review Carousel on Fresh Home See More'.
  • BTS ticket 600 may include bug information for the private branch of FIG. 5.
  • bug information included in the BTS ticket 600 may be 'Ready for release'. Accordingly, the bug information corresponding to the current personal branch is 'Ready for release', and as the merge of the personal branch to the master branch is re-approved, the electronic device 100 can merge the personal branch to the master branch.
  • Figure 7 is a block diagram illustrating an electronic device for providing a page according to an embodiment.
  • the electronic device 700 of FIG. 7 may correspond to the electronic device 100 of the present specification.
  • the electronic device 700 of the present disclosure may include a transceiver 710, a processor 720, and a storage 730.
  • the components shown in FIG. 7 are not essential for implementing the electronic device, so the electronic device 700 described herein may have more or fewer components than the components listed above.
  • the processor 720 may include at least one processor.
  • the transceiver 710 can communicate with an external device using wired or wireless communication technology and may include the transceiver 710.
  • the external device can be a terminal or server.
  • communication technologies used by the transceiver 710 include Global System for Mobile communication (GSM), Code Division Multi Access (CDMA), Long Term Evolution (LTE), 5G, Wireless LAN (WLAN), and Wireless-Fidelity (Wi-Fi). ), Bluetooth, RFID (Radio Frequency Identification), Infrared Data Association (IrDA), ZigBee, NFC (Near Field Communication), etc., but are not limited thereto.
  • the transceiver 710 may receive a signal for a request to merge a private branch containing source code into the master branch. Additionally, the transceiver 710 may transmit a personal branch including source code to the terminal as it receives a download request for a personal branch merged into the master branch from another terminal.
  • the processor 720 can control the overall operation of the electronic device 700 and process data and signals.
  • the processor 720 may perform one of the methods described above through FIGS. 1 to 6.
  • the processor 720 controls embodiments performed by the electronic device 700 through interaction with the transceiver 710 and the storage 730 and further components that the electronic device 700 may include. You can.
  • processor 720 verifies a request to merge a private branch containing source code into the master branch, verifies the private branch's identifying information, and configures the private branch corresponding to the private branch's identifying information. You can check the bug information, decide whether to approve the request based on the bug information, merge the private branch to the master branch if the request is approved, and block the merge of the private branch to the master branch if the request is not approved. there is.
  • the storage 730 may store information for performing at least one method described above with reference to FIGS. 1 to 6 .
  • Storage 730 may be referred to as memory and may be volatile memory or non-volatile memory. Additionally, the storage 730 may store one or more instructions required to perform the operation of the processor 1520, and may temporarily store data stored on the platform or in an external memory. For example, storage 730 may include identification information for a private branch, bug information for the private branch, and group information for set bug information used to determine whether to approve a request. In addition, the storage 730 may temporarily store information confirmed by the processor 720.
  • the electronic device or terminal includes a processor, memory for storing and executing program data, permanent storage such as a disk drive, a communication port for communicating with an external device, a touch panel, and a key. , user interface devices such as icons, etc.
  • Methods implemented as software modules or algorithms may be stored on a computer-readable recording medium as computer-readable codes or program instructions executable on the processor.
  • computer-readable recording media include magnetic storage media (e.g., ROM (read-only memory), RAM (random-access memory), floppy disk, hard disk, etc.) and optical read media (e.g., CD-ROM). ), DVD (Digital Versatile Disc), etc.
  • the computer-readable recording medium is distributed among computer systems connected to a network, so that computer-readable code can be stored and executed in a distributed manner.
  • the media may be readable by a computer, stored in memory, and executed by a processor.
  • This embodiment can be represented by functional block configurations and various processing steps. These functional blocks may be implemented in various numbers of hardware or/and software configurations that execute specific functions. For example, embodiments include integrated circuit configurations such as memory, processing, logic, look-up tables, etc. that can execute various functions under the control of one or more microprocessors or other control devices. can be hired. Similar to how the components can be implemented as software programming or software elements, the present embodiments include various algorithms implemented as combinations of data structures, processes, routines or other programming constructs, such as C, C++, Java ( It can be implemented in a programming or scripting language such as Java, assembler, Python, etc. Functional aspects may be implemented as algorithms running on one or more processors.
  • this embodiment may employ conventional technologies for electronic environment settings, signal processing, and/or data processing.
  • Terms such as “mechanism,” “element,” “means,” and “composition” can be used broadly and are not limited to mechanical and physical components. The term may include the meaning of a series of software routines in connection with a processor, etc.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Business, Economics & Management (AREA)
  • Quality & Reliability (AREA)
  • Human Resources & Organizations (AREA)
  • Strategic Management (AREA)
  • Computer Hardware Design (AREA)
  • Entrepreneurship & Innovation (AREA)
  • General Business, Economics & Management (AREA)
  • Tourism & Hospitality (AREA)
  • Operations Research (AREA)
  • Marketing (AREA)
  • Economics (AREA)
  • Data Mining & Analysis (AREA)
  • Stored Programmes (AREA)
  • Information Transfer Between Computers (AREA)

Abstract

전자 장치에서 소스 코드를 업로드하는 방법이 개시된다. 구체적으로, 전자 장치에서 소스 코드를 업로드하는 방법은 소스 코드를 포함하는 개인 브랜치를 마스터 브랜치에 머지하는 요청을 확인하는 단계; 개인 브랜치의 식별 정보를 확인하는 단계; 개인 브랜치의 식별 정보에 대응하는 개인 브랜치에 대한 버그 정보를 확인하는 단계; 버그 정보에 기반하여, 요청의 승인 여부를 결정하는 단계; 및 요청을 승인하면 개인 브랜치를 마스터 브랜치에 머지하고, 요청을 미승인하면 개인 브랜치의 마스터 브랜치로의 머지를 블락하는 단계를 포함할 수 있다.

Description

소스 코드를 업로드하는 방법 및 장치
본 명세서의 실시 예는 소스 코드를 업로드하는 방법 및 장치에 관한 것이다. 본 명세서의 실시 예는 개인 브랜치에 대한 버그 정보에 기반하여 개인 브랜치를 마스터 브랜치에 머지하는 요청의 승인 여부를 결정함으로써, 소스 코드를 포함하는 개인 브랜치를 마스터 브랜치에 머지하여 소스 코드를 업로드하는 방법 및 이에 대한 장치에 관한 것이다.
컴퓨터 소프트웨어 개발에서, 소스 코드 관리 시스템은 개발자에 의해 작성된 소스 코드를 관리하기 위해 사용되고 있다. Git과 같은 소스 코드 관리 시스템은 중앙 집중식 서버 컴퓨터에 모든 버전의 소스 코드를 저장하고 있지 않은 것을 특징으로 할 수 있다. 개발자가 새로운 버전의 소스 코드를 개발함에 따라, 소스 코드 관리 시스템은 새로운 버전의 소스 코드 파일로 기존 버전의 소스 코드 파일을 덮어 쓰기함으로써 소스 코드에 대한 수정 사항을 저장할 수 있다. 다만, 개발자에 의해 작성된 버그가 있는 소스 코드가 소스 코드 관리 시스템에 저장되면, 다른 개발자에게도 버그가 있는 소스 코드가 공유될 우려가 있을 수 있다. 따라서, 이와 같은 문제를 해결하기 위한 방법 및 장치가 요구된다.
본 개시는 상술한 문제점을 해결하기 위해 제안된 것으로, 페이지를 제공하는 방법 및 이를 장치를 제공하는데 있다.
보다 구체적으로 본 개시는 개인 브랜치에 대한 버그 정보에 기반하여 개인 브랜치를 마스터 브랜치에 머지하는 요청의 승인 여부를 결정하여, 버그가 없다고 확인된 개인 브랜치를 마스터 브랜치에 머지하고, 버그가 있다고 확인된 개인 브랜치의 마스터 브랜치로의 머지는 블락함으로써, 오류가 없는 소스 코드를 업로드하는 방법 및 장치를 제공하는 것을 목적으로 한다.
본 실시 예가 이루고자 하는 기술적 과제는 상기된 바와 같은 기술적 과제들로 한정되지 않으며, 이하의 실시 예들로부터 또 다른 기술적 과제들이 유추될 수 있다.
상술한 과제를 달성하기 위한 기술적 수단으로서, 본 개시의 제1측면에 따른 전자 장치에서 소스 코드를 업로드하기 위한 방법은 소스 코드를 포함하는 개인 브랜치를 마스터 브랜치에 머지하는 요청을 확인하는 단계; 개인 브랜치의 식별 정보를 확인하는 단계; 개인 브랜치의 식별 정보에 대응하는 개인 브랜치에 대한 버그 정보를 확인하는 단계; 버그 정보에 기반하여, 요청의 승인 여부를 결정하는 단계; 및 요청을 승인하면 개인 브랜치를 마스터 브랜치에 머지하고, 요청을 미승인하면 개인 브랜치의 마스터 브랜치로의 머지를 블락하는 단계를 포함할 수 있다.
일 실시 예에 따르면, 개인 브랜치는 사용자의 소스 코드의 개발에 이용되는 전용 브랜치이고, 및 마스터 브랜치는 다른 사용자의 소스 코드의 개발 및 다운로드에도 이용되는 공유 브랜치인 것을 특징으로 할 수 있다.
일 실시 예에 따르면, 개인 브랜치에 대한 버그 정보를 확인하는 단계는 요청에 포함되는 식별 정보에 기반하여, 식별 정보에 대응되는 버그 정보를 확인하는 단계를 포함할 수 있다.
일 실시 예에 따르면, 요청의 승인 여부를 결정하는 단계는 버그 정보가 설정된 버그 정보에 대한 그룹에 포함되는지 여부에 따라, 요청의 승인 여부를 결정하는 단계를 포함할 수 있다.
일 실시 예에 따르면, 개인 브랜치의 마스터 브랜치로의 머지를 블락하는 단계는 버그 정보의 변경을 확인하는 단계; 변경된 버그 정보에 기반하여, 요청의 승인 여부를 재결정하는 단계; 및 요청을 승인하면 개인 브랜치를 마스터 브랜치에 머지하는 단계를 더 포함할 수 있다.
일 실시 예에 따르면, 개인 브랜치를 마스터 브랜치에 머지하는 단계는 소스 코드의 변경을 확인하는 단계; 및 변경된 소스 코드를 포함하는 개인 브랜치의 마스터 브랜치로의 머지를 블락하는 단계를 더 포함할 수 있다.
일 실시 예에 따르면, 변경된 소스 코드를 포함하는 개인 브랜치의 마스터 브랜치로의 머지를 블락하는 단계는 소스 코드가 변경됨에 따라, 버그 정보를 리셋하는 단계; 리셋된 버그 정보에 기반하여, 요청의 미승인을 결정하는 단계; 및 요청을 미승인함에 따라 변경된 소스 코드를 포함하는 개인 브랜치의 마스터 브랜치로의 머지를 블락하는 단계를 포함할 수 있다.
일 실시 예에 따르면, 요청을 미승인함에 따라 변경된 소스 코드를 포함하는 개인 브랜치의 마스터 브랜치로의 머지를 블락하는 단계는 변경된 소스 코드에 대응하는 변경된 버그 정보를 확인하는 단계; 변경된 버그 정보에 기반하여, 요청을 재승인하는 단계; 및 요청을 재승인하면 개인 브랜치를 마스터 브랜치에 머지하는 단계를 더 포함할 수 있다.
일 실시 예에 따르면, 변경된 버그 정보는 QA(Quality Assurance) 단말 또는 소스 코드를 개발한 사용자의 단말을 통한 변경된 소스 코드에 대한 승인 여부에 따라 변경되는 정보인 것을 특징으로 할 수 있다.
일 실시 예에 따르면, 소스 코드는 사용자의 단말에서 작성된 소스 코드이고, 및 전자 장치에서 소스 코드를 업로드하기 위한 방법은 요청을 승인한 경우, 제1 사용자의 제1 단말로부터 마스터 브랜치에 머지된 개인 브랜치에 대한 다운로드 요청을 수신함에 따라 제1 단말에 소스 코드를 포함하는 개인 브랜치를 제공하는 단계를 더 포함할 수 있다.
일 실시 예에 따르면, 소스 코드는 사용자의 단말에서 작성된 소스 코드이고, 및 소스 코드의 변경은 제1 사용자의 제1 단말에서 변경된 것을 특징으로 할 수 있다.
본 개시의 제2측면에 따른 소스 코드를 업로드하기 위한 전자 장치는 트랜시버; 하나 이상의 명령어를 저장하는 스토리지; 및 소스 코드를 포함하는 개인 브랜치를 마스터 브랜치에 머지하는 요청을 확인하고, 개인 브랜치의 식별 정보를 확인하고, 개인 브랜치의 식별 정보에 대응하는 개인 브랜치에 대한 버그 정보를 확인하고, 버그 정보에 기반하여, 요청의 승인 여부를 결정하고, 및 요청을 승인하면 개인 브랜치를 마스터 브랜치에 머지하고, 요청을 미승인하면 개인 브랜치의 마스터 브랜치로의 머지를 블락하는 프로세서를 포함할 수 있다.
본 개시의 제3측면에 따른 기록매체는 컴퓨터에서 실행시키기 위한 프로그램을 기록한 컴퓨터로 읽을 수 있는 비일시적 기록매체일 수 있다.
본 명세서의 실시 예에 따르면, 전자 장치는 개인 브랜치에 대한 버그 정보에 기반하여 개인 브랜치를 마스터 브랜치에 머지하는 요청의 승인 여부를 결정할 수 있다. 이에 따라, 버그가 있는 소스 코드를 포함하는 개인 브랜치의 마스터 브랜치로의 머지는 블락될 수 있고, 버그가 없는 소스 코드를 포함하는 개인 브랜치는 마스터 브랜치로 머지될 수 있다. 이에 따라, 전자 장치는 버그가 없는 소스 코드를 포함하는 개인 브랜치는 마스터 브랜치로 머지함으로써, 복수의 사용자에 의해 이용될 수 있는 마스터 브랜치에 버그가 있는 개인 브랜치가 머지되는 것을 방지할 수 있다.
발명의 효과는 이상에서 언급한 효과로 제한되지 않으며, 언급되지 않은 또 다른 효과들은 청구범위의 기재로부터 당해 기술 분야의 통상의 기술자에게 명확하게 이해될 수 있을 것이다.
도 1은 다양한 실시 예에 따른 전자 장치가 소스 코드를 업로드하는 방법이 구현될 수 있는 시스템을 설명하기 위한 도면이다.
도 2는 전자 장치가 소스 코드를 업로드하는 방법을 나타낸 흐름도이다.
도 3은 전자 장치가 개인 브랜치를 마스터 브랜치에 머지하거나 개인 브랜치의 마스터 브랜치로의 머지를 블락하는 구체적인 실시 예를 설명하기 위한 도면이다.
도 4는 버그 정보가 변경되는 구체적인 실시 예를 설명하기 위한 도면이다.
도 5는 개인 브랜치에 포함되는 소스 코드를 수정하거나 개인 브랜치에 새로운 소스 코드를 푸시함에 따라, 마스터 브랜치에 머지되는 개인 브랜치의 변경을 설명하기 위한 도면이다.
도 6은 개인 브랜치에 대응하는 BTS 티켓 및 BTS 티켓에 포함되는 버그 정보를 설명하기 위한 도면이다.
도 7은 일 실시 예에 따른 페이지를 제공하기 위한 전자 장치를 도식화한 블록도이다.
실시 예들에서 사용되는 용어는 본 개시에서의 기능을 고려하면서 가능한 현재 널리 사용되는 일반적인 용어들을 선택하였으나, 이는 당 분야에 종사하는 기술자의 의도 또는 판례, 새로운 기술의 출현 등에 따라 달라질 수 있다. 또한, 특정한 경우는 출원인이 임의로 선정한 용어도 있으며, 이 경우 해당되는 설명 부분에서 상세히 그 의미를 기재할 것이다. 따라서 본 개시에서 사용되는 용어는 단순한 용어의 명칭이 아닌, 그 용어가 가지는 의미와 본 개시의 전반에 걸친 내용을 토대로 정의되어야 한다.
명세서 전체에서 어떤 부분이 어떤 구성요소를 “포함”한다고 할 때, 이는 특별히 반대되는 기재가 없는 한 다른 구성요소를 제외하는 것이 아니라 다른 구성요소를 더 포함할 수 있음을 의미한다. 또한, 명세서에 기재된 “...부”, “...모듈” 등의 용어는 적어도 하나의 기능이나 동작을 처리하는 단위를 의미하며, 이는 하드웨어 또는 소프트웨어로 구현되거나 하드웨어와 소프트웨어의 결합으로 구현될 수 있다.
명세서 전체에서 기재된 “a, b, 및 c 중 적어도 하나”의 표현은, ‘a 단독’, ‘b 단독’, ‘c 단독’, ‘a 및 b’, ‘a 및 c’, ‘b 및 c’, 또는 ‘a,b,c 모두’를 포괄할 수 있다.
이하에서 언급되는 "단말"은 네트워크를 통해 서버나 타 단말에 접속할 수 있는 컴퓨터나 휴대용 단말로 구현될 수 있다. 여기서, 컴퓨터는 예를 들어, 웹 브라우저(WEB Browser)가 탑재된 노트북, 데스크톱(desktop), 랩톱(laptop) 등을 포함하고, 휴대용 단말은 예를 들어, 휴대성과 이동성이 보장되는 무선 통신 장치로서, IMT(International Mobile Telecommunication), CDMA(Code Division Multiple Access), W-CDMA(W-Code Division Multiple Access), LTE(Long Term Evolution) 등의 통신 기반 단말, 스마트폰, 태블릿 PC 등과 같은 모든 종류의 핸드헬드(Handheld) 기반의 무선 통신 장치를 포함할 수 있다.
아래에서는 첨부한 도면을 참고하여 본 개시의 실시 예에 대하여 본 개시가 속하는 기술 분야에서 통상의 지식을 가진 자가 용이하게 실시할 수 있도록 상세히 설명한다. 그러나 본 개시는 여러 가지 상이한 형태로 구현될 수 있으며 여기에서 설명하는 실시 예에 한정되지 않는다.
이하, 본 발명의 실시 예를 첨부된 도면을 참조하여 상세하게 설명한다.
실시 예를 설명함에 있어서 본 발명이 속하는 기술 분야에 익히 알려져 있고 본 발명과 직접적으로 관련이 없는 기술 내용에 대해서는 설명을 생략한다. 이는 불필요한 설명을 생략함으로써 본 발명의 요지를 흐리지 않고 더욱 명확히 전달하기 위함이다.
마찬가지 이유로 첨부 도면에 있어서 일부 구성요소는 과장되거나 생략되거나 개략적으로 도시되었다. 또한, 각 구성요소의 크기는 실제 크기를 전적으로 반영하는 것이 아니다. 각 도면에서 동일한 또는 대응하는 구성요소에는 동일한 참조 번호를 부여하였다.
본 발명의 이점 및 특징, 그리고 그것들을 달성하는 방법은 첨부되는 도면과 함께 상세하게 후술되어 있는 실시 예들을 참조하면 명확해질 것이다. 그러나 본 발명은 이하에서 개시되는 실시 예들에 한정되는 것이 아니라 서로 다른 다양한 형태로 구현될 수 있으며, 단지 본 실시 예들은 본 발명의 개시가 완전하도록 하고, 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 발명의 범주를 완전하게 알려주기 위해 제공되는 것이며, 본 발명은 청구항의 범주에 의해 정의될 뿐이다. 명세서 전체에 걸쳐 동일 참조 부호는 동일 구성 요소를 지칭한다.
이 때, 처리 흐름도 도면들의 각 블록과 흐름도 도면들의 조합들은 컴퓨터 프로그램 인스트럭션들에 의해 수행될 수 있음을 이해할 수 있을 것이다. 이들 컴퓨터 프로그램 인스트럭션들은 범용 컴퓨터, 특수용 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비의 프로세서에 탑재될 수 있으므로, 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비의 프로세서를 통해 수행되는 그 인스트럭션들이 흐름도 블록(들)에서 설명된 기능들을 수행하는 수단을 생성하게 된다. 이들 컴퓨터 프로그램 인스트럭션들은 특정 방식으로 기능을 구현하기 위해 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비를 지향할 수 있는 컴퓨터 이용 가능 또는 컴퓨터 판독 가능 메모리에 저장되는 것도 가능하므로, 그 컴퓨터 이용가능 또는 컴퓨터 판독 가능 메모리에 저장된 인스트럭션들은 흐름도 블록(들)에서 설명된 기능을 수행하는 인스트럭션 수단을 내포하는 제조 품목을 생산하는 것도 가능하다. 컴퓨터 프로그램 인스트럭션들은 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비 상에 탑재되는 것도 가능하므로, 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비 상에서 일련의 동작 단계들이 수행되어 컴퓨터로 실행되는 프로세스를 생성해서 컴퓨터 또는 기타 프로그램 가능한 데이터 프로세싱 장비를 수행하는 인스트럭션들은 흐름도 블록(들)에서 설명된 기능들을 실행하기 위한 단계들을 제공하는 것도 가능하다.
또한, 각 블록은 특정된 논리적 기능(들)을 실행하기 위한 하나 이상의 실행 가능한 인스트럭션들을 포함하는 모듈, 세그먼트 또는 코드의 일부를 나타낼 수 있다. 또, 몇 가지 대체 실행 예들에서는 블록들에서 언급된 기능들이 순서를 벗어나서 발생하는 것도 가능함을 주목해야 한다. 예컨대, 잇달아 도시되어 있는 두 개의 블록들은 사실 실질적으로 동시에 수행되는 것도 가능하고 또는 그 블록들이 때때로 해당하는 기능에 따라 역순으로 수행되는 것도 가능하다.
도 1은 다양한 실시 예에 따른 전자 장치가 소스 코드를 업로드하는 방법이 구현될 수 있는 시스템을 설명하기 위한 도면이다.
도 1을 참조하면, 다양한 실시 예에 따른 시스템(10)은 다양한 종류의 장치들에 의해 구현될 수 있다. 예를 들어, 시스템(10)은 전자 장치(100), 단말(110) 및 제1 단말(120)을 포함할 수 있다. 도1에 도시된 시스템(10)은 본 실시 예와 관련된 구성요소들만 도시되어 있다. 따라서, 도 1에 도시된 구성요소들 외에 다른 범용적인 구성요소들이 더 포함될 수 있음을 본 실시 예와 관련된 기술분야에서 통상의 지식을 가진 자라면 이해할 수 있다. 또한, 시스템(10)은 Git, Bazaar와 같은 소스 코드 관리 시스템을 포함할 수 있다.
전자 장치(100), 단말(110) 및 제1 단말(120) 각각은 트랜시버, 스토리지 및 프로세서를 포함할 수 있다. 또한, 전자 장치(100), 단말(110) 및 제1 단말(120) 각각은 적어도 하나의 기능이나 동작을 처리하는 단위를 의미하며, 이는 하드웨어나 소프트웨어, 또는, 하드웨어 및 소프트웨어의 결합으로 구현될 수 있다. 한편 실시 예 전반에서 전자 장치(100), 단말(110) 및 제1 단말(120) 각각은 분리된 장치 또는 서버로 언급되나 이는 논리적으로 나누어진 구조일 수 있으며, 이들 중 적어도 일부가 하나의 장치 또는 서버에서 분리된 기능에 의해 구현될 수 있다.
일 실시 예에 따르면, 전자 장치(100), 단말(110) 및 제1 단말(120)는 네트워크 서버로 구현되는 다수의 컴퓨터 시스템 또는 컴퓨터 소프트웨어를 포함할 수 있다. 예를 들면 전자 장치(100), 단말(110) 및 제1 단말(120) 중 적어도 일부는 인트라넷 또는 인터넷과 같은 컴퓨터 네트워크를 통해 다른 네트워크 서버와 통신할 수 있는 하위 장치와 연결되어 작업 수행 요청을 접수하고, 그에 대한 작업을 수행하여 수행 결과를 제공하는 컴퓨터 시스템 및 컴퓨터 소프트웨어를 지칭할 수 있다. 이외에도, 전자 장치(100), 단말(110) 및 제1 단말(120) 중 적어도 일부는 네트워크 서버 상에서 동작할 수 있는 일련의 응용 프로그램과, 내부 혹은 연결된 다른 노드에 구축되어 있는 각종 데이터베이스를 포함하는 광의의 개념으로 이해될 수 있다. 예컨대, 전자 장치(100), 단말(110) 및 제1 단말(120) 중 적어도 일부는 도스(DOS), 윈도우(Windows), 리눅스(Linux), 유닉스(UNIX), 또는 맥OS(MacOS) 등의 운영 체제에 따라 다양하게 제공되는 네트워크 서버 프로그램을 이용하여 구현될 수 있다.
전자 장치(100), 단말(110) 및 제1 단말(120)는 네트워크(미도시)를 통해서 서로 통신할 수 있다. 네트워크는 근거리 통신망(Local Area Network; LAN), 광역 통신망(Wide Area Network; WAN), 부가가치 통신망(Value Added Network; VAN), 이동 통신망(mobile radio communication network), 위성 통신망 및 이들의 상호 조합을 포함하며, 도 1에 도시된 각 네트워크 구성 주체가 서로 원활하게 통신을 할 수 있도록 하는 포괄적인 의미의 데이터 통신망이며, 유선 인터넷, 무선 인터넷 및 모바일 무선 통신망을 포함할 수 있다. 무선 통신은 예를 들어, 무선 랜(Wi-Fi), 블루투스, 블루투스 저 에너지(Bluetooth low energy), 지그비, WFD(Wi-Fi Direct), UWB(ultra wideband), 적외선 통신(IrDA, infrared Data Association), NFC(Near Field Communication) 등이 있을 수 있으나, 이에 한정되는 것은 아니다.
일 실시 예에 따르면, 전자 장치(100)는 소스 코드를 포함하는 개인 브랜치를 마스터 브랜치에 머지하는 요청을 확인하고, 개인 브랜치의 식별 정보를 확인하고, 개인 브랜치의 식별 정보에 대응하는 개인 브랜치에 대한 버그 정보를 확인하고, 버그 정보에 기반하여, 요청의 승인 여부를 결정하고, 및 요청을 승인하면 개인 브랜치를 마스터 브랜치에 머지하고, 요청을 미승인하면 개인 브랜치의 마스터 브랜치로의 머지를 블락할 수 있다. 개인 브랜치가 마스터 브랜치에 머지된 경우, 전자 장치(100)는 제1 사용자의 제1 단말(120)로부터 마스터 브랜치에 머지된 개인 브랜치에 대한 다운로드 요청을 수신함에 따라 제1 단말(120)에 소스 코드를 포함하는 개인 브랜치를 제공할 수 있다.
본원에서, 개인 브랜치는 사용자의 소스 코드의 개발에 이용되는 전용 브랜치일 수 있고, 마스터 브랜치는 다른 사용자의 소스 코드의 개발 및 다운로드 등에 이용될 수 있는 공유 브랜치일 수 있다. 마스터 브랜치에 머지된 개인 브랜치는 다른 사용자들도 다운로드 받을 수 있는 바, 버그 트래킹 시스템을 통해 버그가 없다고 검증된 개인 브랜치만을 마스터 브랜치에 병합할 필요가 있을 수 있다. 이에 따라, 전자 장치(100)는 개인 브랜치를 마스터 브랜치에 머지하는 요청을 확인함에 따라, 요청에 대응하는 개인 브랜치에 대한 버그 정보를 확인하고, 버그 정보에 기반하여 요청의 승인 여부를 결정할 수 있다. 이에 따라, 전자 장치(100)는 버그가 없다고 확인된 개인 브랜치만을 병합함으로써, 다른 사용자들도 공유하는 마스터 브랜치에 버그가 있는 소스 코드를 포함하는 개인 브랜치가 머지되는 것을 방지할 수 있다. 또한, 전자 장치(100)는 소스 코드가 변경되거나 개인 브랜치에 대응되는 버그 정보가 변경될 때, 개인 브랜치를 마스터 브랜치에 머지하는 요청의 승인 여부를 재결정할 수도 있다. 이에 대한 구체적인 실시 예는 하기에서 자세히 살펴보기로 한다,
도 2는 전자 장치가 소스 코드를 업로드하는 방법을 나타낸 흐름도이다.
도 2를 참조하면, 전자 장치(100)가 소스 코드를 업로드하는 각 동작은 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 명확하게 이해되는 범위 내에서 일부 동작이 변경, 치환되거나 동작 간의 일부 순서가 변경될 수 있음은 자명하게 이해될 수 있다.
단계 S210에서, 전자 장치(100)는 소스 코드를 포함하는 개인 브랜치를 마스터 브랜치에 머지하는 요청을 확인할 수 있다.
사용자는 단말(110)을 통해 로컬 저장소에 소스 코드를 작성하고, 저장할 수 있다. 보다 상세하게는, 사용자는 로컬 저장소에 작성된 소스 코드를 추가하여 저장할 수 있고, 기존에 로컬 저장소에 저장된 소스 코드를 업데이트하여 커밋함으로써, 소스 코드가 업데이트된 시간에 대한 정보에 업데이트된 소스 코드를 함께 저장할 수 있다.
또한, 사용자는 로컬 저장소에 저장된 소스 코드 중 일부를 원격 저장소의 개인 브랜치에 저장할 수 있다. 보다 상세하게는, 사용자는 로컬 저장소에 저장된 소스 코드 중 일부 소스 코드를 깃허브(github)의 마스터 브랜치에 머지하기 전에 개인용 원격 저장소에 저장된 개인 브랜치로 이동시킬 수 있다. 또한, 전자 장치(100)는 마스터 브랜치에서 개인 브랜치로 공유한 소스 코드를 풀(Pull) 또는 클론(clone)함으로써, 로컬 저장소에 해당 소스 코드를 다운로드 받을 수도 있다. 본원에서, 개인 브랜치는 사용자의 소스 코드의 개발에 이용되는 전용 브랜치이고, 마스터 브랜치는 사용자뿐만 아니라 다른 사용자의 소스 코드의 개발 및 다운로드에도 이용되는 공유 브랜치인 것을 특징으로 할 수 있다.
일 실시 예에 따르면, 전자 장치(100)는 소스 코드를 포함하는 개인 브랜치를 마스터 브랜치에 머지하는 요청을 확인할 수 있다. 보다 상세하게는, 전자 장치(100)는 소스 코드를 포함하는 개인 브랜치를 마스터 브랜치에 머지하는 풀 뤠크스트를 확인할 수 있다. 여기서, 소스 코드는 사용자의 단말에서 작성되어 사용자의 로컬 저장소에서 저장되어 있던 소스 코드로, 머지에 대한 요청이 승인되는 경우, 다른 사용자에게도 공유되는 소스 코드일 수 있다. 다만, 소스 코드에 에러가 있을 수 있는 바, 다른 사용자에게 공유해도 되는지에 관한 검증 프로세스가 요구될 수 있다. 이에 따라, 소스 코드를 포함하는 개인 브랜치에 대응하는 버그 정보에 기반하여, 소스 코드에 에러가 있는지를 확인하는 본원 실시 예에 대해 아래에서 자세히 살펴보기로 한다.
단계 S220에서, 전자 장치(100)는 개인 브랜치의 식별 정보를 확인할 수 있다.
일 실시 예에 따르면, 전자 장치(100)는 요청에 대응하여, 마스터 브랜치에 머지가 요청된 개인 브랜치를 다른 개인 브랜치와 구별하기 위한 식별 정보를 확인할 수 있다. 여기서, 개인 브랜치의 식별 정보는 개인 브랜치에 생성됨에 따라 자동으로 생성될 수 있다. 또한, 개인 브랜치의 식별 정보는 요청에 포함될 수 있으며, 동일한 사용자의 단말을 통해 생성된 개인 브랜치라도 상이한 개인 브랜치 간의 식별 정보는 상이할 수 있다. 본원에서, 개인 브랜치의 식별 정보는 개인 브랜치에 대응하는 버그 정보를 확인하기 위한 BTS(Bug Tracking System) 키일 수 있다.
단계 S230에서, 전자 장치(100)는 개인 브랜치의 식별 정보에 대응하는 개인 브랜치에 대한 버그 정보를 확인할 수 있다.
일 실시 예에 따르면, 전자 장치(100)는 개인 브랜치의 식별 정보에 대응하는 개인 브랜치의 버그 여부의 검증에 대한 정보인 버그 정보를 확인할 수 있다. 개인 브랜치에 대한 버그 정보를 포함하는 BTS 티켓은 개인 브랜치가 생성됨에 따라 시스템에 의해 자동으로 생성될 수 있다. 개인 브랜치에 포함되는 소스 코드가 생성될 때, 버그 정보와 관련된 BTS 티켓은 자동으로 생성될 수 있다. 다만, BTS 티켓에 포함되는 버그 정보는 소스 코드가 생성된 직후에는 해당 소스 코드에 버그가 있는지 여부에 대한 검증이 진행되지 않음을 나타낼 수 있으나, 이에 한정되는 것은 아니다. BTS 티켓에 포함되는 버그 정보는 QA(Quality Assurance) 단말 등을 통한 검증 결과에 따라 재설정되는 것을 특징으로 할 수 있다. 또한, BTS 티켓에 포함되는 버그 정보는 개인 브랜치를 마스터 브랜치에 머지하는 요청을 확인한 시점과 무관하게 QA(Quality Assurance) 단말 등을 통한 검증 결과에 따라 머지 요청 전 또는 후에 결정되는 것을 특징으로 할 수 있다.
BTS 티켓에 포함되는 버그 정보는 QA 단말 등을 통해 검증 결과에 따라 개인 브랜치의 버그 여부에 대한 상이한 상태 정보를 나타낼 수 있다. 예를 들어, 버그 정보는 Closed, Done, Ready for deploy, Ready for deployment, Ready for release, Open, In Progress, Resolved, In QA, Reopen 중 하나일 수 있으나, 이에 한정되는 것은 아니다.
여기서, 1) Closed는 QA 등에 의해 프로세스에 따라 버그가 없다고 결정되어 해당 BTS의 작업이 최종 완료된 상태를 나타낼 수 있다. 2) Done은 QA 또는 개인 브랜치의 개발자 등에 의해 버그 검증 여부에 대해 중간 확인이 완료된 상태를 나타낼 수 있다. 3) Ready for deploy, Ready for deployment 및 Ready for release는 개인 브랜치에 버그가 없다고 확인된 후, 개인 브랜치가 실행 또는 배포가 예정되어 있다는 것을 의미할 수 있다. 또한, 4) Open은 BTS에 의해 개인 브랜치에 대한 버그 검증 여부에 대한 프로세스가 오픈되었음을 나타낼 수 있다. 5) In Progress는 개발자에 의해 개인 브랜치에 버그가 있는지 여부가 검토되고 있음을 나타낼 수 있다 6) Resolved는 개발자 단계에서 버그가 없다고 확인되었음을 나타낼 수 있다. 또한, 7) In QA는 개발자 단계에서 버그가 없다고 확인됨에 따라 QA로부터 개인 브랜치에 버그가 있는지 여부에 대한 확인을 기다리는 단계를 나타낼 수 있다. 8) Reopen은 개발자 또는 QA에 의해 개인 브랜치에 오류가 있다고 확인되었음을 나타낼 수 있다. 이때, 소스 코드가 업데이트되거나 개발자 또는 QA에 의해 개인 브랜치에 오류가 있는지 여부를 재검증 받음을 통해, Reopen은 Resolved, Closed 등으로 변경될 수 있다.
단계 S240에서, 전자 장치(100)는 버그 정보에 기반하여, 요청의 승인 여부를 결정할 수 있다.
일 실시 예에 따르면, 전자 장치(100)는 확인된 버그 정보가 버그 정보에 대한 그룹에 포함되는지 여부에 따라, 요청의 승인 여부를 결정할 수 있다. 버그 정보에 대한 그룹은 개인 브랜치에 대한 검증이 확인된 버그 정보를 나타내는 그룹을 의미할 수 있다. 예를 들어, 전자 장치(100)는 확인된 버그 정보가 버그 정보에 대한 그룹인 Closed, Done, Ready for deploy, Ready for deployment, Ready for release에 포함되면, 요청의 승인을 결정할 수 있다. 또한, 전자 장치(100)는 확인된 버그 정보가 Open, In Progress, Resolved, In QA, Reopen 등 BTS 시스템에서 추가적인 프로세스가 요구되는 상태인 경우, 요청의 미승인을 결정할 수 있다.
단계 S250에서, 전자 장치(100)는 요청을 승인하면 개인 브랜치를 마스터 브랜치에 머지하고, 요청을 미승인하면 개인 브랜치의 마스터 브랜치로의 머지를 블락할 수 있다.
단계 S240에서, 요청의 승인 여부를 결정함에 따라 전자 장치(100)는 개인 브랜치의 마스터 브랜치로의 머지를 허용하거나 블락할 수 있다. 다만, QA 또는 개발자 등에 의해 버그 정보는 변경될 수 있는 바, 전자 장치(100)는 개인 브랜치의 마스터 브랜치로의 머지에 대한 승인 여부를 유동적으로 변경할 수 있다.
1) 예를 들어, 전자 장치(100)는 개인 브랜치에 대한 버그 정보에 기반하여 개인 브랜치의 마스터 브랜치로의 머지를 블락할 수 있다. 다만, QA 또는 개발자에 의해 버그 정보가 변경됨에 따라 개인 브랜치의 마스터 브랜치로의 머지에 대한 요청의 승인 여부를 재결정할 수 있다. 이때, 요청의 승인을 결정함에 따라, 전자 장치(100)는 개인 브랜치를 마스터 브랜치에 머지할 수 있다. 2) 예를 들어, 전자 장치(100)는 개인 브랜치에 대한 버그 정보에 기반하여 개인 브랜치를 마스터 브랜치에 머지할 수 있다. 다만, 개인 브랜치에 대한 버그 정보가 변경될 수 있다. 예를 들어, 소스 코드가 업데이트됨에 따라 변경된 소스 코드를 포함하는 개인 브랜치에 대한 버그 정보가 변경될 수 있다. 이에 따라, 전자 장치(100)는 변경된 버그 정보에 기반하여 개인 브랜치의 마스터 브랜치로의 머지에 대한 요청의 승인 여부를 재결정할 수 있다. 요청의 미승인을 결정함에 따라, 전자 장치(100)는 개인 브랜치의 마스터 브랜치로의 머지를 블락할 수 있다. 이와 관련된 구체적인 실시 예는 도 3에서 자세히 살펴보기로 한다.
도 3은 전자 장치가 개인 브랜치를 마스터 브랜치에 머지하거나 개인 브랜치의 마스터 브랜치로의 머지를 블락하는 구체적인 실시 예를 설명하기 위한 도면이다.
단계 S301에서, 전자 장치(100)는 소스 코드를 포함하는 개인 브랜치를 마스터 브랜치에 머지하는 요청을 확인할 수 있다. 이에 대응하여, 전자 장치(100)는 개인 브랜치의 식별 정보에 대응하는 개인 브랜치에 대한 버그 정보를 확인할 수 있다. 여기서, 개인 브랜치에 대한 버그 정보는 'In Progress'로, 현재 개인 브랜치에 버그가 있는지 여부에 대한 것은 QA 또는 개발자에 의해 확인되는 중일 수 있다.
단계 S302에서, 전자 장치(100)는 버그 정보에 기반하여, 요청의 승인 여부를 결정할 수 있다. 예를 들어, 전자 장치(100)는 개인 브랜치에 대한 버그 정보가 'In Progress'인 바, 개인 브랜치의 마스터 브랜치로의 머지에 대한 요청의 미승인을 결정할 수 있다.
단계 S303에서, 전자 장치(100)는 요청의 미승인을 결정함에 따라, 개인 브랜치의 마스터 브랜치로의 머지를 블락할 수 있다.
단계 S304에서, QA 또는 개발자는 개인 브랜치의 버그 여부를 검증할 수 있다. 예를 들어, 개인 브랜치에 대한 버그 정보가 'In Progress'인 바, QA 또는 개발자는 개인 브랜치에 포함되는 소스 코드에 버그가 있는지 여부를 추가적으로 검증할 수 있다.
단계 S305에서, 전자 장치(100)는 버그 정보의 변경을 확인할 수 있다. 예를 들어, 전자 장치(100)는 변경된 버그 정보를 'Closed'으로 확인할 수 있다. 본원에서, 변경된 버그 정보는 QA(Quality Assurance) 단말 또는 소스 코드를 개발한 사용자의 단말(110)을 통한 변경된 소스 코드에 대한 승인 여부에 따라 변경되는 정보일 수 있다.
단계 S306에서, 전자 장치(100)는 변경된 버그 정보에 기반하여 머지에 대한 요청의 승인 여부를 재결정할 수 있다. 예를 들어, 전자 장치(100)는 변경된 버그 정보인 'Closed'에 기반하여 머지에 대한 요청의 승인을 결정할 수 있다.
단계 S307에서, 요청이 승인됨에 따라, 전자 장치(100)는 개인 브랜치를 마스터 브랜치에 머지할 수 있다. 이에 따라, QA 및 개발자에 의해 검증이 완료된 소스 코드를 포함하는 개인 브랜치는 마스터 브랜치에 머지됨에 따라, 다른 사용자 또는 개발자들은 소스 코드를 포함하는 개인 브랜치를 다운로드하여 이용할 수 있다.
다만, 마스터 브랜치에 머지된 개인 브랜치에 포함되는 소스 코드가 변경되는 등에 따라 버그 정보가 변경되면, 개인 브랜치의 마스터 브랜치로의 머지에 대한 승인 여부는 변경될 수 있다.
단계 S308에서, 전자 장치(100)는 소스 코드의 변경을 확인할 수 있다. 예를 들어, 사용자가 개인 브랜치에 포함되는 소스 코드를 업데이트하거나 새로운 소스 코드를 푸시함에 따라, 전자 장치(100)는 소스 코드의 변경을 확인할 수 있다.
단계 S309에서, 전자 장치(100)는 변경된 소스 코드를 포함하는 개인 브랜치에 대한 버그 정보를 리셋할 수 있다. 소스 코드가 변경되면, 변경 전 소스 코드를 포함하는 개인 브랜치에 대한 버그 정보는 변경될 필요가 있다. 리셋에 따른 버그 정보는 버그 정보에 대한 디폴트 값일 수 있다. 예를 들어, 버그 정보에 대한 디폴트 값은 'Reopen'일 수 있으며, 전자 장치(100)는 리셋된 버그 정보를 'Reopen'으로 확인할 수 있다.
단계 S310에서, 전자 장치(100)는 요청의 승인 여부를 결정할 수 있다. 예를 들어, 전자 장치(100)는 리셋된 버그 정보에 기반하여, 요청의 미승인을 결 정할 수 있다.
단계 S311에서, 전자 장치(100)는 요청의 미승인을 결정함에 따라, 개인 브랜치의 마스터 브랜치로의 머지를 블락할 수 있다. 이에 따라, 전자 장치(100)는 변경된 소스 코드가 포함되는 개인 브랜치의 마스터 브랜치로의 머지를 블락할 수 있다.
단계 S312에서, QA 또는 개발자는 변경된 소스 코드를 포함하는 개인 브랜치의 버그 여부를 검증할 수 있다. 예를 들어, 개인 브랜치에 대한 버그 정보가 'Reopen'인 바, QA 또는 개발자는 개인 브랜치에 포함되는 소스 코드에 버그가 있는지 여부를 추가적으로 검증할 수 있다. QA 또는 개발자의 검증에 따라, 버그 정보가 변경될 수 있다. 예를 들어, 변경된 버그 정보는 'Closed'일 수 있다.
단계 S313에서, 전자 장치(100)는 변경된 버그 정보에 기반하여 머지에 대한 요청의 승인 여부를 재결정할 수 있다. 예를 들어, 전자 장치(100)는 변경된 버그 정보인 'Closed'에 기반하여 머지에 대한 요청의 재승인을 결정할 수 있다.
단계 S314에서, 요청이 재승인됨에 따라, 전자 장치(100)는 개인 브랜치를 마스터 브랜치에 머지할 수 있다. 변경된 소스 코드에 대해 검증이 완료됨에 따라, 전자 장치(100)는 변경된 소스 코드를 포함하는 개인 브랜치를 마스터 브랜치에 머지할 수 있다.
도 4는 버그 정보가 변경되는 구체적인 실시 예를 설명하기 위한 도면이다.
보다 상세하게는, 도 4는 개발자 및 QA로부터 개인 브랜치에 버그가 있는지 여부를 검증함에 따라 BTS 티켓에 포함되는 버그 정보가 변경되는 BTS 시스템(400)을 나타내고 있다. 도 4의 실시 예에 따른 BTS 시스템(400)은 1) 개발자 및 2) QA 순으로 버그 여부에 대한 검증 후에 버그 정보가 'Closed'되는 것을 특징으로 하고 있지만, 이에 한정되는 것은 아니다. 예를 들어, BTS 시스템(400)은 개발자 및 QA 중 하나로부터 버그 여부에 대한 검증을 수행할 수도 있다.
도 4를 참조하면, 개인 브랜치에 대한 버그 정보를 포함하는 BTS 티켓은 개인 브랜치가 생성됨에 따라 시스템에 의해 자동으로 생성될 수 있다. 구체적으로, 자동을 생성된 BTS 티켓에 포함되는 버그 정보는 디폴트 값으로, 'Open'일 수 있다.
개발자에 의해 개인 브랜치에 포함된 소스 코드에 버그가 있는지 여부를 검토하는 프로세스에 해당되면, 개인 브랜치에 대응하는 버그 정보는 'In Progress'일 수 있다. 1) 개발자 단계에서 개인 브랜치에 포함되는 소스 코드에 버그가 없다고 확인되면, 개인 브랜치에 대응하는 버그 정보는 'Resolved'일 수 있다. 반대로, 2) 개발자 단계에서 개인 브랜치에 포함되는 소스 코드에 버그가 있다고 확인되면, 개인 브랜치에 대응하는 버그 정보는 'Reopen'일 수 있다. 이때, 소스 코드가 업데이트되거나 개발자에 의해 소스 코드에 포함되는 개인 브랜치에 대한 재검증 프로세스에 해당되면, 버그 정보는 다시 'In Progress'가 될 수 있다.
개발자에 이어, QA에 의해 개인 브랜치에 포함된 소스 코드에 버그가 있는지 여부를 검토하는 프로세스에 해당되면, 개인 브랜치에 대응하는 버그 정보는 'In QA'일 수 있다. In QA는 개발자 단계에서 버그가 없다고 확인됨에 따라 QA로부터 개인 브랜치에 버그가 있는지 여부에 대한 확인을 기다리는 단계를 나타낼 수 있다. 1) QA 단계에서 개인 브랜치에 포함되는 소스 코드에 버그가 없다고 확인되면, 개인 브랜치에 대응하는 버그 정보는 'Ready for release'일 수 있다. 반대로, 2) QA 단계에서 개인 브랜치에 포함되는 소스 코드에 버그가 있다고 확인되면, 개인 브랜치에 대응하는 버그 정보는 'Reopen'일 수 있다. 이때, 소스 코드가 업데이트되거나 개발자에 의해 소스 코드에 포함되는 개인 브랜치에 대한 재검증 프로세스에 해당되면, 버그 정보는 다시 'In Progress'가 될 수 있다.
버그 정보가 'Ready for release'이면, 개인 브랜치는 다른 사용자에게 배포될 예정인 상태일 수 있다. 다만, QA 또는 개발자에 의해 개인 브랜치에 대응되는 버그가 있다고 판단됨에 따라, 버그 정보는 'Ready for release'에서 'Reopen'으로 변경될 수 있다. 다만, 버그 정보가 'Ready for release'인 단계를 거치지 않고, 버그 정보가 'In QA'에서 바로 'Closed'로 변경될 수 있다.
버그 정보가 'Closed'이면, QA 등에 의해 프로세스에 따라 버그가 없다고 결정되어 해당 BTS의 작업이 최종 완료된 상태를 나타낼 수 있다. 다만, 소스 코드가 변경되거나 QA 또는 개발자에 의해 소스 코드에 버그가 있다고 확인되면, 버그 정보는 'Closed'에서 'Reopen'로 변경될 수 있다.
도 5는 개인 브랜치에 포함되는 소스 코드를 수정하거나 개인 브랜치에 새로운 소스 코드를 푸시함에 따라, 마스터 브랜치에 머지되는 개인 브랜치의 변경을 설명하기 위한 도면이다.
도 5는 마스터 브랜치에 머지되는 개인 브랜치의 변경에 따른 커밋을 설명하기 위한 화면(500)을 나타내고 있다.
마스터 브랜치에 머지되는 개인 브랜치는 개인 브랜치에 포함되는 소스 코드를 수정하거나 개인 브랜치에 새로운 소스 코드를 푸시함에 따라, 개인 브랜치에 대응되는 버그 정보는 리셋될 수 있다. 마스터 브랜치에 머지된 개인 브랜치에 포함되는 소스 코드에 변경이 있는 경우, 커밋에 따른 소스 코드의 변경된 내역이 화면(500)과 같이 저장될 수 있다. 또한, 소스 코드의 변경에 대응되는 변경된 버그 정보를 확인하기 위한 식별 정보도 함께 저장될 수 있다. 예를 들어, 개인 브랜치의 식별 정보는 개인 브랜치에 대응되는 버그 정보를 확인하기 위한 BTS 키일 수 있다. 도 5를 참조하면, 개인 브랜치의 식별 정보는 'FRES-1103'일 수 있다. 예를 들어, 제1 커밋(510)은 'Video Review Carousel on Fresh Home See More'에 관한 것일 수 있다.
마스터 브랜치에 머지된 개인 브랜치에 포함되는 소스 코드는 꼭 하나의 개발자에 의해 변경되는 것은 아닐 수 있다. 예를 들어, 소스 코드에 포함되는 개인 브랜치가 개발자 A를 통한 풀 뤼퀘스트에 따라 마스터 브랜치에 머지되게 되면, 개발자 A뿐만 아니라 다른 개발자도 개인 브랜치를 공유할 수 있다. 이에 따라, 개발자 B는 소스 코드를 포함하는 개인 브랜치를 다운로드하여 이를 수정할 수 있다. 예를 들어, 도 5를 참조하면, 개인 브랜치의 변경은 개발자 A 또는 개발자 B에 의해 실행됨을 확인할 수 있다. 따라서, 소스 코드는 사용자(개발자 A에 대응)의 단말에서 작성된 소스 코드이고, 소스 코드의 변겨은 제1 사용자(개발자 B에 대응)의 제1 단말에서 변경된 것을 특징으로 할 수 있다.
도 6은 개인 브랜치에 대응하는 BTS 티켓 및 BTS 티켓에 포함되는 버그 정보를 설명하기 위한 도면이다.
개인 브랜치에 대한 버그 정보를 포함하는 BTS 티켓(600)은 개인 브랜치가 생성됨에 따라 시스템에 의해 자동으로 생성될 수 있다. BTS 티켓(600)은 개인 브랜치의 식별 정보를 포함할 수 있다. 예를 들어, BTS 티켓(600)은 도 5의 식별 정보인 'FRES-1103'(610)을 포함할 수 있다. 이에 따라, 전자 장치(100)는 식별 정보인 'FRES-1103'(610)에 기반하여, 복수 개의 BTS 티켓 중 개인 브랜치에 대응하는 BTS 티켓(600)을 확인할 수 있다. 여기서, BTS 티켓(600)은 'Video Review Carousel on Fresh Home See More'에 관한 도 5의 제1 커밋(510)에 대응될 수 있다.
또한, BTS 티켓(600)은 도 5 의 개인 브랜치에 대한 버그 정보를 포함할 수 있다. 예를 들어, BTS 티켓(600)에 포함되는 버그 정보는 'Ready for release'일 수 있다. 따라서, 현재 개인 브랜치에 대응되는 버그 정보는 'Ready for release'로, 개인 브랜치의 마스터 브랜치로의 머지가 재승인됨에 따라, 전자 장치(100)는 개인 브랜치를 마스터 브랜치로 머지할 수 있다.
도 7은 일 실시 예에 따른 페이지를 제공하기 위한 전자 장치를 도식화한 블록도이다.
도 7의 전자 장치(700)는 본원 명세서의 전자 장치(100)에 대응될 수 있다.
본 개시의 전자 장치(700)는 일 실시 예에 따라, 트랜시버(710), 프로세서(720) 및 스토리지(730)를 포함할 수 있다. 도 7에 도시된 구성요소들은 전자 장치를 구현하는데 있어서 필수적인 것은 아니어서, 본 명세서 상에서 설명되는 전자 장치(700)는 위에서 열거된 구성요소들 보다 많거나, 또는 적은 구성요소들을 가질 수 있음을 본 실시 예와 관련된 기술분야에서 통상의 지식을 가진 자라면 이해할 수 있다. 한편 실시 예에서 프로세서(720)는 적어도 하나의 프로세서를 포함할 수 있다.
트랜시버(710)는 유무선 통신 기술을 이용하여 외부의 장치와 통신할 수 있으며 트랜시버(710)를 포함할 수 있다. 외부의 장치는 단말 또는 서버가 될 수 있다. 또한, 트랜시버(710)가 이용하는 통신 기술에는 GSM(Global System for Mobile communication), CDMA(Code Division Multi Access), LTE(Long Term Evolution), 5G, WLAN(Wireless LAN), Wi-Fi(Wireless-Fidelity), 블루투스(Bluetooth), RFID(Radio Frequency Identification), 적외선 통신(Infrared Data Association; IrDA), ZigBee, NFC(Near Field Communication) 등이 있을 수 있으며, 이에 한정되는 것은 아니다.
일 실시 예에 따라, 트랜시버(710)는 소스 코드를 포함하는 개인 브랜치를 마스터 브랜치에 머지하는 요청에 대한 신호를 수신할 수 있다. 또한, 트랜시버(710)는 다른 단말로부터 마스터 브랜치에 머지된 개인 브랜치에 대한 다운로드 요청을 수신함에 따라 단말에 소스 코드를 포함하는 개인 브랜치를 전송할 수 있다.
프로세서(720)는 전자 장치(700)의 전반적인 동작을 제어하고 데이터 및 신호를 처리할 수 있다. 프로세서(720)는 도 1 내지 도 6을 통하여 전술한 하나의 방법을 수행할 수 있다. 프로세서(720)는 트랜시버(710) 및 스토리지(730)와, 나아가 전자 장치(700)가 더 포함할 수 있는 구성요소들과의 상호 작용을 통해 전자 장치(700)가 수행하는 실시 예들을 제어할 수 있다. 일 실시 예에 따라, 프로세서(720)는 소스 코드를 포함하는 개인 브랜치를 마스터 브랜치에 머지하는 요청을 확인하고, 개인 브랜치의 식별 정보를 확인하고, 개인 브랜치의 식별 정보에 대응하는 개인 브랜치에 대한 버그 정보를 확인하고, 버그 정보에 기반하여, 요청의 승인 여부를 결정하고, 및 요청을 승인하면 개인 브랜치를 마스터 브랜치에 머지하고, 요청을 미승인하면 개인 브랜치의 마스터 브랜치로의 머지를 블락할 수 있다.
스토리지(730)는 도 1 내지 도 6을 통하여 전술한 적어도 하나의 방법을 수행하기 위한 정보를 저장할 수 있다. 스토리지(730)는 메모리로 호칭될 수 있고, 휘발성 메모리 또는 비휘발성 메모리일 수 있다. 또한, 스토리지(730)는 프로세서(1520)의 동작을 수행하는데 필요한 하나 이상의 명령어를 저장할 수 있고, 플랫폼 상에 저장되거나 외부 메모리에 저장되는 데이터를 임시적으로 저장할 수 있다. 예를 들어, 스토리지(730)는 개인 브랜치의 식별 정보, 개인 브랜치에 대한 버그 정보 및 요청의 승인 여부를 결정하는데 이용되는 설정된 버그 정보에 대한 그룹 정보를 포함할 수 있다. 이외에도, 스토리지(730)는 프로세서(720)에 의해 확인된 정보를 임시적으로 저장할 수 있다.
한편, 본 명세서와 도면에는 본 발명의 바람직한 실시 예에 대하여 개시하였으며, 비록 특정 용어들이 사용되었으나, 이는 단지 본 발명의 기술 내용을 쉽게 설명하고 발명의 이해를 돕기 위한 일반적인 의미에서 사용된 것이지, 본 발명의 범위를 한정하고자 하는 것은 아니다. 여기에 개시된 실시 예 외에도 본 발명의 기술적 사상에 바탕을 둔 다른 변형 예들이 실시 가능하다는 것은 본 발명이 속하는 기술 분야에서 통상의 지식을 가진 자에게 자명한 것이다.
전술한 실시 예들에 따른 전자 장치 또는 단말은, 프로세서, 프로그램 데이터를 저장하고 실행하는 메모리, 디스크 드라이브와 같은 영구 저장부(permanent storage), 외부 장치와 통신하는 통신 포트, 터치 패널, 키(key), 아이콘 등과 같은 사용자 인터페이스 장치 등을 포함할 수 있다. 소프트웨어 모듈 또는 알고리즘으로 구현되는 방법들은 상기 프로세서상에서 실행 가능한 컴퓨터가 읽을 수 있는 코드들 또는 프로그램 명령들로서 컴퓨터가 읽을 수 있는 기록 매체 상에 저장될 수 있다. 여기서 컴퓨터가 읽을 수 있는 기록 매체로 마그네틱 저장 매체(예컨대, ROM(read-only memory), RAM(random-Access memory), 플로피 디스크, 하드 디스크 등) 및 광학적 판독 매체(예컨대, 시디롬(CD-ROM), 디브이디(DVD: Digital Versatile Disc)) 등이 있다. 컴퓨터가 읽을 수 있는 기록 매체는 네트워크로 연결된 컴퓨터 시스템들에 분산되어, 분산 방식으로 컴퓨터가 판독 가능한 코드가 저장되고 실행될 수 있다. 매체는 컴퓨터에 의해 판독가능하며, 메모리에 저장되고, 프로세서에서 실행될 수 있다.
본 실시 예는 기능적인 블록 구성들 및 다양한 처리 단계들로 나타내어질 수 있다. 이러한 기능 블록들은 특정 기능들을 실행하는 다양한 개수의 하드웨어 또는/및 소프트웨어 구성들로 구현될 수 있다. 예를 들어, 실시 예는 하나 이상의 마이크로프로세서들의 제어 또는 다른 제어 장치들에 의해서 다양한 기능들을 실행할 수 있는, 메모리, 프로세싱, 로직(logic), 룩 업 테이블(look-up table) 등과 같은 직접 회로 구성들을 채용할 수 있다. 구성 요소들이 소프트웨어 프로그래밍 또는 소프트웨어 요소들로 실행될 수 있는 것과 유사하게, 본 실시 예는 데이터 구조, 프로세스들, 루틴들 또는 다른 프로그래밍 구성들의 조합으로 구현되는 다양한 알고리즘을 포함하여, C, C++, 자바(Java), 어셈블러(assembler), 파이썬(Python) 등과 같은 프로그래밍 또는 스크립팅 언어로 구현될 수 있다. 기능적인 측면들은 하나 이상의 프로세서들에서 실행되는 알고리즘으로 구현될 수 있다. 또한, 본 실시 예는 전자적인 환경 설정, 신호 처리, 및/또는 데이터 처리 등을 위하여 종래 기술을 채용할 수 있다. “매커니즘”, “요소”, “수단”, “구성”과 같은 용어는 넓게 사용될 수 있으며, 기계적이고 물리적인 구성들로서 한정되는 것은 아니다. 상기 용어는 프로세서 등과 연계하여 소프트웨어의 일련의 처리들(routines)의 의미를 포함할 수 있다.
전술한 실시 예들은 일 예시일 뿐 후술하는 청구항들의 범위 내에서 다른 실시 예들이 구현될 수 있다.

Claims (13)

  1. 전자 장치에서 소스 코드를 업로드하는 방법에 있어서,
    상기 소스 코드를 포함하는 개인 브랜치를 마스터 브랜치에 머지하는 요청을 확인하는 단계;
    상기 개인 브랜치의 식별 정보를 확인하는 단계;
    상기 개인 브랜치의 식별 정보에 대응하는 상기 개인 브랜치에 대한 버그 정보를 확인하는 단계;
    상기 버그 정보에 기반하여, 상기 요청의 승인 여부를 결정하는 단계; 및
    상기 요청을 승인하면 상기 개인 브랜치를 상기 마스터 브랜치에 머지하고, 상기 요청을 미승인하면 상기 개인 브랜치의 상기 마스터 브랜치로의 머지를 블락하는 단계를 포함하는 소스 코드를 업로드하는 방법.
  2. 제1항에 있어서,
    상기 개인 브랜치는 사용자의 소스 코드의 개발에 이용되는 전용 브랜치이고, 및
    상기 마스터 브랜치는 다른 사용자의 소스 코드의 개발 및 다운로드에도 이용되는 공유 브랜치인 것을 특징으로 하는 소스 코드를 업로드하는 방법.
  3. 제1항에 있어서,
    상기 개인 브랜치에 대한 버그 정보를 확인하는 단계는,
    상기 요청에 포함되는 상기 식별 정보에 기반하여, 상기 식별 정보에 대응되는 상기 버그 정보를 확인하는 단계를 포함하는 소스 코드를 업로드하는 방법.
  4. 제1항에 있어서,
    상기 요청의 승인 여부를 결정하는 단계는,
    상기 버그 정보가 설정된 버그 정보에 대한 그룹에 포함되는지 여부에 따라, 상기 요청의 승인 여부를 결정하는 단계를 포함하는 소스 코드를 업로드하는 방법.
  5. 제1항에 있어서,
    상기 개인 브랜치의 상기 마스터 브랜치로의 머지를 블락하는 단계는,
    상기 버그 정보의 변경을 확인하는 단계;
    상기 변경된 버그 정보에 기반하여, 상기 요청의 승인 여부를 재결정하는 단계; 및
    상기 요청을 승인하면 상기 개인 브랜치를 상기 마스터 브랜치에 머지하는 단계를 더 포함하는 소스 코드를 업로드하는 방법.
  6. 제1항에 있어서,
    상기 개인 브랜치를 상기 마스터 브랜치에 머지하는 단계는,
    상기 소스 코드의 변경을 확인하는 단계; 및
    상기 변경된 소스 코드를 포함하는 상기 개인 브랜치의 상기 마스터 브랜치로의 머지를 블락하는 단계를 더 포함하는 소스 코드를 업로드하는 방법.
  7. 제6항에 있어서,
    상기 변경된 소스 코드를 포함하는 상기 개인 브랜치의 상기 마스터 브랜치로의 머지를 블락하는 단계는,
    상기 소스 코드가 변경됨에 따라, 상기 버그 정보를 리셋하는 단계;
    상기 리셋된 버그 정보에 기반하여, 상기 요청의 미승인을 결정하는 단계; 및
    상기 요청을 미승인함에 따라 상기 변경된 소스 코드를 포함하는 상기 개인 브랜치의 상기 마스터 브랜치로의 머지를 블락하는 단계를 포함하는 소스 코드를 업로드하는 방법.
  8. 제7항에 있어서,
    상기 요청을 미승인함에 따라 상기 변경된 소스 코드를 포함하는 상기 개인 브랜치의 상기 마스터 브랜치로의 머지를 블락하는 단계는,
    상기 변경된 소스 코드에 대응하는 변경된 버그 정보를 확인하는 단계;
    상기 변경된 버그 정보에 기반하여, 상기 요청을 재승인하는 단계; 및
    상기 요청을 재승인하면 상기 개인 브랜치를 상기 마스터 브랜치에 머지하는 단계를 더 포함하는 소스 코드를 업로드하는 방법.
  9. 제8항에 있어서,
    상기 변경된 버그 정보는 QA(Quality Assurance) 단말 또는 상기 소스 코드를 개발한 사용자의 단말을 통한 상기 변경된 소스 코드에 대한 승인 여부에 따라 변경되는 정보인 것을 특징으로 하는 소스 코드를 업로드하는 방법.
  10. 제1항에 있어서,
    상기 소스 코드는 사용자의 단말에서 작성된 소스 코드이고, 및
    상기 요청을 승인한 경우, 제1 사용자의 제1 단말로부터 상기 마스터 브랜치에 머지된 상기 개인 브랜치에 대한 다운로드 요청을 수신함에 따라 상기 제1 단말에 상기 소스 코드를 포함하는 상기 개인 브랜치를 제공하는 단계를 더 포함하는 소스 코드를 업로드하는 방법.
  11. 제6항에 있어서,
    상기 소스 코드는 사용자의 단말에서 작성된 소스 코드이고, 및 상기 소스 코드의 변경은 제1 사용자의 제1 단말에서 변경된 것을 특징으로 하는 소스 코드를 업로드하는 방법.
  12. 소스 코드를 업로드하기 위한 전자 장치에 있어서,
    트랜시버;
    하나 이상의 명령어를 저장하는 스토리지; 및
    상기 소스 코드를 포함하는 개인 브랜치를 마스터 브랜치에 머지하는 요청을 확인하고,
    상기 개인 브랜치의 식별 정보를 확인하고,
    상기 개인 브랜치의 식별 정보에 대응하는 상기 개인 브랜치에 대한 버그 정보를 확인하고,
    상기 버그 정보에 기반하여, 상기 요청의 승인 여부를 결정하고, 및
    상기 요청을 승인하면 상기 개인 브랜치를 상기 마스터 브랜치에 머지하고, 상기 요청을 미승인하면 상기 개인 브랜치의 상기 마스터 브랜치로의 머지를 블락하는 프로세서를 포함하는 소스 코드를 업로드하기 위한 전자 장치.
  13. 제1항의 방법을 컴퓨터에서 실행시키기 위한 프로그램을 기록한 컴퓨터로 읽을 수 있는 비일시적 기록매체.
PCT/KR2022/012967 2022-08-19 2022-08-30 소스 코드를 업로드하는 방법 및 장치 WO2024038944A1 (ko)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
KR10-2022-0103944 2022-08-19
KR1020220103944A KR20240025825A (ko) 2022-08-19 2022-08-19 소스 코드를 업로드하는 방법 및 장치

Publications (1)

Publication Number Publication Date
WO2024038944A1 true WO2024038944A1 (ko) 2024-02-22

Family

ID=89941887

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/KR2022/012967 WO2024038944A1 (ko) 2022-08-19 2022-08-30 소스 코드를 업로드하는 방법 및 장치

Country Status (3)

Country Link
KR (1) KR20240025825A (ko)
TW (1) TW202422324A (ko)
WO (1) WO2024038944A1 (ko)

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20160000761A (ko) * 2014-06-25 2016-01-05 주식회사 포워드벤처스 소스 관리 장치, 시스템 및 방법, 컴퓨터 판독 가능한 기록 매체
CN107678773A (zh) * 2017-09-28 2018-02-09 郑州云海信息技术有限公司 一种基于git的代码开发与测试流程管理方法
CN107728996A (zh) * 2017-10-11 2018-02-23 郑州云海信息技术有限公司 一种git分支管理方法及装置
US20210089297A1 (en) * 2019-09-20 2021-03-25 Sungard Availability Services, Lp Automated check for ticket status of merged code
CN113190447A (zh) * 2021-04-30 2021-07-30 成都新潮传媒集团有限公司 一种代码自动合并的方法、装置、设备及存储介质

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20160000761A (ko) * 2014-06-25 2016-01-05 주식회사 포워드벤처스 소스 관리 장치, 시스템 및 방법, 컴퓨터 판독 가능한 기록 매체
CN107678773A (zh) * 2017-09-28 2018-02-09 郑州云海信息技术有限公司 一种基于git的代码开发与测试流程管理方法
CN107728996A (zh) * 2017-10-11 2018-02-23 郑州云海信息技术有限公司 一种git分支管理方法及装置
US20210089297A1 (en) * 2019-09-20 2021-03-25 Sungard Availability Services, Lp Automated check for ticket status of merged code
CN113190447A (zh) * 2021-04-30 2021-07-30 成都新潮传媒集团有限公司 一种代码自动合并的方法、装置、设备及存储介质

Also Published As

Publication number Publication date
TW202422324A (zh) 2024-06-01
KR20240025825A (ko) 2024-02-27

Similar Documents

Publication Publication Date Title
WO2018135766A1 (ko) 블록 체인을 이용하여 데이터를 관리하는 장치 및 방법
US20190312952A1 (en) Method and System for Mobile Applications Update in the Cloud
US8601599B2 (en) Platform security apparatus and method thereof
WO2017030252A1 (ko) 컨테이너 이미지 보안 검사 방법 및 그 장치
US10346161B2 (en) Automatic detection of potential merge errors
CN110096424B (zh) 测试的处理方法、装置、电子设备及存储介质
US12032939B2 (en) Automated machine deployment and configuration
CN113434158A (zh) 一种大数据组件的自定义管理方法、装置、设备及介质
WO2024038944A1 (ko) 소스 코드를 업로드하는 방법 및 장치
US20230328062A1 (en) Management of shared authentication credentials
US20230161604A1 (en) Automatic machine deployment and configuration
US20170357494A1 (en) Code-level module verification
US9069643B1 (en) Creating a prerequisite checklist corresponding to a software application
US11593098B2 (en) Synchronization of source code under development in multiple concurrent instances of an integrated development environment
WO2024147400A1 (ko) 불변성을 검증하는 전자 장치 및 그 방법
WO2023249156A1 (ko) 코드 정보 제공을 위한 전자 장치 및 그 방법
WO2024025023A1 (ko) 서비스와 관련된 테스트를 관리하는 방법 및 장치
WO2024128402A1 (ko) 데이터를 제공하는 방법 및 장치
KR102023424B1 (ko) 어플리케이션 사용환경 설정방법 및 이를 이용한 테스트방법
WO2024063183A1 (ko) 테스트를 수행하기 위한 방법 및 장치
WO2024106621A1 (ko) 스크립트와 관련한 정보를 제공하는 전자 장치 및 그 방법
WO2014098293A1 (ko) 어플리케이션 실행 제어 방법 및 어플리케이션 실행 여부 판별 방법과 이를 실행하기 위한 프로그램을 기록한 컴퓨터로 판독가능한 기록매체
WO2024038939A1 (ko) 서비스와 관련된 인공 지능 모델을 관리하는 방법 및 장치
WO2018194217A1 (ko) 문서의 저장 위치를 제어하기 위한 방법
WO2024147403A1 (ko) 가상의 테스트 정보에 기반하여 시스템에 대한 테스트 방법 및 이를 수행하는 전자 장치

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22955816

Country of ref document: EP

Kind code of ref document: A1