Electronic apparatus, deploying codes method, and non-transitory computer-readable recording medium comprising a computer program for performing the method

Abstract

The present invention provides a code deployment method for an electronic device. The code deployment method may include the following steps: performing a first test on a first code received from a first terminal that is related to a first function; merging the first code that passes the first test into an integration branch; performing a second test on a plurality of functions corresponding to a plurality of codes including the first code, wherein the plurality of codes are merged into the integration branch; and merging a second code that meets set conditions into a main branch, wherein the second code is one or more codes corresponding to one or more functions that pass the second test.

Description

Technical Field

[0001] This invention relates to an electronic device and its control method that automates tasks manually performed by operators during continuous integration / deployment, thereby efficiently implementing the continuous integration / deployment process. Prior Technology

[0002] Before deploying an application, developers need to conduct various tests to ensure that the application meets the required functionality, performance, usability, and stability. Furthermore, to add new features not present in the existing application while providing services to customers, a continuous integration / continuous deployment (CI / CD) process is required. However, many tasks in continuous integration / continuous deployment require user confirmation or approval, leading to low productivity and efficiency. Summary of the Invention

[0003] [The problem the invention aims to solve] The disclosed embodiments aim to provide an electronic device and a method for deploying code therein. More specifically, the object is to provide an electronic device and a method for controlling it that automates tasks manually performed by operators during continuous integration / deployment, thereby efficiently implementing the continuous integration / deployment process.

[0004] The technical problem to be solved in this embodiment is not limited to the technical problem described above. Other technical problems can be deduced from the following embodiments. [Technical means to solve the problem]

[0005] One aspect of the present invention provides a code deployment method, comprising the following steps: performing a first test on first code received from a first terminal that is related to a first function; merging the first code that passes the first test into an integration branch; performing a second test on a plurality of functions corresponding to a plurality of codes including the first code, wherein the plurality of codes are merged into the integration branch; and merging second code that meets set conditions into a main branch, wherein the second code is one or more codes corresponding to one or more functions that pass the second test.

[0006] Furthermore, in one embodiment of the present invention, a code deployment method may be provided, wherein the step of performing the second test on the plurality of functions includes the following steps: confirming whether the plurality of functions have data dependencies; and performing a first function test on the second function with data dependencies among the plurality of functions based on mock data, and performing a second function test on the third function without data dependencies among the plurality of functions.

[0007] Furthermore, in one embodiment of the present invention, a code deployment method may be provided, wherein the second functional test is performed in a simulated environment that is set up in the same way as the actual service environment in the form of no data traffic. The simulated environment is configured with the same server specifications, terminal specifications, network speed and security settings as the actual service environment.

[0008] Furthermore, in one embodiment of the present invention, a code deployment method may be provided, wherein the first functional test and the second functional test include at least one of the following functional tests: whether the existing functions are implemented normally when the plurality of functions are newly implemented; whether the API (application programming interface) calls used to implement the plurality of functions are implemented normally; whether the plurality of functions are displayed normally on the display; and whether the simulated data is loaded normally.

[0009] Furthermore, in one embodiment of the present invention, a code deployment method may be provided, wherein the first test includes at least one of the following tests: a quality test of the first code; a security test of the first code; a parity test of the first code; and a test of the form of the pull request of the first code.

[0010] Furthermore, in one embodiment of the present invention, a code deployment method may be provided, wherein the step of merging the second code into the main branch includes the following steps: implementing one or more of the functions in a plurality of test environments with different data flow ratios set; confirming the value of the metric identified when implementing one or more of the functions; and confirming that the second code whose value of the metric has not reached the set threshold satisfies the set conditions.

[0011] Furthermore, in one embodiment of the present invention, a code deployment method may be provided, wherein the plurality of test environments include a first test environment with a data traffic ratio set to a first value and a second test environment with a data traffic ratio set to a second value, wherein the first value is set to be less than the second value.

[0012] Furthermore, in one embodiment of the present invention, a code deployment method may be provided, wherein the first value is determined based on at least one of the following: the type of page that implements the above-mentioned one or more functions; the area that provides the above-mentioned one or more functions; the capacity of the data required to implement the above-mentioned one or more functions; the type of data required to implement the above-mentioned one or more functions; and the dependency of the above-mentioned one or more functions on other functions.

[0013] Furthermore, in one embodiment of the present invention, a code deployment method may be provided, wherein the values ​​of the above-mentioned metrics include at least one of the following: the delay time generated when implementing the above-mentioned one or more functions; the number of requests received within a set time for the type of page implementing the above-mentioned one or more functions; the memory utilization rate corresponding to the implementation of the above-mentioned one or more functions; the CPU (central processing unit) utilization rate corresponding to the implementation of the above-mentioned one or more functions; and the number of errors generated in the web server.

[0014] Furthermore, in one embodiment of the present invention, a code deployment method may be provided, wherein the aforementioned threshold is determined based on at least one of the following: the type of page that implements the above-mentioned one or more functions; the area that provides the above-mentioned one or more functions; the capacity of the data required to implement the above-mentioned one or more functions; the type of data required to implement the above-mentioned one or more functions; and the dependency of the above-mentioned one or more functions on other functions.

[0015] Furthermore, in one embodiment of the present invention, a code deployment method may be provided, which further includes the following steps: rolling back the third code among the above-mentioned one or more codes that does not meet the above-set conditions.

