An application updating method and device based on a componentized architecture

Abstract

The application embodiment provides an application updating method and device based on a component-based architecture, a train version application (main image) is created, an updating operation is isolated from a main version, when the application is updated, each component is independently developed, only the component code which is completed in development can be merged into the train version application to obtain a to-be-tested version application, the to-be-tested version application can be merged into the main version application only after being tested by regression, the main code is updated, frequent modification and pollution of the main code in the updating process are avoided, code merging complexity is reduced, regression test pressure is reduced, one project (component) instability does not block the whole application updating, and therefore, application updating efficiency is improved.

Description

Technical Field

[0001] This application relates to the field of mobile application technology, and in particular to an application update method and apparatus based on a component-based architecture. Background Technology

[0002] Currently, mobile applications generally adopt a component-based architecture that combines a shell project and business components. The shell project serves as the core entry point, but it does not carry specific business logic. It is mainly responsible for basic application configuration (including package name, signature, resources, channel and version information, etc.) and compilation and packaging related work. The list and versions of the business components to be integrated are specified through configuration files. Business components correspond to independent business domains (such as login, messaging, live streaming, etc.) and exist as independent repositories or modules. During the final build, they are pulled and integrated based on the shell project configuration.

[0003] In this architecture, traditional code management and delivery processes revolve around the trunk. Specifically, all modifications to business components must ultimately be merged into the trunk, and the shell project configuration files are also maintained in the trunk and frequently updated as business components change. Projects often pull specific version-derived feature branches or release branches from the trunk. In this model, when multiple projects are developed in parallel, each business development proceeds on its own dedicated project branch. During regression testing, integration testing, or deployment, branch changes need to be merged back into the trunk and then synchronized to other branches, causing the shell project configuration files to become high-conflict hotspots. In this process, frequent trunk merging leads to high code merging complexity, high regression testing pressure, and instability in one project can block the entire application update, resulting in low application update efficiency. Summary of the Invention

[0004] The purpose of this application is to provide an application update method and apparatus based on a component-based architecture, so as to improve application update efficiency. The specific technical solution is as follows:

[0005] In a first aspect, embodiments of this application provide an application update method based on a component-based architecture, the method comprising:

[0006] Create a mirror of the trunk version application as the train version application;

[0007] At the first time point, identify the components that are expected to be developed before the second time point, and designate them as the components to be put into the vehicle.

[0008] At the second time node, the component code of each of the expected boarding components is determined and merged into the train version application to obtain the test version application, wherein the component code of each of the expected boarding components is updated between the first time node and the second time node;

[0009] Regression testing was performed on the application version to be tested;

[0010] If the application under test passes the regression test, the application under test will be merged into the trunk application to obtain a new trunk application.

[0011] In one possible implementation, the component code of the expected boarding component is updated during the period from the first time node to the second time node in the following manner:

[0012] Pull the code of the shell project, the component code of the expected component to be installed, and the component code of the related components that the expected component to be installed depends on from the main version application.

[0013] Merge the pulled code to get a sandboxed version of the application;

[0014] The component code of the expected onboard component is updated in the sandbox version application.

[0015] In one possible implementation, determining the component code of each of the expected onboard components and incorporating it into the train version application includes:

[0016] Identify the components that have been developed and passed self-testing and are expected to be installed on the vehicle, as the target components for installation on the vehicle.

[0017] The component code of each target onboard component is determined and merged into the train version application.

[0018] In one possible implementation, determining the anticipated on-vehicle component that has completed development and passed self-testing as the target on-vehicle component includes:

[0019] Identify the components that have been developed and passed self-testing, as well as the components that can be rolled back to a stable version, as the target components for deployment.

[0020] In one possible implementation, after merging the test version of the application into the trunk version of the application to obtain a new trunk version of the application, the method further includes:

[0021] Using the expected onboard component that is not the target onboard component as the new expected onboard component, return to the step of creating the image of the trunk version application as the train version application.

[0022] In one possible implementation, the method further includes:

[0023] Before the second time node, update the code of the shell project in the train version application so that the shell project of the train version application supports the updating of the code of each component.

[0024] Secondly, embodiments of this application provide an application update apparatus based on a component-based architecture, the apparatus comprising:

[0025] Create a module to create a mirror of the trunk version application, which will serve as the train version application.

[0026] The module is used to identify, at the first time point, the components that are expected to be developed before the second time point, as the expected components to be put into the vehicle.

