Multi-user remote construction method and device and electronic equipment

Abstract

The invention discloses a multi-user remote construction method and device and electronic equipment, and belongs to the technical field of computer software development. The method comprises the steps that a remote server is logged in, and the remote server creates a virtual working directory under an independent user directory of a current SSH session; mounting the virtual working directory as a session-level virtual disk consistent with a local development environment drive so as to obtain a path mapping environment in which a remote compiling path is consistent with a local development path; on the basis of the path mapping environment, the change file and the construction script of the local development environment are synchronized to the corresponding path in the session-level virtual disk to obtain a remote synchronization code set, and the path of the remote synchronization code set in the session-level virtual disk is kept consistent with the path of the change file; the construction script is remotely executed to start a compiling process to process the remote synchronous code set, and a remote target file set is obtained; and returning the far-end target file set to a corresponding path of the local development environment to obtain a local synchronous target file set.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer software development, in particular to a multi-user remote building method and device and electronic equipment. BACKGROUND

[0002] In the related art, in the field of C / C++ embedded software development, in order to shorten the build time of large projects and improve team collaboration efficiency, remote compilation and distributed building technology has been widely used. The basic idea is to send the source code from the local environment of the developer to a remote server with stronger performance for compilation, and then return the compilation results (such as object files, executable files, library files, etc.) to the local, so as to fully utilize the computing resources of the server and achieve the purpose of improving the compilation speed.

[0003] In the related art, the remote building method is mainly based on the building method of the continuous integration system. This kind of system is generally deeply combined with the version control repository, and the standard workflow usually requires the developer to first submit the code to the remote code repository, and then the remote building system pulls the source code from the repository to the server's build directory to perform compilation, testing, packaging and other operations. This method uses full-pull and full-compile, which results in low efficiency in the transmission and compilation process. SUMMARY

[0004] The present application provides a multi-user remote building method, device and electronic equipment, aiming to solve the problem of low efficiency of remote building.

[0005] In a first aspect, a multi-user remote building method is provided, comprising the following steps: logging into a remote server, the remote server creating a virtual working directory under the independent user directory of the current SSH session; mounting the virtual working directory as a session-level virtual disk consistent with the local development environment drive letter based on the operating system command, to obtain a path mapping environment in which the remote compilation path is consistent with the local development path; based on the path mapping environment, running an incremental synchronization tool to synchronize the changed files and build scripts of the local development environment to the corresponding paths in the session-level virtual disk, to obtain a remote synchronized code set, the path of the remote synchronized code set in the session-level virtual disk being consistent with the path of the changed files; remotely executing the build script to start a compilation process to process the remote synchronized code set, to obtain a remote target file set; running the incremental synchronization tool to return the remote target file set to the corresponding path of the local development environment, to obtain a local synchronized target file set.

[0006] In some embodiments, the operating system of the remote server is a Windows system, the operating system command is a subst command, and the session-level virtual disk maps the virtual working directory to the local development environment drive letter through the subst command.

[0007] In some embodiments, before running the incremental synchronization tool to synchronize the changed files and the build script of the local development environment to the corresponding path in the session-level virtual disk, the method further comprises: obtaining source files of an initial version of the local development environment; sending the source files of the initial version of the local development environment to the remote server; modifying the source files of the initial version of the local development environment to obtain source files of a current version of the local development environment; comparing the source files of the current version with the source files of the initial version in the remote server, and screening out parts of the source files of the current version that are different from the source files of the initial version in the remote server to obtain the changed files.

[0008] In some embodiments, remotely executing the build script in the remote synchronization code set starts a compilation process, including: switching to the drive letter of the session-level virtual disk through an SSH command, then entering the corresponding working path in the session-level virtual disk, and executing the build script.

[0009] In some embodiments, the remote server is pre-configured to disable or not assign the local development environment drive letter, so as to reserve the drive letter for mounting of the session-level virtual disk.

[0010] In some embodiments, after running the incremental synchronization tool to return the remote target file set to the corresponding path of the local development environment to obtain a local synchronization target file set, the method further comprises: exiting the current SSH session, and the session-level virtual disk automatically disappears and releases the occupied drive letter resource.