[0016] Another aspect of the present invention provides an electronic device comprising: a transceiver; a memory; and a processor; wherein the processor performs the following: performs a first test on a first code received from a first terminal that is related to a first function; merges the first code that passes the first test into an integration branch; performs a second test on a plurality of functions corresponding to a plurality of codes including the first code, the plurality of codes being merged into the integration branch; and merges second code that meets set conditions into a main branch, the second code being one or more codes corresponding to one or more functions that pass the second test.

[0017] Another aspect of the present invention provides a computer-readable recording medium that records a program useful for implementing a method carried out by an electronic device.

[0018] Specific details of other embodiments are included in the detailed description and drawings. [Effects of the Invention]

[0019] Based on the proposed embodiments, one or more of the following effects can be expected.

[0020] According to embodiments of this specification, electronic devices merge functional branches into an integrated branch that is maintained regardless of the release cycle, and test multiple functions in the same test environment, thereby maximizing the flexibility and productivity of the development process.

[0021] The effects of the invention are not limited to those mentioned above. Those skilled in the art can clearly understand other effects not mentioned based on the description in the patent application. Simple Explanation of the Diagram

[0022] Figure 1 illustrates a system according to one embodiment. Figure 2 is a diagram illustrating the process of deploying user-written code in an electronic device according to an embodiment. Figure 3 is a diagram illustrating the process of deploying user-written code in an electronic device according to an embodiment. Figure 4 is a diagram illustrating the process of deploying user-written code in an electronic device according to an embodiment. Figure 5 is a diagram illustrating the process of deploying user-written code in an electronic device according to an embodiment. Figure 6 is a flowchart illustrating a code deployment method for an electronic device according to an embodiment. Figure 7 is a block diagram illustrating an embodiment of an electronic device. Implementation

[0023] The terminology used in the embodiments is selected as widely used and common terms as possible while considering the functions of this invention. However, it may vary depending on the intentions or precedents of those skilled in the art, the emergence of new technologies, etc. Furthermore, in certain situations, there may be terms arbitrarily chosen by the applicant; in such cases, their meanings will be described in detail in the corresponding description. Therefore, the terminology used in this invention should be defined based on its meaning and the overall content of the invention, rather than simply based on the name of the term.

[0024] Throughout this specification, when a part is described as "including" a certain constituent element, it means that other constituent elements may be included, rather than excluded, unless otherwise stated.

[0025] The expression "at least one of a, b and c" as used throughout the specification may include "a alone", "b alone", "c alone", "a and b", "a and c", "b and c", or "all three of a, b and c".

[0026] The term "terminal" as used below can refer to a computer or a portable terminal that can connect to a server or other terminal via a network. Here, a computer includes, for example, a laptop, desktop, or tablet computer equipped with a web browser. A portable terminal, as a wireless communication device ensuring portability and mobility, can include, for example, IMT (International Mobile Telecommunication), CDMA (Code Division Multiple Access), W-CDMA (W-Code Division Multiple Access), LTE (Long Term Evolution) communication terminals, as well as all types of handheld wireless communication devices such as smartphones and tablets.

[0027] Hereinafter, embodiments of the present invention will be described in detail with reference to the accompanying drawings, so that those skilled in the art can easily implement the invention. However, the present invention can be implemented in various different forms and is not limited to the embodiments described herein.

[0028] Hereinafter, embodiments of the present invention will be described in detail with reference to the drawings.

[0029] Figure 1 illustrates a system according to one embodiment.

[0030] Referring to FIG1, the system may include at least one of electronic device 100, one or more user terminals 120, 140, 160, and network 180. On the other hand, the system shown in FIG1 only illustrates the components relevant to this embodiment. Therefore, those skilled in the art related to this embodiment will understand that, in addition to the components shown in FIG1, other common components may be included.

[0031] Electronic device 100 is a device that constitutes and provides various types of information. Electronic device 100 can provide the constituted information through web pages or application screens, or the information can be provided in the form of information displayed on web pages or application screens in a receiving terminal.

[0032] According to one embodiment, electronic device 100 can merge user-written code into code used to implement an application and deploy the application with the merged code. For example, electronic device 100 can perform a first test on first code related to a first function received from a first terminal; and merge the first code that passes the first test into an integration branch. Then, electronic device 100 can perform a second test on a plurality of functions corresponding to a plurality of codes including the first code merged into the integration branch, and merge the second code that meets set conditions into the main branch. This second code is one or more codes corresponding to one or more functions that pass the second test.

[0033] One or more user terminals 120, 140, and 160 serve as terminals for each user, who can access services provided via network 180 using their respective user terminals 120, 140, and 160. For example, users can input codes to perform specific functions using their respective user terminals 120, 140, and 160, and user terminals 120, 140, and 160 can send pull requests, including the input codes, to electronic device 100.

[0034] One or more user terminals 120, 140, 160 and electronic devices 100 can communicate with each other within network 180. Network 180 includes local area networks (LANs), wide area networks (WANs), value-added networks (VANs), mobile radio communication networks, satellite communication networks, and combinations thereof. This network is a comprehensive data communication network that enables the constituent entities of the networks shown in Figure 1 to communicate smoothly with each other. It may include wired internet, wireless internet, and mobile wireless communication networks. Wireless communication may include, for example, wireless LAN (Wi-Fi), Bluetooth, Bluetooth Low Energy, Wi-Fi Direct (WFD), UWB (ultra-wideband), infrared data association (IrDA), NFC (near field communication), etc., but is not limited to these.

[0035] Figure 2 is a diagram illustrating the process of deploying user-written code in an electronic device 100 according to an embodiment.