[0027] The merging module is used to determine the component code of each of the expected onboard components and merge it into the train version application at the second time node to obtain the test version application, wherein the component code of each of the expected onboard components is updated between the first time node and the second time node;

[0028] The testing module is used to perform regression testing on the application version to be tested;

[0029] The update module is used to merge the application under test into the trunk version application if the application under test passes the regression test, so as to obtain a new trunk version application.

[0030] In one possible implementation, the component code of the expected boarding component is updated during the period from the first time node to the second time node in the following manner:

[0031] Pull the code of the shell project, the component code of the expected component to be installed, and the component code of the related components that the expected component to be installed depends on from the main version application.

[0032] Merge the pulled code to get a sandboxed version of the application;

[0033] The component code of the expected onboard component is updated in the sandbox version application.

[0034] In one possible implementation, the merging module includes:

[0035] The first merging submodule is used to identify the expected onboard components that have been developed and passed self-testing, and use them as target onboard components.

[0036] The second merging submodule is used to determine the component code of each target onboard component and merge it into the train version application.

[0037] In one possible implementation, the first merging submodule includes:

[0038] The first merging submodule is used to identify the components that have been developed and passed self-testing and are expected to be deployed, as well as the components that can be rolled back to a stable version, as the target deployment components.

[0039] In one possible implementation, after merging the test version of the application into the trunk version of the application to obtain a new trunk version of the application, the apparatus further includes:

[0040] The loop module is used to return to the step of creating the trunk version application image as the train version application, taking the expected boarding component that is not the target boarding component as the new expected boarding component.

[0041] In one possible implementation, the device further includes:

[0042] The pre-update module is used to update the code of the shell project in the train version application before the second time node, so that the shell project of the train version application supports the updating of the code of each component.

[0043] Thirdly, embodiments of the present invention provide an electronic device, including:

[0044] Memory, used to store computer programs;

[0045] When the processor executes a program stored in memory, it implements the application update method based on the component-based architecture described in the first aspect above.

[0046] Fourthly, embodiments of the present invention provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the application update method based on a component-based architecture described in the first aspect.

[0047] Fifthly, embodiments of the present invention also provide a computer program product containing instructions that, when run on a computer, cause the computer to execute the application update method based on the component-based architecture described in the first aspect.

[0048] Beneficial effects of the embodiments in this application:

[0049] This application provides an application update method and apparatus based on a component-based architecture. It obtains a train version application by creating a mirror of the trunk version application. At a first time point, components expected to be developed before a second time point are identified as expected onboard components. At the second time point, the component code of each expected onboard component is determined and merged into the train version application to obtain a test version application. The component code of each expected onboard component is updated between the first and second time points. Regression testing is performed on the obtained test version application. If the test version application passes the regression test, it is merged into the trunk version application to obtain a new trunk version application. This method isolates update operations from the main version by creating a train version application (main image). During application updates, each component is developed independently, and only the code of the completed components can be merged into the train version application to obtain the test version application. Only after the test version application passes regression testing can it be merged into the main version application to update the main code. This avoids frequent modifications and pollution to the main code during the update process, reduces the complexity of code merging, reduces the pressure of regression testing, and ensures that the instability of one component will not block the entire application update, thereby improving the efficiency of application updates.

[0050] Of course, implementing any product or method of this application does not necessarily require achieving all of the advantages described above at the same time. Attached Figure Description

[0051] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of this application. For those skilled in the art, other embodiments can be obtained based on these drawings.

[0052] Figure 1 A schematic diagram of an application update method provided in an embodiment of this application;

[0053] Figure 2 A schematic diagram illustrating component code updates provided in an embodiment of this application;

[0054] Figure 3 Another schematic diagram of the application update method provided in the embodiments of this application;

[0055] Figure 4 Another schematic diagram of the application update method provided in the embodiments of this application;

[0056] Figure 5 This is a schematic diagram of the structure of the application update device provided in the embodiments of this application;

[0057] Figure 6This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0058] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those skilled in the art based on this application are within the scope of protection of this application.

[0059] In traditional processes, code management and delivery (i.e., the steps performed after an application update) mainly follow the following pattern:

[0060] 1. Centered on trunk: All modifications to business components must eventually be merged into the trunk. The configuration files of the shell project are also maintained in the trunk and need to be frequently modified as business components change. The project usually pulls specific versions from the trunk to form feature branches or release branches.