[0011] In some embodiments, after exiting the current SSH session, the method further comprises: starting a debugging tool in the local development environment, and loading the local synchronization target file set for breakpoint debugging.

[0012] The second aspect also provides a multi-user remote building device, comprising: a login module configured to log in a remote server, and the remote server creates a virtual working directory under a separate user directory of a current SSH session; a creation module configured to mount the virtual working directory as a session-level virtual disk consistent with a local development environment drive letter based on an operating system command, to obtain a path mapping environment in which a remote compilation path is consistent with a local development path. an incremental pushing module, based on the path mapping environment, running an incremental synchronization tool to synchronize changed files and build scripts of the local development environment to corresponding paths in the session-level virtual disk to obtain a remote synchronization code set, the paths in the session-level virtual disk of the remote synchronization code set being consistent with the paths of the changed files; an executing module, configured to remotely execute the build scripts to start a compilation process to process the remote synchronization code set to obtain a remote target file set; an incremental returning module, configured to run the incremental synchronization tool to return the remote target file set to corresponding paths of the local development environment to obtain a local synchronization target file set.

[0013] In a third aspect, an electronic device is provided, which includes a processor and a memory for storing processor-executable instructions, and the processor executes the instructions to implement the steps of the method in any of the above embodiments.

[0014] In a fourth aspect, a computer-readable storage medium is provided, which stores a computer program, and the computer program is loaded by a processor to execute the steps of the method in any of the above embodiments.

[0015] The present application has the following beneficial effects: the embodiments of the present application use an incremental synchronization tool to transmit only changed files when pushing source code and returning target files, thereby reducing data transmission volume and being significantly faster than the full-pull of a conventional system, and allowing developers to directly compile remote code that has not been committed, without relying on a code repository, thereby avoiding version pollution caused by frequent code commits for debugging and fitting the workflow of high-frequency modification, compilation and debugging in the daily development stage. BRIEF DESCRIPTION OF DRAWINGS

[0016] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following will briefly introduce the drawings needed in the embodiment description. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative effort based on these drawings.

[0017] Figure 1 is a flowchart of a multi-user remote building method provided by an exemplary embodiment of the present disclosure; Figure 2 is a workflow diagram of a local development end and a remote building server provided by an exemplary embodiment of the present disclosure; Figure 3 is a flowchart of a multi-user remote building method provided by an exemplary embodiment of the present disclosure; Figure 4FIG. 1 is a structural schematic diagram of a multi-user remote building device provided by an example embodiment of the present disclosure. DETAILED DESCRIPTION

[0018] The technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, rather than all the embodiments of the present application. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative work fall within the scope of protection of the present application.

[0019] The use of “based on” in this application means openness and inclusiveness, because the process, step, calculation or other action “based on” one or more described conditions or values can be based on additional conditions or values beyond the described values in practice.

[0020] In this application, the word “exemplary” is used to mean “serving as an example, instance, or illustration.” Any embodiment described as “exemplary” in this application is not necessarily to be construed as preferred or advantageous over other embodiments. The following description is presented to enable any person skilled in the art to make and use the application. In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present application. It will be apparent, however, to one skilled in the art that the present application can be practiced without using these specific details. In other instances, well-known structures and processes are not elaborated in order not to obscure the description of the present application with unnecessary details. Thus, the present application is not intended to be limited by the embodiments shown, but is to be accorded the widest scope consistent with the principles and features disclosed herein.

[0021] In the related art, the mainstream remote building method is mainly based on the building method of a continuous integration system. Such a system is generally deeply combined with a version control repository, and the standard workflow usually requires a developer to first submit code to a remote code repository, and then the remote building system pulls the source code from the code repository to the building directory of the server to perform operations such as compilation, testing, and packaging.