[0036] In step S200, according to one embodiment, the electronic device 100 may receive a first code related to the first function from the first user terminal 120. For example, the user may input the following codes to the first user terminal 120: a code for changing the position of text on a specific page of an application, a code for displaying a specific image on a specific page of an application, or a code for implementing a specific function on a specific page of an application. The first user terminal 120 may send the user-inputted code to the electronic device 100.

[0037] In step S210, according to one embodiment, upon confirmation that the first code has passed the first test, the electronic device 100 may merge the first code into the integration branch. More specifically, the electronic device 100 may perform at least one of the following tests: a quality test of the first code, a security test of the first code, a parity test of the first code, and a pull request form test of the first code, and upon confirmation that the first code has passed all the performed tests, the first code is merged into the integration branch.

[0038] For example, electronic device 100 can use tools such as SonarQube to perform tests to: confirm code quality such as complexity, repetitiveness, code style violations, and potential errors; or identify security vulnerabilities by detecting higher-level security risks in OWASP (Open Web Application Security Project) (e.g., SQL Injection, XSS). Alternatively, electronic device 100 can perform tests to: verify whether the refactored code functions the same as the existing functionality or confirm whether the code changes function as expected; or confirm whether the commit message, pull request title and description, code format, etc., conform to the rules. Afterwards, once the first code has passed all the implemented tests, electronic device 100 can merge the first code into the integration branch.

[0039] At this point, integration branches are used to merge the work done in multiple functional branches, coordinate changes between them, and conduct tests. They are characterized by continuous maintenance. Therefore, unlike the RC (release candidate) branches generated in each release cycle, they allow code that passes tests to be continuously merged regardless of the release cycle, thereby maximizing the flexibility and productivity of the development process.

[0040] In step S220, according to one embodiment, the electronic device 100 may receive a second code related to the second function from the second user terminal 140. For example, the user may input the following codes into the second user terminal 140: code for adjusting the size of text on a specific page of the application, code for displaying a specific image on a specific page of the application, or code for implementing a specific function on a specific page of the application. The second user terminal 140 may send the user-inputted code to the electronic device 100.

[0041] In step S230, according to one embodiment, upon confirmation that the second code has passed the first test, the electronic device 100 may merge the second code into the integration branch. More specifically, the electronic device 100 may perform at least one of the following tests: a quality test of the second code, a security test of the second code, an equivalence test of the second code, and a test of the form of the pull request of the first code, and upon confirmation that the second code has passed all the performed tests, the second code is merged into the integration branch.

[0042] For example, electronic device 100 can use tools such as SonarQube to perform tests to verify code quality, such as code complexity, repetitiveness, code style violations, and potential errors; or to identify security vulnerabilities by detecting higher-level security risks in OWASP. Alternatively, electronic device 100 can perform tests to verify whether the refactored code functions the same as the existing functionality or to confirm whether code changes function as expected; or to confirm whether commit messages, pull request titles and descriptions, code format, etc., conform to the rules. Afterwards, once the second code has passed all the implemented tests, electronic device 100 can merge the second code into the integration branch.

[0043] In step S240, according to one embodiment, the electronic device 100 can perform a second test on a plurality of functions corresponding to a plurality of codes merged into an integrated branch. More specifically, the electronic device 100 can determine whether the plurality of functions have data dependencies, and perform a first function test on the first function among the plurality of functions that has data dependencies based on mock data, and perform a second function test on the second function among the plurality of functions that does not have data dependencies.

[0044] For example, electronic device 100 can confirm that the first function is used to change the position of text displayed on a specific page of an application, and confirm that it does not have data dependencies. Therefore, electronic device 100 can perform the second function test on the first function in a simulated environment set up identically to the actual service environment, without data traffic. In this case, the simulated environment can refer to an environment where the server specifications, terminal specifications, network speed, and security settings are all set to be the same as the actual service environment.

[0045] For example, electronic device 100 can confirm that the first function is used to display the new badge image on a specific page of the application, and confirm that it has data dependency. Therefore, electronic device 100 can perform the first function test on the second function based on analog data.

[0046] On the other hand, the first and second functional tests may include, but are not limited to, the following functional tests: whether the existing functions are implemented correctly when multiple functions are implemented in a new way; whether the API (application programming interface) calls used to implement multiple functions are implemented correctly; whether the multiple functions are displayed correctly on the display; or whether the simulated data is loaded correctly.

[0047] In step S250, according to one embodiment, the electronic device 100 can identify one or more codes corresponding to one or more functions that have passed the second test. For example, depending on whether the plurality of functions have data dependencies, the electronic device 100 can identify one or more functions that have passed the first function test or the second function test, and identify one or more codes corresponding to one or more functions.

[0048] In step S260, according to one embodiment, the electronic device 100 can identify a code among one or more codes that meets the set conditions. More specifically, the electronic device 100 can implement one or more functions in multiple test environments with different set data flow ratios, and identify codes whose metric values ​​have not reached the set threshold values ​​when implementing one or more functions.

[0049] For example, electronic device 100 can implement more than one function in the following environments: a first test environment where the data flow ratio is set to a first value, and a second test environment where the data flow ratio is set to a second value. Then, electronic device 100 can verify the value of the metric in the first and second test environments, and verify that the code indicating that the value of the metric has not reached a threshold satisfies the set conditions. The value of the metric includes at least one of the following: the latency time generated when implementing more than one function; the number of requests received within a set time for the type of page implementing more than one function; the memory utilization rate corresponding to the implementation of more than one function; the CPU (central processing unit) utilization rate corresponding to the implementation of more than one function; or the number of errors generated in the web server.