[0061] 2. Parallelism and frequent merging of multiple branches: When multiple projects are running in parallel, business development is carried out on their respective project branches. When projects are undergoing regression testing, integration testing, or preparing for launch, it is necessary to merge the changes of each project branch back into the trunk and then synchronize them from the trunk to other branches. In particular, the configuration files of shell projects are high-conflict hotspots.

[0062] 3. High testing and release costs: Each merge into the trunk may trigger heavy redline regression testing. When there are more than a dozen projects running in parallel, a large number of merge and regression operations will be generated within a version cycle. Once a project fails the test, complex rollbacks or cherry-picks need to be performed at the branch and trunk levels, which is risky.

[0063] 4. Uncontrollable version rhythm: Some requirements expose serious problems close to the release date, which can only be temporarily abandoned or cause the overall version to be delayed. Since all projects revolve around trunk merging and regression, the instability of one or two projects can affect the overall version quality and release date.

[0064] The main problems with existing technologies include the following:

[0065] Problem 1: Shell project configuration files become hotspots for conflicts, resulting in high merging costs;

[0066] Question 2: The trunk is frequently contaminated, resulting in decreased stability and a large number of regressions, leading to high regression testing pressure.

[0067] Question 3: Strong coupling between multiple projects; instability in one area blocks application updates.

[0068] Question 4: It is difficult to achieve a fixed update schedule, and the application update plan is frequently disrupted.

[0069] To address the aforementioned issues, this application provides an application update method based on a component-based architecture. (See attached document.) Figure 1 , Figure 1 A schematic diagram of an application update method provided in an embodiment of this application, the method including:

[0070] S101, create a mirror of the trunk version application as the train version application.

[0071] S102, at the first time point, identify the components that are expected to be developed before the second time point, as the expected components to be put into the vehicle.

[0072] S103, at the second time point, determine the component code of each expected component to be loaded onto the train and merge it into the train version application to obtain the version application to be tested.

[0073] Among them, the component code of each expected component to be put on the vehicle will be updated between the first time node and the second time node;

[0074] S104, perform regression testing on the application version to be tested.

[0075] S105. If the application under test passes the regression test, merge the application under test into the trunk application to obtain a new trunk application.

[0076] Applying the above embodiments, a train version application is obtained by creating a mirror of the trunk version application. At the first time point, components expected to be developed before the second time point are identified as expected onboard components. At the second time point, the component code of each expected onboard component is determined and merged into the train version application, resulting in the application to be tested. The component code of each expected onboard component is updated between the first and second time points. Regression testing is performed on the obtained application to be tested. If the application to be tested passes the regression test, it is merged into the trunk version application to obtain a new trunk version application. This method isolates update operations from the main version by creating a train version application (main image). During application updates, each component is developed independently. Only the code of the completed components can be merged into the train version application to obtain the test version application. Only after the test version application passes regression testing can it be merged into the main version application to update the main code. This avoids frequent modifications and pollution to the main code during the update process, reduces the complexity of code merging, and reduces the pressure of regression testing. The instability of one component will not block the entire application update, thereby improving the application update efficiency and solving the aforementioned problems one to three.

[0077] Furthermore, since each component is developed independently, any problem in the development of any component will not affect application updates. Therefore, a fixed update schedule can be achieved, and the application update plan will not be frequently disrupted, thus solving the aforementioned problem four.

[0078] Since the version under test is built based on the train version image, if the test fails, only the problematic components need to be fixed, without rolling back the entire trunk version. The original stable version can run normally and will not affect the normal use of the application. If the test passes, the new trunk version is based on the original stable version and has good compatibility and traceability. Even if problems occur later, it can be quickly rolled back to the previous trunk image.

[0079] The application update method based on component-based architecture provided in this application embodiment is applied to a continuous integration platform (CI system). The CI system supports automatically initiating tasks such as building, unit testing, user interface (UI) automated testing, and packaging based on changes in branches (including train version applications and sandbox version applications). It supports identifying train version applications and sandbox version applications and using different pipeline strategies for different version applications.

[0080] Steps S101-S105 will be explained below:

[0081] In step S101, during the application update process, code management and delivery are centered on the trunk. All modifications to components must eventually be merged into the trunk to achieve the application update.

[0082] The trunk version of the application is the base version of the application, which is maintained with a trunk. It contains verified and stable basic functional modules and code, and serves as the foundation for all subsequent updates and iterations.