[0022] In the above related technologies, the remote compiling method represented by the continuous integration system has serious defects. First, the compiling path of the remote server is inconsistent with the local path of the developer, resulting in an error in the source code debugging path embedded in the target file generated by compiling, so that breakpoint debugging cannot be performed after the remote build product is returned to the local; second, the system generally lacks a real multi-user isolation mechanism, and simultaneous building by multiple developers can easily cause file conflicts, and the use of task queues (serial execution) to avoid this problem seriously sacrifices the parallel computing capability of the server; third, the related technologies excessively rely on the code repository, and force the developer to submit the code to the code repository before building, which does not conform to the development habits of daily high-frequency debugging, and also causes confusion in the version records of the repository, which is not convenient for unified management; finally, the related technologies mostly use full-pull and full-compile, rather than efficient incremental synchronization, resulting in a large amount of time being wasted on repeated file transmission and compilation when the project size (code size) is large, and lacking a perfect incremental synchronization mechanism, which cannot meet the needs of rapid feedback in the development stage.

[0023] In one aspect, the embodiment provides a multi-user remote building method, as shown in the following steps: Figure 1 S101: logging into a remote server, the remote server creating a virtual working directory under the independent user directory of the current SSH session; S102: based on the operating system command, mounting the virtual working directory as a session-level virtual disk consistent with the local development environment drive letter to obtain a path mapping environment in which the remote compiling path is consistent with the local development path; S103: based on the path mapping environment, running an incremental synchronization tool to synchronize the changed files and building scripts of the local development environment to the corresponding paths in the session-level virtual disk to obtain a remote synchronized code set, the path of the remote synchronized code set in the session-level virtual disk being consistent with the path of the changed files; S104: remotely executing the building script to start a compiling process to process the remote synchronized code set to obtain a remote target file set; S105: running the incremental synchronization tool to return the remote target file set to the corresponding paths of the local development environment to obtain a local synchronized target file set.

[0024] First of all, it needs to be pointed out that, referring to Figure 2 and Figure 3 ​As shown, the specific implementation of the multi-user remote building method depends on a distributed system architecture which logically comprises at least two core entities, i.e. a local client and a remote build server. In this embodiment, the local client and the remote build server are the environmental prerequisites for implementing the method of the application, wherein: The local client is the initiating end and the result receiving end of the method of the application. It is usually a personal computer of a developer (user). The operating system is usually a Windows system. The engineering source code (also referred to as local source file, source file, engineering file, local engineering file) is stored in a local specific path, for example, D:\work\project\. The path is the local development environment drive letter to be matched by the application. The local client is installed with an SSH (secure shell) client for logging in to the remote server and an rsync incremental synchronization tool for efficient file transfer. The developer writes and modifies the code on the local client and triggers the entire remote building process through an automated script, and finally receives a set of local synchronization target files that can be used for debugging on the local client. The remote build server (referred to as server or remote server) is the actual execution end of the building task in the method of the application. It is usually a server with high-performance computing resources. The operating system is preferably a system supporting session-level drive letter mapping, for example, Windows Server. The remote build server is installed with an SSH server to receive SSH connections from multiple users. The remote build server is installed with an rsync incremental synchronization tool corresponding to the local client and a compilation tool chain required for C / C++ embedded development. In order to achieve path consistency, the remote build server is pre-configured to disable or not assign a drive letter consistent with the local development environment drive letter, i.e. there is no physical D: drive on the server, so as to reserve the drive letter for subsequent session-level virtual drive mounting.

[0025] Referring to Figure 2 As shown, the environment and functions of the local client are described in detail below.

[0026] (1) Environment: Developer's local Windows machine.

[0027] (2) Function: Run the remote_build.sh script. "Running the remote_build.sh script" specifically includes: 1. Detecting whether the drive letter of the local source file is D:\ (in this embodiment, the local source file is the current version of the source file) 2. Connecting to the remote server through SSH 3. Send the command mkdir to create the directory C:\Users\username\virtual_D; 4. Send the command subst to mount “C:\Users\username\virtual_D” as a virtual D drive (the virtual mapping will be D:\work\project); 5. Perform Rsync incremental push (e.g., send source code from the D:\work\project directory); 6. Send the build command (e.g., the build.bat script); 7. Perform Rsync incremental fetch (e.g., receive compilation results in the D:\work\project\build directory).

[0028] See Figure 2 As shown below, the environment and functions of the remote build server will be explained in detail.