[0050] At this point, the first value can be set to be less than the second value, but this is only one embodiment and is not limited to the one described above.

[0051] According to one embodiment, electronic device 100 can determine the data flow ratio of a first test environment based on information of one or more functions. More specifically, electronic device 100 can determine the data flow ratio, i.e., the first value, of the first test environment based on at least one of the following: the type of page that implements one or more functions, the area that provides one or more functions, the data capacity required to implement one or more functions, the type of data required to implement one or more functions, and the dependency of one or more functions on other functions.

[0052] For example, compared to a shopping cart page or checkout page where the page that performs more than one function is a page that requires more data, such as a search result page (SRP) or a single detail page (SDP), the electronic device 100 can more accurately determine the data flow ratio, i.e., the first value, of the first test environment.

[0053] For example, compared to a country where one or more functions are provided in a region with relatively few consumers, in a country where one or more functions are provided in a region with many consumers, the electronic device 100 can more accurately determine the data flow ratio, i.e., the first value, of the first test environment.

[0054] For example, the electronic device 100 can more accurately determine the data flow ratio, i.e., the first value, of the first test environment in the following situations: when one or more functions include operations that read or write large amounts of data, when one or more functions process important data such as personal information, or when there is a possibility of data processing bottlenecks.

[0055] For example, the electronic device 100 can more accurately determine the data flow ratio, i.e., the first value, of the first test environment in the following situations: when various types of data are required to achieve more than one function; when the data used to achieve more than one function has an overlapping structure or a complex structure such as including multi-level relationships; or when more than one function processes real-time data flow.

[0056] For example, the electronic device 100 can more accurately determine the data flow ratio, i.e., the first value, of the first test environment in the following situations: when one or more functions call multiple subordinate functions, or when one or more functions are central functions with high dependency.

[0057] However, the above method is only one embodiment. The electronic device 100 may determine the data flow ratio of the first test environment based on different factors, or by completely opposite methods.

[0058] According to one embodiment, electronic device 100 can determine a threshold value for determining whether a code meets a condition based on information about one or more functions. More specifically, electronic device 100 can determine the threshold value for determining whether a code meets a condition based on at least one of the following: the type of page implementing one or more functions, the area providing one or more functions, the capacity of data required to implement one or more functions, the type of data required to implement one or more functions, and the dependency of one or more functions on other functions.

[0059] For example, compared to a shopping cart page or checkout page where the page performing more than one function is a page that requires more information, such as a search results page or a product details page, the electronic device 100 can more accurately determine the threshold value used to determine whether the code meets the conditions, compared to a shopping cart page or checkout page where the page performing more than one function is a shopping cart page or checkout page.

[0060] For example, compared to a country where the area offering more than one function is used by a relatively small number of consumers, in a country where the area offering more than one function is used by a large number of consumers, the electronic device 100 can more accurately determine the threshold value used to determine whether the code meets the conditions.

[0061] For example, in the following situations, the electronic device 100 can more accurately determine the threshold value used to determine whether the code meets the conditions: when one or more functions include reading or writing large-scale data, when one or more functions process important data such as personal information, or when there is a possibility of data processing bottlenecks.

[0062] For example, in the following situations, the electronic device 100 can more accurately determine the threshold value used to determine whether the code meets the conditions: when various types of data are required to achieve more than one function; when the data used to achieve more than one function has an overlapping structure or a complex structure such as including multi-level relationships; or when more than one function processes real-time data streams.

[0063] For example, in the following situations, the electronic device 100 can more accurately determine the threshold value used to determine whether the code meets the conditions: when one or more functions call multiple subordinate functions, or when one or more functions are central functions with high dependency.

[0064] However, the above method is only one embodiment. The electronic device 100 may determine the threshold value for determining whether the code meets the conditions based on different factors, or by using completely opposite methods.

[0065] In step S270, according to one embodiment, the electronic device 100 can merge codes that meet set conditions into the main branch and roll back codes that do not meet the set conditions. For example, the electronic device 100 can merge codes whose measured values ​​do not reach a set threshold into the main branch under one or more conditions, and roll back codes whose measured values ​​are above the set threshold.

[0066] Figure 3 is a diagram illustrating the process of deploying user-written code in an electronic device 100 according to an embodiment.

[0067] According to one embodiment, the electronic device 100 can generate a plurality of functional branches for implementing a plurality of functions. For example, referring to FIG3, the electronic device 100 can separate from the autonomous branch 300 to generate a first functional branch 310 for implementing a first function, a second functional branch 320 for implementing a second function, and a third functional branch 330 for implementing a third function.

[0068] At this point, a feature branch is an independent and temporary branch created to develop a specific feature. It operates independently of the core codebase, so it will not affect other developers who are simultaneously developing other features or fixing existing features.

[0069] According to one embodiment, electronic device 100 can generate release candidate (RC) branches. For example, referring to FIG3, electronic device 100 can obtain permission lock in each set release cycle and generate release candidate branches 340 for merging multiple functional branches.

[0070] At this point, access control or locking refers to a mechanism that restricts specific resources or jobs (job space, branches, etc.) to prevent multiple jobs from being generated simultaneously, thereby preventing conflicts or unexpected actions caused by code changes.

[0071] According to one embodiment, electronic device 100 can merge a plurality of functional branches into a release candidate branch. For example, referring to FIG3, electronic device 100 can merge the first functional branch 310, the second functional branch 320 and the third functional branch 330 into the release candidate branch 340 after the merge start point.