[0083] The train version application obtained from the mirror is a complete backup of the trunk version application, covering all necessary elements for running, such as basic functional modules, code, dependent environment, and configuration files, and can reproduce the application state consistent with the trunk version application. There can be one or more train version applications.

[0084] In step S102, each component is treated as an independent module or repository, and the version management of the component can be implemented using any of the following methods: semantic versioning, Git tags, or branching mechanisms.

[0085] In practical applications, application updates may involve multiple updates, meaning there will be multiple update cycles. In this article, the first time node is the planning start point for each update cycle, and the second time node is the deadline for component merging; together, they constitute a complete component iteration and merging cycle. The component code of each component expected to be deployed is updated between the first and second time nodes.

[0086] The application update cycle can be fixed as two natural weeks per train. The first week is the period from the first time node to the second time node, which is called the "train start week" and is used for requirement access and development completion.

[0087] Week 2, defined as the period from the second time point to the acquisition of the new backbone application version, is designated as the "Integration Week." It is used for unified integration and regression testing. At the end of the week, all expected components for integration are determined. At the beginning of the Integration Week, these expected components are merged into the train version application, resulting in the application version to be tested. Unified regression testing is performed on this application version. Only after all merged components pass the regression test is it released to the production environment. This means merging the application version to be tested into the backbone application, obtaining the new backbone application version, and releasing it to the production environment. Steps S103, S104, and S105 mentioned above are all steps performed during the Integration Week.

[0088] If a component is not completed or is deemed too risky by the end of the week, it will be marked as not being used in this cycle. The component will continue development and be carried over to the next cycle, which will be the cycle corresponding to the next update period.

[0089] In this step, based on factors such as development requirements, priorities, and resource allocation, components that can be developed, tested, and optimized within the current deployment week are selected and identified as the expected deployment components. Under a component-based architecture, each component is independent of the others, thus allowing for individual assessment of the development cycle of each component, preventing delays in the development of some components from impacting the overall application update schedule.

[0090] When determining the components to be integrated into the vehicle, the components that are expected to be developed before the second time point can be selected based on the preset integration rules or industry standards.

[0091] The onboarding rules are used as the basis for anticipating whether each component can complete development before the second time node, including but not limited to: the scale of requirements and the scope of changes are assessed to be within a controllable range, the dependencies on other components are clear and accepted, and the components promise to complete development and self-testing within the specified time.

[0092] In step S103, at the second time node, the component codes of each expected onboard component determined in step S102 are merged into the train version application to obtain the test version application.

[0093] In step S104, regression testing is used to verify whether the functional integrity, stability, compatibility, and other performance of the application under test are normal after the component code of each expected onboard component is merged.

[0094] In step S105, passing the regression test means that the functional integrity, stability, and compatibility of the application under test have met the standards for going live or iterating. At this time, the application under test can be merged into the main application to obtain a new main application.

[0095] In one possible embodiment, the component code of the expected onboard component can be updated in the train version application between the first time node and the second time node.

[0096] In another possible implementation, a sandboxed version of the application can be created based on a stable shell project on the trunk. Between the first and second time points, the component code of the components to be deployed in the sandboxed version application is updated. For details, see [link to relevant documentation]. Figure 2 , Figure 2 A schematic diagram illustrating component code updates provided in the embodiments of this application includes:

[0097] S201, pull the code of the shell project, the component code of the expected component to be installed, and the component code of the related components that the expected component to be installed depends on from the main version application.

[0098] S202, merge the pulled code to get the sandboxed version of the application.

[0099] S203, Update the component code of the expected onboard component in the sandbox version application.

[0100] In step S201, the shell project is the basic container that carries each component in the componentized architecture. Its code is stored in the trunk of the main version application as basic project code, which only includes basic configuration code, packaging script code, component list configuration code, etc., and does not contain business logic code.

[0101] Pulling the shell project code ensures that the development environment maintains consistency with the basic framework of the main version of the application, avoiding component compatibility issues caused by framework differences. Pulling the code of the components to be deployed is to enable updates and iterations based on the existing code, ensuring the continuity of component functionality. Pulling the code of its dependent components is because components in a component-based architecture are not completely isolated; some components require the interfaces or functions of related components to function properly. Pulling them synchronously restores the complete dependency environment for component operation, avoiding problems such as missing dependencies and interface incompatibility during updates.