[0029] (1) Environment: Windows Server operating system; 1. Install OpenSSH server to support multi-user SSH login; 2. When each user logs in for the first time, the system automatically creates their own independent user directory, such as: C:\Users\username\; 3. The remote build server cannot have a D drive (the D drive letter is left empty and reserved for temporary mounting each time a user connects). When multiple users log in at the same time, their respective D drives are isolated from each other.

[0030] (2) Function: As a server for remote compilation; 1. Execute the command mkdir to create the directory C:\Users\username\virtual_D; 2. Execute the command `subst` to mount virtual_D as a virtual drive D; 3. Perform Rsync incremental push (e.g., receive source code in the D:\work\project directory); 4. Execute the build command (e.g., the build.bat script); 5. Execute Rsync incremental fetch (e.g., send the compilation results of the D:\work\project\build directory).

[0031] With the aforementioned environment and entities already in place, a multi-user remote construction method will be described in detail below with reference to the accompanying drawings.

[0032] S101: log in a remote server, which creates a virtual working directory under the independent user directory of the current SSH session.

[0033] In some embodiments, a user logs in a remote server through a secure shell (SSH) protocol, which creates a virtual working directory under the independent user directory of the current SSH session. Specifically, the secure shell (SSH) protocol is an encrypted network transmission protocol that allows a user to securely access and operate another computer over an insecure network; in order to ensure that each user has an independent working environment on the remote server, an independent virtual working directory is created for each user at each login, so that the build environments of different users are completely isolated, avoiding file conflicts and permission interference between multiple users. It is particularly noted that the virtual working directory and the files therein (i.e., the remote synchronization code set) will not be automatically cleaned up after the session ends, but will be intentionally retained to provide a basis for incremental synchronization for the user's next build session, which can improve subsequent build efficiency. The application automatically cleans up the session-level virtual disk drive mapping created in the subsequent steps, not the physical directory.

[0034] S102: mount the virtual working directory as a session-level virtual disk consistent with the local development environment drive based on an operating system command, to obtain a path mapping environment in which the remote compilation path is consistent with the local development path.

[0035] In some embodiments, the virtual working directory is mounted as a session-level virtual disk consistent with the local development environment drive based on an operating system command, to obtain a path mapping environment in which the remote compilation path is consistent with the local development path, and to achieve session isolation of the build environments of multiple users without interfering with each other.

[0036] In some embodiments, the operating system of the remote server is a Windows system, the operating system command is a subst command, and the session-level virtual disk maps the virtual working directory to the local development environment drive through the subst command.

[0037] In a Windows operating system environment, the subst command can conveniently map the directory on the remote server to a virtual disk, ensuring the path consistency of the local development environment and the remote compilation environment, which allows the developer to directly debug the target files produced by remote compilation without complex path conversion (e.g., the remote target file set can be directly used for debugging after being transmitted back to the local).

[0038] Specifically, the subst command in the Windows operating system is used to map the virtual working directory on the remote server to a virtual disk consistent with the local development environment disk, so that the target file path of remote compilation is consistent with the local compilation path. This not only enables developers to obtain the same debugging information as in the local environment during remote building, but also ensures consistency in path mapping and solves the problem of remote compilation products that cannot be directly debugged. The path mapping environment refers to the virtual working state created on the remote server, which is consistent with the local development path. The local development environment is equivalent to the system environment of the local development end.

[0039] S103: Based on the path mapping environment, run the incremental synchronization tool to synchronize the modified files and the build script of the local development environment to the corresponding path in the session-level virtual disk to obtain a remote synchronization code set, and the path of the remote synchronization code set in the session-level virtual disk is consistent with the path of the modified files.

[0040] In some embodiments, before running the incremental synchronization tool to synchronize the modified files and the build script of the local development environment to the corresponding path in the session-level virtual disk, the method further comprises: S1: Obtain the source files of the initial version of the local development environment; S2: Send the source files of the initial version to the remote server; S3: Modify the source files of the initial version of the local development environment to obtain the source files of the current version of the local development environment; S4: Compare the source files of the current version and the source files of the initial version in the remote server, and filter out the part of the source files of the current version that is different from the source files of the initial version in the remote server to obtain the modified files.