[0072] According to one embodiment, electronic device 100 can perform set tests on multiple functions corresponding to multiple functional branches. For example, electronic device 100 can perform various functional tests on function 1, function 2, and function 3 in a simulated environment set up in the same way as the actual service environment without data traffic.

[0073] According to one embodiment, when certain conditions are met, the electronic device 100 can merge the emergency patch branch into the release candidate branch. For example, referring to FIG3, the electronic device 100 can merge the emergency patch branch 350 into the release candidate branch 340 only when errors or urgent corrections are confirmed during functional testing, rather than merging it into the functional branch after the merging deadline. Afterwards, the electronic device 100 can perform additional functional tests to confirm whether the corrections have been correctly applied.

[0074] According to one embodiment, upon confirmation of production approval, electronic device 100 can merge multiple functional branches into a main branch. For example, electronic device 100 can provide the user with the test results of the first, second, and third functions and obtain the user's approval input. Therefore, electronic device 100 can merge the first functional branch 310, the second functional branch 320, and the third functional branch 330 into the main branch 300.

[0075] As described above, when electronic device 100 merges functional branches into release candidate branches and tests the functions, there are inconveniences as follows: each function must be tested in a separate environment each time it is deployed. Furthermore, user approval is required each time a function is tested, resulting in low efficiency and productivity in continuous integration and deployment.

[0076] Figure 4 is a diagram illustrating the process of deploying user-written code in an electronic device 100 according to an embodiment.

[0077] According to one embodiment, electronic device 100 can maintain and manage integration branches. For example, referring to FIG4, electronic device 100 can generate and manage integration branch 480 as a space for reviewing changes merged into feature branches regardless of the release cycle.

[0078] According to one embodiment, the electronic device 100 can generate a plurality of functional branches for implementing a plurality of functions. For example, referring to FIG4, the electronic device 100 can separate from the autonomous branch 400 to generate a first functional branch 420 for implementing a first function, a second functional branch 440 for implementing a second function, and a third functional branch 460 for implementing a third function.

[0079] According to one embodiment, electronic device 100 can verify the dependencies and quality of a plurality of functional branches. For example, referring to FIG4, electronic device 100 can use a tool such as SonarQube to perform tests to verify the quality of code, such as the complexity, repetition, code style violations, and potential errors, of the code corresponding to the first functional branch 420, the second functional branch 440, and the third functional branch 460. Alternatively, referring to FIG4, electronic device 100 can perform tests to verify whether the functions corresponding to the first functional branch 420, the second functional branch 440, and the third functional branch 460 call multiple subordinate functions or whether such functions are central functions with high dependencies.

[0080] According to one embodiment, electronic device 100 can merge multiple functional branches into an integrated branch. For example, referring to FIG4, after confirming the dependencies and quality of the first functional branch 420, the second functional branch 440 and the third functional branch 460 and merging them into the integrated branch 480, electronic device 100 can generate a release tag.

[0081] According to one embodiment, the electronic device 100 can perform set tests on a plurality of functions corresponding to a plurality of functional branches. For example, referring to FIG4, the electronic device 100 can perform functional tests on data-dependent functions of the first, second, and third functions based on mock data, and perform various functional tests on non-data-dependent functions of the first, second, and third functions in a mock environment set up in the same way as the actual service environment without data traffic.

[0082] According to one embodiment, as multiple functions corresponding to multiple functional branches are implemented in various test environments, the electronic device 100 can confirm whether the set conditions are met. For example, referring to FIG4, the electronic device 100 can confirm that the value of the following metric has not reached the set threshold value, which is identified when the first function and the second function are implemented in the first test environment with the data flow ratio set to the first value. Alternatively, the electronic device 100 can confirm that the value of the following metric has not reached the set threshold value, which is identified when the first function, the second function, and the third function are implemented in the second test environment with the data flow ratio set to the second value.

[0083] According to one embodiment, as it is confirmed that a plurality of functions meet set conditions, the electronic device 100 can merge the plurality of functional branches into a main branch. For example, the electronic device 100 can confirm that the value of a metric has not reached a set threshold, the value of which is identified when the first, second, and third functions are implemented in a first or second test environment. Therefore, the electronic device 100 can merge the first functional branch 420, the second functional branch 440, and the third functional branch 460 into the main branch 400.

[0084] As described above, the electronic device 100 can merge functional branches into an integrated branch that is maintained regardless of the release cycle, and test multiple functions in the same test environment, thereby maximizing the flexibility and productivity of the development process.

[0085] Figure 5 is a diagram illustrating the process of deploying user-written code in an electronic device 100 according to an embodiment.

[0086] In step S500, according to one embodiment, the electronic device 100 may perform code development steps. More specifically, referring to FIG5, the electronic device 100 may perform code check-in steps, steps to confirm the PR review of functional branches, steps to confirm code quality, code check-in steps, and code merging steps.

[0087] For example, electronic device 100 can verify the user's newly written first code and confirm the user's approval of the first code's retrieval request. Afterwards, electronic device 100 can perform tests such as: quality testing of the first code, security testing of the first code, equivalence testing of the first code, or testing of the form of the first code's retrieval request. Once the first code is confirmed to have passed the tests, electronic device 100 can push the first code to remote storage and merge it into the integration branch.

[0088] In step S510, according to one embodiment, the electronic device 100 may perform a pre-check and build step. More specifically, referring to FIG5, the electronic device 100 may perform a Docker image build step, a data dependency determination step, a deployment step in the PERM environment, and a first functional test step.