[0102] In step S202, the code of the shell project, the component code of the expected component to be installed, and the component code of the related components that the expected component to be installed depend on are merged to obtain a sandbox version application. That is, a sandbox version application is created based on the code of the shell project, the component code of the expected component to be installed, and the component code of the related components that the expected component to be installed depends on.

[0103] The sandbox version of the application is an independent, isolated development environment. It merges the pulled shell project code, the code of the expected components to be deployed, and the code of related components to build a dedicated development environment that is consistent with the main version environment and contains only the target components and their corresponding dependencies. This environment is completely isolated from the main version application and the development environments of other components. When developers update components in this environment, they will not modify the code of the main version application, nor will it affect the development progress of other components. At the same time, it can fully simulate the running scenarios of components in real-world applications.

[0104] In step S203, the component code of the expected onboard component is updated in the created sandbox version application.

[0105] Applying the above embodiments, the code of the shell project, the component code of the expected component to be integrated, and the component code of the related components that the expected component to be integrated depend on are pulled from the main version application. The pulled code is then merged to obtain a sandbox version application. The component code of the expected component to be integrated is then updated in the sandbox version application. By using this method, component code updates are carried out based on the sandbox version, achieving isolation between the update operation and the main version application, and avoiding the impact of the update process on the main version application.

[0106] When determining the component code of each expected onboard component and merging it into the train version application, in one possible embodiment, the component code of the expected onboard components can be self-tested. After passing the self-test, it can be merged into the train version application. For details, see [link to relevant documentation]. Figure 3 , Figure 3 This is another schematic diagram of the application update method provided in the embodiments of this application. The method includes:

[0107] S101, create a mirror of the trunk version application as the train version application.

[0108] S102, at the first time point, identify the components that are expected to be developed before the second time point, as the expected components to be put into the vehicle.

[0109] S1031, at the second time point, identify the expected on-board components that have been developed and passed self-testing, and use them as target on-board components;

[0110] S1032, determine the component code of each target onboard component and merge it into the train version application to obtain the application to be tested.

[0111] Among them, the component code of each expected component to be put on the vehicle will be updated between the first time node and the second time node;

[0112] S104, perform regression testing on the application version to be tested.

[0113] S105. If the application under test passes the regression test, merge the application under test into the trunk application to obtain a new trunk application.

[0114] Steps S1031 and S1032 are detailed steps of the aforementioned step S103. Steps S101, S102, S104 and S105 have been explained in the preceding text and will not be repeated here.

[0115] In steps S1031 and S1032, after the expected onboard component is developed, it can be self-tested in the aforementioned sandbox version application, and the expected onboard component that passes the self-test is determined as the target onboard component.

[0116] Specifically, an application package is built in the sandbox version of the application. This application package is used for internal functional testing and integration testing of the component code. The CI platform performs automated tests on the sandbox version of the application to ensure the self-testing quality of the component code in the sandbox version of the application.

[0117] By applying the above embodiments, the components that have been developed and passed self-testing are identified as target components for integration into the train version application. The component code of each target component is then merged into the train version application. This method, by merging only the code of components that have been developed and passed self-testing, ensures the code quality of the train version application, avoids the inclusion of incomplete or problematic code, and thus improves the efficiency of application updates.

[0118] In another possible implementation, the component code of the expected onboard component can be self-tested. Only after passing the self-test and being able to roll back to a stable version can the code component be merged into the train version application. For details, see [link to relevant documentation]. Figure 4 , Figure 4 This is another schematic diagram of the application update method provided in the embodiments of this application. The method includes:

[0119] S101, create a mirror of the trunk version application as the train version application.

[0120] S102, at the first time point, identify the components that are expected to be developed before the second time point, as the expected components to be put into the vehicle.

[0121] S10311, at the second time point, identify the expected components that have been developed and passed self-testing, as well as the expected components that can be rolled back to a stable version, as the target components for implementation.

[0122] S1032, determine the component code of each target onboard component and merge it into the train version application to obtain the application to be tested.

[0123] Among them, the component code of each expected component to be put on the vehicle will be updated between the first time node and the second time node;

[0124] S104, perform regression testing on the application version to be tested.

[0125] S105. If the application under test passes the regression test, merge the application under test into the trunk application to obtain a new trunk application.

[0126] Step S10311 is a detailed step of the aforementioned step S1031. Steps S101, S102, S104, S1032 and S105 have been explained in the preceding text and will not be repeated here.