[0041] The above steps S1 to S4 are called "incremental synchronization". Among them, S1 and S2 only need to be performed once, while S3 and S4 can be performed multiple times as the user modifies the source files of the local development environment to obtain different modified files.

[0042] Specifically, in the remote build process, the initial version of the source file of the local development environment is sent to the remote server in advance; the incremental synchronization tool (for example, rsync) is used to synchronize only the changed files, instead of transmitting the entire source code every time, that is, the incremental synchronization tool is used to extract the changed part of the current version of the source file to obtain the changed file, and only the changed file is transmitted each time, which can greatly improve the efficiency of the build process, especially in large projects, a large amount of network bandwidth and time can be saved, in addition, the incremental synchronization tool can ensure that the synchronization path is consistent with the local development environment, and avoid the problem of difficult debugging caused by inconsistent paths; wherein the remote synchronization code set specifically refers to the entire set of source code that has been successfully transmitted from the local development end to the remote build server by the incremental synchronization tool such as rsync. The changed file is successfully deployed on the remote build server to obtain the remote synchronization code set.

[0043] Specifically, in the remote build process, the path of the build script in the session-level virtual disk is consistent with the path of the changed file.

[0044] Specifically, in the remote build process, the build script can also be part of the remote synchronization code set and synchronized to the corresponding path in the session-level virtual disk.

[0045] S104: remotely executing the build script starts a compilation process to process the remote synchronization code set to obtain a remote target file set.

[0046] In some embodiments, the remote execution of the build script starts a compilation process to process the remote synchronization code set, and since the path mapping environment ensures the consistency of the compilation path and the local path, the source code debugging path recorded in the "remote target file set" generated by the compilation is completely consistent with the local compilation result, and the "remote target file set" with consistent paths is obtained.

[0047] In some embodiments, the remote execution of the build script in the remote synchronization code set starts a compilation process, including: switching to the disk symbol of the session-level virtual disk through an SSH command, then entering the corresponding working path in the session-level virtual disk, and executing the build script.

[0048] The build process is remotely executed through an SSH command, and before executing the build script, the system automatically switches to the correct working directory, which can ensure the smooth progress of the build process and maintain the consistency of the path.

[0049] In some embodiments, when the build script is executed on the remote server, the consistency of the compilation path with the local path ensures that the debug path information in the "remote target file set", such as.elf,.obj, etc. generated in the compilation process is consistent with the local one, which enables the developer to directly use the "remote target file set" built remotely for debugging when debugging locally, without any path conversion, thereby simplifying the debugging process.

[0050] S105: running the incremental synchronization tool to return the remote target file set to the corresponding path of the local development environment to obtain a local synchronized target file set.

[0051] In some embodiments, based on the path-consistent remote target file set, the incremental synchronization tool is run to perform "incremental return" of the remote target file set to the corresponding path of the local development environment to obtain a local synchronized target file set.

[0052] In some embodiments, after the build is completed, the incremental return mechanism ensures that only the updated part (remote target file set) of the remote build result is returned to the local, avoiding the redundant transmission of the full file, which not only saves the transmission time and bandwidth, but also ensures the path consistency of the remote target file set with the local development environment, so that the remote target file set (after return) can be directly used for local debugging.

[0053] In some embodiments, after running the incremental synchronization tool to return the remote target file set to the corresponding path of the local development environment to obtain a local synchronized target file set, the method further comprises: exiting the current SSH session, and the session-level virtual disk automatically disappears and releases the occupied disk symbol resource.

[0054] Specifically, when the user exits the current SSH session, the virtual disk created for him is automatically released, ensuring that it does not affect the build tasks of other users. The build environment of each user is completely independent, and the resources of the remote server are efficiently managed.

[0055] In some embodiments, the incremental synchronization tool is the rsync tool; the incremental synchronization tool can be used to push the "source file of the initial version of the local development environment" to the session-level virtual disk; the incremental synchronization tool can be used to perform incremental return and result synchronization, specifically including pulling the path-consistent remote target file set back to the local development environment.