[0089] For example, electronic device 100 can generate a Docker image of a new application version using CircleCIe and verify whether the first function corresponding to the first code has data dependencies. If it is confirmed that the first function has data dependencies, electronic device 100 can deploy the application containing the first code to the PERM environment and perform functional testing on the first function in the PERM environment based on simulated data.

[0090] In step S520, according to one embodiment, the electronic device 100 may perform the Stage steps. More specifically, referring to FIG5, the electronic device 100 may perform the deployment steps in the Stage environment, the second functional test steps, the flow / error sensing steps, the quality verification steps, and the interruption and notification steps.

[0091] For example, if electronic device 100 determines that the first function lacks data dependency, electronic device 100 can deploy the application containing the first code to a Stage environment configured identically to the actual service environment and perform the second function test. Afterwards, electronic device 100 can use traffic monitoring to confirm whether there are any abnormal actions and to verify the code quality and stability. If a problem with code quality and stability is confirmed, electronic device 100 can interrupt the deployment process of the first function and notify the user.

[0092] In step S530, according to one embodiment, the electronic device 100 may perform the Devx CRT step. More specifically, referring to FIG5, the electronic device 100 may perform a deployment preparation step, a step of generating a release tag for a Docker image, a permission locking step, a CRT generation step, and a CRT approval step.

[0093] For example, if it is confirmed that there are no issues with code quality and stability, electronic device 100 can generate a final release image tag to deploy an application reflecting the first code. Afterwards, electronic device 100 can write a CRT (change request ticket) and automatically approve the CRT for the changes.

[0094] In step S540, according to one embodiment, the electronic device 100 may perform a Canary step. More specifically, referring to FIG5, the electronic device 100 may perform a deployment step in a Canary environment, a step to confirm whether the conditions are met, and a rollback step.

[0095] For example, electronic device 100 can deploy an application containing the first code to a Canary environment where the data flow ratio is set to the first value or 10%, and verify whether the value of the metric identified when implementing the first function has not reached the set threshold. If it is confirmed that the value of the metric is above the threshold, electronic device 100 can roll back to a version of the application that does not include the first function.

[0096] However, those skilled in the art will understand that the data flow ratio of the Canary environment is only one example and can be set to a different value than described above.

[0097] In step S550, according to one embodiment, the electronic device 100 may perform a Production step. More specifically, referring to FIG5, the electronic device 100 may perform a deployment step in the Production environment, a step to confirm whether the conditions are met, a quality confirmation step, and a rollback step.

[0098] For example, if it is confirmed that the value of a metric has not reached a critical value, the electronic device 100 can deploy the application containing the first code to a production environment where the data flow ratio is set to the second value or 100%, and confirm whether the value of the metric identified when implementing the first function has not reached the set critical value. If it is confirmed that the value of a metric is above the critical value, the electronic device 100 can roll back to a version of the application that does not include the first function. If it is confirmed that the value of a metric has not reached a critical value, the electronic device 100 can confirm the code quality and stability.

[0099] However, those skilled in the art will understand that the data flow ratio of the Production environment is only one example and can be set to a different value than described above.

[0100] In step S560, according to one embodiment, the electronic device 100 may perform a Release Lock step. More specifically, the electronic device 100 may perform a lock release and merge to the main branch step.

[0101] For example, referring to Figure 5, if it is confirmed that there are no problems with the code quality and stability, the electronic device 100 can be unlocked after the release is completed and the first code can be merged into the main branch to complete the final deployment.

[0102] Figure 6 is a flowchart illustrating a code deployment method for an electronic device according to one embodiment. The above description can be applied to repetitive content.

[0103] In step S600, the electronic device may perform a first test on the first code related to the first function received from the first terminal.

[0104] According to one embodiment, the first test may include at least one of the following tests: a test of the quality of the first code; a test of the security of the first code; a test of the parity of the first code; and a test of the form of the pull request of the first code.

[0105] In step S620, the electronic device can merge the first code that has passed the first test into the integration branch.

[0106] In step S640, the electronic device can perform a second test on a plurality of functions corresponding to a plurality of codes, including the first code, that are merged into the integrated branch.

[0107] According to one embodiment, when performing a second test on a plurality of functions, the electronic device can determine whether the plurality of functions are data-dependent, perform a first function test on the second function with data dependence among the plurality of functions based on mock data, and perform a second function test on the third function without data dependence among the plurality of functions.

[0108] According to one embodiment, the second functional test can be performed in a simulated environment with the same settings as the actual service environment, in the form of no data traffic. The simulated environment has the same server specifications, terminal specifications, network speed and security settings as the actual service environment.

[0109] According to one embodiment, the first functional test and the second functional test may include at least one of the following functional tests: whether the existing functions are implemented correctly when the plurality of functions are newly implemented; whether the API (application programming interface) calls used to implement the plurality of functions are implemented correctly; whether the plurality of functions are displayed correctly on the display; and whether the simulated data is loaded correctly.

[0110] In step S660, the electronic device may merge the second code that meets the set conditions into the main branch. The second code is one or more codes that correspond to one or more functions that have passed the second test.

[0111] According to one embodiment, when the second code is merged into the main branch, the electronic device can implement more than one function in multiple test environments where the data flow ratio is set in different ways, and confirm the value of the metric identified when implementing more than one function, and confirm that the second code whose metric value has not reached the set threshold satisfies the set condition.