[0127] In step S10311, the expected component to be deployed must have the ability to roll back to a stable version. Specifically, if the expected component is deployed and goes live and encounters sudden failures, performance abnormalities, or other problems, it can quickly switch to a historically verified stable version through a preset rollback mechanism to avoid the application being unavailable for a long time due to component failure.

[0128] Using this embodiment, only components that have completed development and passed self-testing, as well as components that can be rolled back to a stable version, can be considered as target components for deployment. By requiring completion of development, passing self-testing, and implementing a rollback mechanism, this method reduces the risk of application update failures due to component defects, provides components with post-deployment fault-covering capabilities, shortens the duration of fault impact, and improves application stability and reliability.

[0129] As described in step S102 above, if a component is not completed or has too high a risk by the end of the train journey, it is marked as not to be included in this train journey, and the component continues development and is postponed to the next train journey. Specifically, after merging the application to be tested into the trunk application to obtain a new trunk application, the expected components that are not the target components to be included in the train journey are used as new expected components to be included in the train journey. The process then returns to the step of creating the image of the trunk application as the train application, which is to say, the process returns to the aforementioned step S101.

[0130] Components not intended for onboarding include components that have not been developed, components that have not passed self-testing, and components that have neither been developed nor passed self-testing.

[0131] Applying this embodiment, components that are not fully developed, components that have not passed self-testing, and components that are neither fully developed nor passed self-testing are considered as new expected components for deployment. The process then returns to the step of creating the backbone version application image, serving as the train version application. This method avoids interrupting the overall application update process due to substandard development or testing of some components, ensuring the continuity and efficiency of application updates.

[0132] When modifications to the shell project code are needed to support application updates, the shell project code in the train version application can be updated before the second time point, so that the shell project of the train version application can support the updates of the code of each component.

[0133] Applying the above embodiments, before the second time node, the code of the shell project in the train version application is updated so that the shell project of the train version application supports the updating of the code of each component. By applying this method to update the shell project code in the train version application in advance, problems such as interface incompatibility and mechanism mismatch between the old shell project and the new components can be solved, reducing the update risk and improving the success rate of component updates.

[0134] To more clearly illustrate the application update method based on a component-based architecture provided in this application, specific examples will be used for explanation below:

[0135] Taking an application currently in the Nth train cycle (i.e., the aforementioned Nth update cycle) as an example, there are three projects in parallel: Project A, Project B, and Project C.

[0136] Among them, Project A is a high-demand project involving 5 business components; Project B is a medium-demand project involving 2 components; and Project C is an emergency defect repair project involving 1 component.

[0137] At the start of the "boarding week", three projects simultaneously apply to enter the current train. The system creates a train branch for each project. That is, relative to the aforementioned step S101, the project is equivalent to the trunk version application in the aforementioned step S101, and the train branch is equivalent to the train version application in the aforementioned step S101.

[0138] Each project conducted development and integration testing within the sandbox project. Specifically, Project A modified and integrated five components in the sandbox, Project B added new features to two components, and Project C located and fixed defects in the sandbox. By the end of the "onboarding week," Projects B and C passed self-testing in the sandbox, while Project A still had serious unresolved defects. This is equivalent to steps S201, S202, S203, and S1031 mentioned above, where component code was updated and self-tested in the sandbox version application.

[0139] After entering the "Integration Week," the component changes for projects B and C are merged from their respective sandbox branches into the train version branch. Project A is marked as not participating in this train and continues to fix issues in the sandbox, awaiting the next train. A full regression is performed on the train version branch, and after successful verification, the version for that train is released. This is equivalent to steps S103, S104, and S105 mentioned above.

[0140] When the next train begins, Project A continues to be tested and gradually stabilized in the sandbox. Once it passes self-testing before the start of the new train, it is then merged into the new train version branch.

[0141] Corresponding to the aforementioned application update method based on component-based architecture, this application also provides an application update apparatus based on component-based architecture, see [link to relevant documentation]. Figure 5 , Figure 5 This is a schematic diagram of the application update device provided in an embodiment of this application. The device includes:

[0142] Create module 501 to create a mirror of the trunk version application, which will serve as the train version application.

[0143] Module 502 is used to determine, at the first time point, each component that is expected to be developed before the second time point, as the expected components to be put into the vehicle.

[0144] The merging module 503 is used to determine the component code of each of the expected onboard components and merge it into the train version application at the second time node to obtain the test version application, wherein the component code of each of the expected onboard components is updated between the first time node and the second time node.

[0145] Test module 504 is used to perform regression testing on the application version to be tested;