[0056] In some embodiments, rsync is an incremental synchronization tool that ensures only the changed files are transmitted by comparing the timestamps and content differences of the files, thereby greatly reducing the amount and time of file transmission. In the present application, the rsync tool is used to synchronize the current version of the source file and the build result (remote target file set), ensuring the synchronization efficiency and data consistency of the files.

[0057] In some embodiments, after the modified file is sent to the remote server, the modified file and the initial version of the source file can be stored together on the remote server to form a "first remote source file". In the next comparison, the "current version of the source file" modified by the user again and the "first remote source file" can be compared to select the modified part to form the latest modified file.

[0058] In some embodiments, before the path mapping and session isolation, the method further comprises: the remote server is pre-configured to disable or unassign the local development environment drive letter, so as to reserve the drive letter for mounting of the session-level virtual disk.

[0059] In order to avoid conflicts with existing system drive letters, the remote server will reserve a drive letter for mounting the virtual disk. This reservation process is automated, ensuring that the user can use the virtual disk immediately after logging in without manual configuration.

[0060] In some embodiments, all steps of the above method, including path mapping, incremental synchronization, remote compilation and incremental return, are automatically triggered and executed by an automated script to achieve transparent operation for the user.

[0061] It should be noted that the user only needs to execute one command, and the path mapping, incremental synchronization, remote building and return steps will be automatically completed. The automated script simplifies the operation process, avoids manual intervention by the user, and makes the entire remote building process transparent and efficient.

[0062] Based on the above embodiments, the technical effects of the present application are: (1) The embodiments of the present application create a session-level virtual disk consistent with the local drive letter for each SSH session on the remote server by using operating system commands, ensuring the absolute consistency of the remote compilation path and the local development path. The source code debugging path embedded in the target file generated by compilation is exactly the same as the local compilation result, solving the defect that local breakpoint debugging cannot be performed due to inconsistent paths. (2) The application embodiment utilizes the independent user directory automatically created by the operating system for each login user, and a virtual working directory is created under the private directory and is only mapped to the current SSH session, which makes the build environment of each user achieve namespace separation at the file system level, and the users are invisible and do not interfere with each other, allowing multiple users to safely and simultaneously build on the same server, fully utilizing the multi-core computing performance of the server, and avoiding the efficiency bottleneck of traditional task queuing; (3) The application embodiment, through the incremental synchronization tool, only transmits the changed files when pushing the source code and returning the target files, reduces the data transmission amount, is significantly faster than the full-pull of the traditional system, and allows the developer to directly compile the local uncommitted code remotely, without relying on the code repository, avoiding the version pollution caused by frequent submission of code for debugging, and fitting the daily development stage of high-frequency modification, compilation and debugging workflow.

[0063] (4) The application embodiment integrates all steps including SSH login, remote directory creation, virtual disk mounting, incremental synchronization push, trigger compilation, incremental return, and automatic cleaning after session exit through an automatic script, and the user only needs to execute a command locally, that is, the entire remote build process can be completed, which is completely transparent to the user and does not need to manually log in to the remote system for web operation or complex environment configuration.

[0064] In some embodiments, after exiting the current SSH session, the method further comprises: starting a debugging tool in the local development environment, and loading the local synchronization target file set for breakpoint debugging.

[0065] It should be noted that after the "remote target file set" is returned, the user can directly load these files in the local development environment and start the debugging tool for debugging. Since the target files of the remote build ("remote target file set") are consistent with the local at the path and debugging information level, the developer can seamlessly perform breakpoint debugging.