[0112] According to one embodiment, the plurality of test environments include a first test environment in which the data flow ratio is set to a first value, and a second test environment in which the data flow ratio is set to a second value, wherein the first value is set to be less than the second value.

[0113] According to one embodiment, the first value may be determined based on at least one of the following: the type of page that implements one or more functions; the area that provides one or more functions; the capacity of data required to implement one or more functions; the type of data required to implement one or more functions; and the dependency of one or more functions on other functions.

[0114] According to one embodiment, the measured value may include at least one of the following: the latency time generated when implementing one or more functions; the number of requests received within a set time for the type of page that implements one or more functions; the memory utilization rate corresponding to the implementation of one or more functions; the CPU (central processing unit) utilization rate corresponding to the implementation of one or more functions; and the number of errors generated in the web server.

[0115] According to one embodiment, the threshold value can be determined based on at least one of the following: the type of page that implements one or more functions; the area that provides one or more functions; the amount of data required to implement one or more functions; the type of data required to implement one or more functions; and the dependency of one or more functions on other functions.

[0116] According to one embodiment, the electronic device can roll back a third code among more than one code that does not meet the set conditions.

[0117] Figure 7 is a block diagram showing an embodiment of an electronic device 100.

[0118] According to one embodiment, the electronic device 100 may include a transceiver 720, a memory 740, and a processor 760. The electronic device 100 shown in FIG. 7 only illustrates the components relevant to this embodiment. Therefore, those skilled in the art related to this embodiment will understand that other common components may be included in addition to those shown in FIG. 7. In this embodiment, the transceiver 720 may be included in a communication device. Furthermore, in this embodiment, the processor 760 may be included in a controller.

[0119] The transceiver 720, as a device for wired / wireless communication, can communicate with external electronic devices. These external electronic devices can be terminals or servers. Furthermore, the communication technologies utilized by the transceiver 720 may include 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, and NFC (Near Field Communication).

[0120] The processor 760 can control the overall operation of the electronic device 100 and process data and signals. The processor 760 may include at least one hardware unit. Furthermore, the processor 760 can operate by executing one or more software modules generated from program code stored in memory 740. The processor 760 may include memory, and the processor 760 can execute program code stored in memory to control the overall operation of the electronic device 100 and process data and signals.

[0121] The processor 760 can perform a first test on the first code related to the first function received from the first terminal, merge the first code that passes the first test into the integration branch, perform a second test on the multiple functions corresponding to the multiple codes including the first code merged into the integration branch, merge the second code that meets the set conditions into the main branch, and the second code is one or more codes corresponding to one or more functions that pass the second test.

[0122] The electronic device described in the above embodiments may include a processor, memory for storing and executing program data, permanent storage such as a disk drive, a communication port for communicating with external devices, and a user interface device such as a touch panel, keys, or buttons. Computer-readable code or program commands that can be executed on the processor, implemented using software modules or algorithms, can be stored in a computer-readable recording medium. Here, computer-readable recording media include magnetic storage media (e.g., ROM (read-only memory), RAM (random-access memory), floppy disks, hard disks, etc.) and optical reading media (e.g., CD-ROM, DVD, etc.). The computer-readable recording medium is distributed across a network-connected computer system, thereby enabling distributed storage and execution of computer-readable code. The medium can be read by a computer, stored in memory, and executed in a processor.

[0123] This embodiment can be represented by functional blocks and various processing steps. These functional blocks can be implemented by different numbers of hardware and / or software components performing specific functions. For example, the embodiment can employ integrated circuits capable of performing various functions via the control of one or more microprocessors or other control devices, such as memory, processing, logic, lookup tables, etc. The components can be executed by software programming or software elements. Similarly, this embodiment includes algorithms implemented by combinations of data structures, programs, conventions, or other programming structures, and therefore can be implemented using programming or scripting languages ​​such as C, C++, Java, and assemblers. Functionally, it can be implemented by algorithms executed in one or more processors. Furthermore, this embodiment can employ prior art for electronic environment setup, signal processing, and / or data processing. Terms such as "mechanism," "component," "mechanism," and "structure" are used broadly and are not limited to mechanical or physical structures. The above terms may be associated with processors and include the meaning of a series of software processes.

[0124] The above embodiments can be implemented as artificial intelligence (AI) using the processor and memory of an electronic device. The processor may include one or more processors, which can be general-purpose processors such as CPUs, APs, and DSPs (digital signal processors), graphics-specific processors such as GPUs and VPUs (vision processing units), or AI-specific processors such as NPUs. One or more processors can be controlled to process input data according to predefined action rules or AI models stored in memory. Alternatively, when one or more processors are AI-specific processors, the AI-specific processors can be designed with hardware specifically for processing a particular AI model.

[0125] The predefined action rules or artificial intelligence models are characterized by being created through learning. Here, "created through learning" means creating predefined action rules or artificial intelligence models configured in such a way that a basic artificial intelligence model is learned by a learning algorithm and using a large amount of learning data, thereby implementing the desired characteristics (or objectives). This learning can be implemented within the electronic device implementing artificial intelligence of this invention itself, or it can be implemented by a separate server and / or system. Examples of learning algorithms include supervised learning, unsupervised learning, semi-supervised learning, or reinforcement learning, but are not limited to the examples mentioned above.