[0146] The update module 505 is used to merge the application under test into the trunk version application if the application under test passes the regression test, so as to obtain a new trunk version application.

[0147] Applying the above embodiments, a train version application is obtained by creating a mirror of the trunk version application. At the first time point, components expected to be developed before the second time point are identified as expected onboard components. At the second time point, the component code of each expected onboard component is determined and merged into the train version application, resulting in the application to be tested. The component code of each expected onboard component is updated between the first and second time points. Regression testing is performed on the obtained application to be tested. If the application to be tested passes the regression test, it is merged into the trunk version application to obtain a new trunk version application. This device isolates update operations from the main version by creating a train version application (main image). During application updates, each component is developed independently. Only the code of the completed components can be merged into the train version application to obtain the test version application. Only after the test version application passes regression testing can it be merged into the main version application to update the main code. This avoids frequent modifications and pollution to the main code during the update process, reduces the complexity of code merging, and reduces the pressure of regression testing. The instability of one component will not block the entire application update, thereby improving the efficiency of application updates and solving the aforementioned problems one to three.

[0148] Furthermore, since each component is developed independently, any problem in the development of any component will not affect application updates. Therefore, a fixed update schedule can be achieved, and the application update plan will not be frequently disrupted, thus solving the aforementioned problem four.

[0149] Since the version under test is built based on the train version image, if the test fails, only the problematic components need to be fixed, without rolling back the entire trunk version. The original stable version can run normally and will not affect the normal use of the application. If the test passes, the new trunk version is based on the original stable version and has good compatibility and traceability. Even if problems occur later, it can be quickly rolled back to the previous trunk image.

[0150] In one possible implementation, the component code of the expected boarding component is updated during the period from the first time node to the second time node in the following manner:

[0151] Pull the code of the shell project, the component code of the expected component to be installed, and the component code of the related components that the expected component to be installed depends on from the main version application.

[0152] Merge the pulled code to get a sandboxed version of the application;

[0153] The component code of the expected onboard component is updated in the sandbox version application.

[0154] In one possible implementation, the merging module includes:

[0155] The first merging submodule is used to identify the expected onboard components that have been developed and passed self-testing, and use them as target onboard components.

[0156] The second merging submodule is used to determine the component code of each target onboard component and merge it into the train version application.

[0157] In one possible implementation, the first merging submodule includes:

[0158] The first merging submodule is used to identify the components that have been developed and passed self-testing and are expected to be deployed, as well as the components that can be rolled back to a stable version, as the target deployment components.

[0159] In one possible implementation, after merging the test version of the application into the trunk version of the application to obtain a new trunk version of the application, the apparatus further includes:

[0160] The loop module is used to return to the step of creating the trunk version application image as the train version application, taking the expected boarding component that is not the target boarding component as the new expected boarding component.

[0161] In one possible implementation, the device further includes:

[0162] The pre-update module is used to update the code of the shell project in the train version application before the second time node, so that the shell project of the train version application supports the updating of the code of each component.

[0163] This application also provides an electronic device, such as... Figure 6 As shown, it includes:

[0164] Memory 601 is used to store computer programs;

[0165] When processor 602 executes a program stored in memory 601, it performs the following steps:

[0166] Create a mirror of the trunk version application as the train version application;

[0167] At the first time point, identify the components that are expected to be developed before the second time point, and designate them as the components to be put into the vehicle.

[0168] At the second time node, the component code of each of the expected boarding components is determined and merged into the train version application to obtain the test version application, wherein the component code of each of the expected boarding components is updated between the first time node and the second time node;

[0169] Regression testing was performed on the application version to be tested;

[0170] If the application under test passes the regression test, the application under test will be merged into the trunk application to obtain a new trunk application.

[0171] Furthermore, the aforementioned electronic device may also include a communication bus and / or a communication interface, with the processor 602, communication interface, and memory 601 communicating with each other via the communication bus.

[0172] The communication bus mentioned in the above electronic devices can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc. For ease of illustration, only one thick line is used to represent it in the diagram, but this does not mean that there is only one bus or one type of bus.

[0173] The communication interface is used for communication between the aforementioned electronic devices and other devices.

[0174] The memory may include random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0175] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0176] In another embodiment provided in this application, a computer-readable storage medium is also provided, which stores a computer program that, when executed by a processor, implements the steps of any of the above-described application update methods based on a component-based architecture.