[0066] In some embodiments, refer to Figure 3As shown, first, the user executes an automation script, such as remote_build.sh, on the local development end, the automation script checks whether the current project path is located on the D: disk, and logs in to the remote build server through an SSH client, after successful login, the automation script sends a mkdir command through SSH, specifically: mkdir C:\Users\username\virtual_D; creates a virtual working directory on the remote server, which is located in the private directory of the current user, and second, the automation script sends an operating system drive letter mapping command, which is the subst command in the Windows environment, specifically: subst D: C:\Users\username\virtual_D; so that a session-level virtual D disk is created in the current SSH session; then, the automation script executes an rsync incremental synchronization command locally, specifically: rsync -avz --delete / D / work / project / user@remote_server: / D / work / project / ; synchronizes the local project files (i.e., source code, source files) to the corresponding directory under the remote virtual disk (session-level virtual D disk), it should be noted that this process is based on the file content verification algorithm of tools such as rsync, and only the changed files (changed files) are transmitted, greatly reducing the transmission time and improving the efficiency of remote building; then the automation script sends a build command to the remote server through SSH, which must first switch to the virtual D disk and then enter the working path to execute the build script, specifically: ssh user@remote_server "D: && cd D:\work\project && build.bat"; after the remote build is completed, the automation script executes the incremental synchronization command again, which pulls the remote build product folder (remote target file folder) back to the corresponding directory on the local development end, at this time, the developer can obtain the target file (local synchronization target file set) which is completely consistent with the local compilation path information under the path D:\work\project\build\ on the local development end, which can be directly used for breakpoint debugging in the local integrated development environment; finally, after the compilation is completed, the automation script or the user exits the SSH session, and because the virtual D disk mounted by subst is session-level, when the SSH session is disconnected (SSH connection is disconnected), the virtual D disk will automatically disappear and be unmapped, at this time, the D disk symbol resource on the server is released and can be used by other new sessions, the entire process does not require any manual cleaning on the server side, and the use-once-and-go of multiple users is realized.

[0067] Based on the above embodiment, using the session-based virtual disk mapping mechanism, it is ensured that the remote server and the local development environment are completely consistent in the path structure, so that the source file path recorded in the debugging information of the target file generated by the compilation is consistent with the local; and the build environment of each user is independent of each other, and is isolated based on the SSH session-level virtual disk, supporting multiple users to build in parallel at the same time without interference; at the same time, the incremental synchronization mechanism is adopted, only the changed files are transmitted, efficient data synchronization and build result feedback are realized, and the build speed is significantly improved; the whole process control is realized through the automatic script, including path detection, remote login, directory creation, virtual disk mounting, compilation triggering and result feedback, without manual intervention; the remote compilation result is completely consistent with the local compilation result in the binary structure and the debugging information, and can be directly used for breakpoint debugging and symbol analysis on the local, the overall deployment mode is simple, depends on the system self-provided command and common tools, has strong compatibility, and is easy to popularize to different compilation environments and projects.

[0068] The embodiment of the application further provides a multi-user remote building device, referring to Figure 4 as shown in the figure, comprising: The login module 401 is configured to log in to a remote server, and the remote server creates a virtual working directory under an independent user directory of a current SSH session; The creation module 402 is configured to mount the virtual working directory as a session-level virtual disk consistent with a local development environment disk symbol based on an operating system command, to obtain a path mapping environment in which a remote compilation path is consistent with a local development path; The incremental pushing module 403 is configured to run an incremental synchronization tool to synchronize changed files and a build script of the local development environment to corresponding paths in the session-level virtual disk based on the path mapping environment, to obtain a remote synchronization code set, and the path of the remote synchronization code set in the session-level virtual disk is consistent with the path of the changed files; The execution module 404 is configured to remotely execute the build script to start a compilation process to process the remote synchronization code set, to obtain a remote target file set; The incremental feedback module 405 is configured to run the incremental synchronization tool to feed back the remote target file set to corresponding paths of the local development environment, to obtain a local synchronization target file set.

[0069] The embodiment of the application further provides an electronic device, which comprises a processor and a memory for storing processor-executable instructions, and the processor executes the instructions to implement the steps of the method of any one of the above embodiments.

[0070] The embodiment of the application further provides a computer-readable storage medium, which stores a computer program, and the computer program is loaded by a processor to execute the steps of the method of any one of the above embodiments.

[0071] In the embodiments of the present application, the storage medium can be a magnetic disk, an optical disk, a read only memory (ROM), or a random access memory (RAM), etc.

[0072] In the above embodiments, the description of each embodiment has its own focus, and the parts not described in detail in a certain embodiment can be referred to the related description of other embodiments.