[0126] An artificial intelligence model may include a plurality of neural network layers. Each of the plurality of neural network layers has a plurality of weight values, and neural network operations are performed by operations between the results of the previous layer and the plurality of weight values. The plurality of weight values ​​of the plurality of neural network layers can be optimized by the learning results of the artificial intelligence model. For example, during the learning process, the plurality of weight values ​​can be updated in a way that reduces or minimizes the loss or cost value obtained by the artificial intelligence model. Artificial neural networks may include deep neural networks (DNN), convolutional neural networks (CNN), recurrent neural networks (RNN), restricted Boltzmann machines (RBM), deep belief networks (DBN), bidirectional recurrent deep neural networks (BRDNN), or deep Q-networks, but are not limited to the examples mentioned above.

[0127] The above embodiment is only an example, and other embodiments can be implemented within the scope of the invention application described below.

[0128] 100: Electronic devices 120: First User Terminal 140: Second User Terminal 160: Third User Terminal 180: Internet 300: Main branch 310: First Functional Branch 320: Second Functional Branch 330: Third Functional Branch 340: Release candidate branches 350: Emergency Repair Branch 400: Main branch 420: First Functional Branch 440: Second Functional Branch 460: Third functional branch 480: Integration Branch 720: Transceiver 740: Memory 760: Processor S200: Steps S210: Steps S220: Steps S230: Steps S240: Steps S250: Steps S260: Steps S270: Steps S500: Steps S510: Steps S520: Steps S530: Steps S540: Steps S550: Steps S560: Steps S600: Steps S620: Steps S640: Steps S660: Steps

Claims

1. A code deployment method performed via an electronic device, comprising the following steps: performing a first test on first code received from a first terminal that is related to a first function; merging the first code that passes the first test into an integration branch; performing a second test on a plurality of functions corresponding to a plurality of codes including the first code, the plurality of codes being merged into the integration branch; and merging second code that meets set conditions into a main branch, the second code being one or more codes corresponding to one or more functions that pass the second test, wherein the step of performing the second test on the plurality of functions comprises the following steps: confirming whether the plurality of functions have data dependencies; and performing a first function test on the second functions among the plurality of functions that have data dependencies based on simulated data, and performing a second function test on the third functions among the plurality of functions that do not have data dependencies.

2. As in the code deployment method of request item 1, the second functional test mentioned above is performed in a simulated environment set up in the same way as the actual service environment, without data traffic. The simulated environment has the same server specifications, terminal specifications, network speed and security settings as the actual service environment.

3. As in the code deployment method of request item 1, wherein the first functional test and the second functional test mentioned above include at least one of the following functional tests: whether the existing functions are implemented correctly when the plurality of functions are newly implemented; whether the API calls used to implement the plurality of functions are implemented correctly; whether the plurality of functions are displayed correctly on the display; and whether the simulated data is loaded correctly.

4. The code deployment method as described in Request Item 1, wherein the first test mentioned above includes at least one of the following tests: quality testing of the first code; security testing of the first code; equivalence testing of the first code; and testing of the form of the pull request for the first code.

5. The code deployment method as described in Request 1, wherein the step of merging the second code mentioned above into the main branch includes the following steps: implementing one or more of the functions mentioned above in multiple test environments with different data flow ratios set; confirming the values ​​of the metrics identified when implementing one or more of the functions mentioned above; and confirming that the second code mentioned above, whose values ​​of the metrics have not reached the set threshold, meets the set conditions mentioned above.

6. The code deployment method as described in Request 5, wherein the plurality of test environments includes a first test environment with the data traffic ratio set to a first value and a second test environment with the data traffic ratio set to a second value, wherein the first value is set to be less than the second value.

7. The code deployment method as described in Request Item 6, wherein the first value mentioned above is determined based on at least one of the following: the type of page that implements the above-mentioned one or more functions; the area that provides the above-mentioned one or more functions; the capacity of the data required to implement the above-mentioned one or more functions; the type of data required to implement the above-mentioned one or more functions; and the dependency of the above-mentioned one or more functions on other functions.

8. The code deployment method as described in Request Item 5, wherein the values ​​of the above-mentioned metrics include at least one of the following: the latency time incurred when implementing one or more of the above-mentioned functions; the number of requests received within a set time for the type of page implementing one or more of the above-mentioned functions; the memory utilization rate corresponding to the implementation of one or more of the above-mentioned functions; the CPU utilization rate corresponding to the implementation of one or more of the above-mentioned functions; and the number of errors generated in the web server.

9. The code deployment method as described in Request 5, wherein the aforementioned threshold is determined based on at least one of the following: the type of page implementing the above-mentioned functions; the area providing the above-mentioned functions; the data capacity required to implement the above-mentioned functions; the data type required to implement the above-mentioned functions; and the dependency of the above-mentioned functions on other functions.

10. The code deployment method of request item 1 further includes the following steps: rolling back the third code among the above-mentioned one or more codes that does not meet the conditions set above.

11. A non-transitory computer-readable recording medium recording a program for performing the method as described in claim 1 on a computer.

12. An electronic device comprising: transceiver; The memory; and the processor; wherein the processor performs the following: performs a first test on a first code received from a first terminal that is related to a first function; merges the first code that passes the first test into an integration branch; performs a second test on a plurality of functions corresponding to a plurality of codes including the first code, wherein the plurality of codes are merged into the integration branch; merges a second code that meets set conditions into a main branch, wherein the second code is one or more codes corresponding to one or more functions that pass the second test, wherein, in order to perform the second test on the plurality of functions, the processor is configured to: confirm whether the plurality of functions have data dependencies; and perform a first function test on the second function among the plurality of functions that has data dependencies based on simulated data, and perform a second function test on the third function among the plurality of functions that does not have data dependencies.

Images