[0177] In another embodiment provided in this application, a computer program product containing instructions is also provided, which, when run on a computer, causes the computer to execute any of the application update methods based on a component-based architecture described above.

[0178] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium (e.g., floppy disk, hard disk, magnetic tape), an optical medium (e.g., DVD), or a solid-state drive (SSD), etc.

[0179] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0180] The various embodiments in this specification are described in a related manner. Similar or identical parts between embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, the system embodiments are basically similar to the method embodiments, so the description is relatively simple; relevant parts can be referred to the descriptions of the method embodiments.

[0181] The above description is merely a preferred embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application are included within the scope of protection of this application.

Claims

1. A method for updating an application based on a componentized architecture, characterized in that, The method includes: Create a mirror of the trunk version application as the train version application; At the first time point, identify the components that are expected to be developed before the second time point, and designate them as the components to be put into the vehicle. At the second time node, the component code of each of the expected boarding components is determined and merged into the train version application to obtain the test version application, wherein the component code of each of the expected boarding components is updated between the first time node and the second time node; Regression testing was performed on the application version to be tested; If the application under test passes the regression test, the application under test will be merged into the trunk application to obtain a new trunk application.

2. The method according to claim 1, characterized in that, The component code of the expected boarding component is updated during the period from the first time node to the second time node in the following ways: Pull the code of the shell project, the component code of the expected component to be installed, and the component code of the related components that the expected component to be installed depends on from the main version application. Merge the pulled code to get a sandboxed version of the application; The component code of the expected onboard component is updated in the sandbox version application.

3. The method according to claim 1, characterized in that, The step of determining the component code of each of the expected onboard components and merging it into the train version application includes: Identify the components that have been developed and passed self-testing and are expected to be installed on the vehicle, as the target components for installation on the vehicle. The component code of each target onboard component is determined and merged into the train version application.

4. The method according to claim 3, characterized in that, The determination of the expected on-vehicle components that have been developed and passed self-testing, as target on-vehicle components, includes: Identify the components that have been developed and passed self-testing, as well as the components that can be rolled back to a stable version, as the target components for deployment.

5. The method according to claim 3, characterized in that, After merging the application to be tested into the trunk version application to obtain a new trunk version application, the method further includes: Using the expected onboard component that is not the target onboard component as the new expected onboard component, return to the step of creating the image of the trunk version application as the train version application.

6. The method according to claim 1, characterized in that, The method further includes: Before the second time node, update the code of the shell project in the train version application so that the shell project of the train version application supports the updating of the code of each component.

7. An application update device based on a component-based architecture, characterized in that, The device includes: Create a module to create a mirror of the trunk version application, which will serve as the train version application. The module is used to identify, at the first time point, the components that are expected to be developed before the second time point, as the expected components to be put into the vehicle. The merging module is used to determine the component code of each of the expected onboard components and merge it into the train version application at the second time node to obtain the test version application, wherein the component code of each of the expected onboard components is updated between the first time node and the second time node; The testing module is used to perform regression testing on the application version to be tested; The update module is used to merge the application under test into the trunk version application if the application under test passes the regression test, so as to obtain a new trunk version application.

8. The apparatus according to claim 7, characterized in that, The component code of the expected boarding component is updated during the period from the first time node to the second time node in the following ways: Pull the code of the shell project, the component code of the expected component to be installed, and the component code of the related components that the expected component to be installed depends on from the main version application. Merge the pulled code to get a sandboxed version of the application; The component code of the expected onboard component is updated in the sandbox version application; The merging module includes: The first merging submodule is used to identify the expected onboard components that have been developed and passed self-testing, and use them as target onboard components. The second merging submodule is used to determine the component code of each target onboard component and merge it into the train version application; The first merging submodule includes: The first merging submodule is used to identify the expected components that have been developed and passed self-testing, as well as the expected components that can be rolled back to a stable version, as the target components for integration. After merging the application to be tested into the trunk version application to obtain a new trunk version application, the device further includes: The loop module is used to take the expected onboard component that is not the target onboard component as the new expected onboard component, and return to the step of creating the image of the trunk version application as the train version application. The device further includes: The pre-update module is used to update the code of the shell project in the train version application before the second time node, so that the shell project of the train version application supports the updating of the code of each component.

9. An electronic device, characterized in that, It includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; A processor, when executing a program stored in memory, implements the steps of the method described in any one of claims 1-6.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the steps of the method described in any one of claims 1-6.

Images