[0073] The above describes in detail a multi-user remote construction method, device and electronic equipment provided by the embodiments of the present application. The principles and implementation manners of the present application are described by applying specific examples. The above embodiment description is only used to help understand the method and its core idea of the present application. Meanwhile, for those skilled in the art, the specific implementation manners and application ranges will be changed according to the idea of the present application. In summary, the content of the specification should not be understood as a limitation of the present application.

Claims

1. A multi-user remote construction method, characterized in that, include: Log in to the remote server, which creates a virtual working directory in the independent user directory of the current SSH session; The virtual working directory is mounted as a session-level virtual disk with the same drive letter as the local development environment based on operating system commands, so as to obtain a path mapping environment in which the remote compilation path is consistent with the local development path. Based on the path mapping environment, the incremental synchronization tool is run to synchronize the modified files and build scripts in the local development environment to the corresponding paths in the session-level virtual disk to obtain a remote synchronized code set. The path of the remote synchronized code set in the session-level virtual disk is consistent with the path of the modified files. The build script is executed remotely to initiate the compilation process to process the remote synchronous code set and obtain the remote target file set. The incremental synchronization tool is run to send the remote target file set back to the corresponding path in the local development environment to obtain the local synchronized target file set.

2. The multi-user remote construction method according to claim 1, characterized in that, The remote server operates on a Windows system, and the operating system command is the subst command. The session-level virtual disk uses the subst command to map the virtual working directory to the local development environment drive letter.

3. The multi-user remote construction method according to claim 1, characterized in that, Before running the incremental synchronization tool to synchronize the modified files and build scripts in the local development environment to the corresponding paths in the session-level virtual disk, the method further includes: Obtain the source files for the initial version of the local development environment; Send the initial version of the source file to the remote server; Modify the source files of the initial version in the local development environment to obtain the source files of the current version in the local development environment; By comparing the current version of the source file with the initial version of the source file on the remote server, the parts in the current version of the source file that differ from the initial version of the source file on the remote server are selected to obtain the modified file.

4. The multi-user remote construction method according to claim 1, characterized in that, The remote execution of the build script in the remotely synchronized code set to start the compilation process includes: switching to the drive letter of the session-level virtual disk via SSH command, then entering the corresponding working path in the session-level virtual disk, and executing the build script.

5. The multi-user remote construction method according to claim 1, characterized in that, The remote server is pre-configured to disable or not assign the local development environment drive letter, so as to reserve the drive letter for mounting the session-level virtual disk.

6. The multi-user remote construction method according to claim 1, characterized in that, After running the incremental synchronization tool to send the remote target file set back to the corresponding path in the local development environment to obtain the local synchronized target file set, the method further includes: exiting the current SSH session, the session-level virtual disk automatically disappears and releases the disk resources it occupies.

7. A multi-user remote construction method according to claim 6, characterized in that, After exiting the current SSH session, the method further includes: Start the debugging tool in the local development environment and load the local synchronized target file set for breakpoint debugging.

8. A multi-user remote construction device, characterized in that, include: The login module is used to log in to a remote server, which creates a virtual working directory in the independent user directory of the current SSH session; A module is created to mount the virtual working directory as a session-level virtual disk with the same drive letter as the local development environment based on operating system commands, so as to obtain a path mapping environment where the remote compilation path is consistent with the local development path; The incremental push module, based on the path mapping environment, runs an incremental synchronization tool to synchronize the modified files and build scripts in the local development environment to the corresponding paths in the session-level virtual disk to obtain a remote synchronization code set. The path of the remote synchronization code set in the session-level virtual disk is consistent with the path of the modified files. The execution module is used to remotely execute the build script to start the compilation process to process the remote synchronous code set and obtain the remote target file set; The incremental backhaul module is used to run the incremental synchronization tool to backhaul the remote target file set to the corresponding path in the local development environment, so as to obtain the local synchronized target file set.

9. An electronic device, characterized in that, The electronic device includes a processor and a memory for storing processor-executable instructions, wherein the processor executes the instructions to implement the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, It stores a computer program, which is loaded by a processor to perform the steps of the method according to any one of claims 1 to 7.

Images