CN111752595A - 文件打包方法、装置、设备及存储介质 - Google Patents
文件打包方法、装置、设备及存储介质 Download PDFInfo
- Publication number
- CN111752595A CN111752595A CN202010602486.1A CN202010602486A CN111752595A CN 111752595 A CN111752595 A CN 111752595A CN 202010602486 A CN202010602486 A CN 202010602486A CN 111752595 A CN111752595 A CN 111752595A
- Authority
- CN
- China
- Prior art keywords
- packaging
- source code
- code
- micro service
- file
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/70—Software maintenance or management
- G06F8/71—Version control; Configuration management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/34—Network arrangements or protocols for supporting network services or applications involving the movement of software or configuration parameters
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/06—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols the encryption apparatus using shift registers or memories for block-wise or stream coding, e.g. DES systems or RC4; Hash functions; Pseudorandom sequence generators
- H04L9/0643—Hash functions, e.g. MD5, SHA, HMAC or f9 MAC
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Software Systems (AREA)
- General Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Physics & Mathematics (AREA)
- Signal Processing (AREA)
- General Physics & Mathematics (AREA)
- Bioethics (AREA)
- General Health & Medical Sciences (AREA)
- Computer Hardware Design (AREA)
- Health & Medical Sciences (AREA)
- Power Engineering (AREA)
Abstract
本发明公开一种文件打包方法、装置、设备及存储介质,该方法包括:在接收到文件打包指令时,从代码仓库中获取待打包的微服务项目源码;根据微服务项目源码确定对应的源码打包环境以及源码打包方式;基于源码打包环境,按源码打包方式对微服务项目源码进行打包,获得可执行的程序包。由于本发明在进行源码打包时是从远端的代码仓库中获取源码,因而避免了对微服务项目进行打包时对本地代码的依赖,扩大了文件打包的应用场景,又因为是根据源码来确定对应的源码打包环境以及源码打包方式,再根据源码打包环境以及源码打包方式对源码进行打包,从而能够有针对性的对不同的源码进行准确打包,有效减少人工参与打包操作,进一步地提高了打包效率。
Description
技术领域
本发明涉及计算机软件技术领域,尤其涉及一种文件打包方法、装置、设备及存储介质。
背景技术
Docker容器技术当下越来越火热,很多企业都开始采用Docker容器进行云环境或者私有化环境的应用部署。Docker容器技术将软件运行所需要的环境全部在宿主机之上打包成一个个镜像,只要在任何有docker环境的地方运行打包好的镜像就可以将一整套的程序快速的跑起来。
如今,许多软件系统都采用微服务的架构,很多功能都被划分到一个个独立的微服务中去。Docker容器技术提供的docker-compose容器编排技术可以很好的将一个微服务架构系统的每个服务都编排进一个文件中,然后通过docker-compose就可以一键启动整个微服务程序。
目前很多采用docker-compose进行微服务容器编排的方式,大都是先将每个微服务的程序在本地打包好之后,再将一个个打包好的微服务的程序包通过容器挂载的方式完成微服务容器的编排。但这种方式存在:程序打包需依赖本地代码,程序打包需要开发人员参与,以及容器编排部署效率过低的缺点。
上述内容仅用于辅助理解本发明的技术方案,并不代表承认上述内容是现有技术。
发明内容
本发明的主要目的在于提供了一种文件打包方法、装置、设备及存储介质,旨在解决现有的微服务容器编排方式对微服务项目进行打包时依赖本地代码,且需人工参与、打包效率不高的技术问题。
为实现上述目的,本发明提供了一种文件打包方法,所述方法包括以下步骤:
在接收到文件打包指令时,从代码仓库中获取待打包的微服务项目源码;
根据所述微服务项目源码确定对应的源码打包环境以及源码打包方式;
基于所述源码打包环境,按所述源码打包方式对所述微服务项目源码进行打包,获得可执行的程序包。
优选地,所述根据所述微服务项目源码确定对应的源码打包环境以及源码打包方式的步骤之前,所述方法还包括:
对所述微服务项目源码进行哈希值计算,获得待校验哈希值;
从所述代码仓库中获取所述微服务项目源码对应的基准哈希值;
判断所述待校验哈希值与所述基准哈希值是否一致;
在所述待校验哈希值与所述基准哈希值一致时,执行所述根据所述微服务项目源码确定对应的源码打包环境以及源码打包方式的步骤。
优选地,所述在接收到文件打包指令时,从代码仓库中获取待打包的微服务项目源码的步骤,包括:
在接收到文件打包指令时,读取所述文件打包指令中携带的代码仓库地址;
根据所述代码仓库地址从代码仓库中进行源码拉取操作,并统计对应的源码拉取时长;
在所述源码拉取时长达到预设时长阈值时,检测对待打包的微服务项目源码的拉取是否完成;
若否,则停止源码拉取操作,并根据所述代码仓库地址重新从所述代码仓库中拉取待打包的微服务项目源码。
优选地,所述根据所述微服务项目源码确定对应的源码打包环境以及源码打包方式的步骤,包括:
获取所述微服务项目源码对应的代码语言类型;
根据所述代码语言类型在预先构建的映射关系中查找对应的源码打包环境,所述映射关系中包含代码语言类型和源码打包环境之间的对应关系;
获取所述源码打包环境对应的源码打包方式。
优选地,所述基于所述源码打包环境,按所述源码打包方式对所述微服务项目源码进行打包,获得可执行的程序包的步骤,包括:
获取预置Dockerfile文件,并根据所述源码打包方式从所述预置Dockerfile文件读取对应的打包命令;
运行所述源码打包环境,并根据所述打包命令对所述微服务项目源码进行打包,获得可执行的程序包。
优选地,所述运行所述源码打包环境,并根据所述打包命令对所述微服务项目源码进行打包,获得可执行的程序包的步骤,包括:
运行所述源码打包环境;
获取所述打包命令对应的命令执行顺序,根据所述命令执行顺序生成命令执行序列;
根据所述命令执行序列以及所述打包命令对所述微服务项目源码进行打包,获得可执行的程序包。
优选地,所述根据所述命令执行序列以及所述打包命令对所述微服务项目源码进行打包,获得可执行的程序包的步骤,包括:
获取所述微服务项目源码对应的数据大小,并判断所述数据大小是否超过预设阈值;
在所述数据大小超过所述预设阈值时,采用异步操作根据所述命令执行序列以及所述打包命令对所述微服务项目源码进行打包,获得可执行的程序包。
此外,为实现上述目的,本发明还提出一种文件打包装置,所述文件打包装置包括:
源码拉取模块,用于在接收到文件打包指令时,从代码仓库中获取待打包的微服务项目源码;
环境配置模块,用于根据所述微服务项目源码确定对应的源码打包环境以及源码打包方式;
源码打包模块,用于基于所述源码打包环境,按所述源码打包方式对所述微服务项目源码进行打包,获得可执行的程序包。
此外,为实现上述目的,本发明还提出一种文件打包设备,所述设备包括:存储器、处理器及存储在所述存储器上并可在所述处理器上运行的文件打包程序,所述文件打包程序配置为实现如上文所述的文件打包方法的步骤。
此外,为实现上述目的,本发明还提出一种存储介质,所述存储介质上存储有文件打包程序,所述文件打包程序被处理器执行时实现如上文所述的文件打包方法的步骤。
本发明通过上述方式在接收到文件打包指令时,从代码仓库中获取待打包的微服务项目源码;根据微服务项目源码确定对应的源码打包环境以及源码打包方式;基于源码打包环境,按源码打包方式对微服务项目源码进行打包,获得可执行的程序包。由于本发明在进行源码打包时是从远端的代码仓库中获取源码,因而避免了对微服务项目进行打包时对本地代码的依赖,又因为本发明是根据源码来确定对应的源码打包环境以及源码打包方式,再根据源码打包环境以及源码打包方式对源码自动进行打包,从而能够有效的减少人工参与打包操作,打包效率上也有明显的提高。
附图说明
图1是本发明实施例方案涉及的硬件运行环境的文件打包设备的结构示意图;
图2为本发明文件打包方法第一实施例的流程示意图;
图3为本发明文件打包方法第二实施例的流程示意图;
图4为本发明文件打包方法第三实施例的流程示意图;
图5为本发明文件打包装置第一实施例的结构框图。
本发明目的的实现、功能特点及优点将结合实施例,参照附图做进一步说明。
具体实施方式
应当理解,此处所描述的具体实施例仅用以解释本发明,并不用于限定本发明。
参照图1,图1为本发明实施例方案涉及的硬件运行环境的文件打包设备结构示意图。
如图1所示,该文件打包设备可以包括:处理器1001,例如中央处理器(CentralProcessing Unit,CPU),通信总线1002、用户接口1003,网络接口1004,存储器1005。其中,通信总线1002用于实现这些组件之间的连接通信。用户接口1003可以包括显示屏(Display)、输入单元比如键盘(Keyboard),可选用户接口1003还可以包括标准的有线接口、无线接口。网络接口1004可选的可以包括标准的有线接口、无线接口(如无线保真(WIreless-FIdelity,WI-FI)接口)。存储器1005可以是高速的随机存取存储器(RandomAccess Memory,RAM)存储器,也可以是稳定的非易失性存储器(Non-Volatile Memory,NVM),例如磁盘存储器。存储器1005可选的还可以是独立于前述处理器1001的存储装置。
本领域技术人员可以理解,图1中示出的结构并不构成对文件打包设备的限定,可以包括比图示更多或更少的部件,或者组合某些部件,或者不同的部件布置。
如图1所示,作为一种存储介质的存储器1005中可以包括操作系统、数据存储模块、网络通信模块、用户接口模块以及文件打包程序。
在图1所示的文件打包设备中,网络接口1004主要用于与网络服务器进行数据通信;用户接口1003主要用于与用户进行数据交互;本发明文件打包设备中的处理器1001、存储器1005可以设置在文件打包设备中,所述文件打包设备通过处理器1001调用存储器1005中存储的文件打包程序,并执行本发明实施例提供的文件打包方法。
本发明实施例提供了一种文件打包方法,参照图2,图2为本发明文件打包方法第一实施例的流程示意图。
本实施例中,所述文件打包方法包括以下步骤:
步骤S10:在接收到文件打包指令时,从代码仓库中获取待打包的微服务项目源码;
需要说明的是,本实施例方法的执行主体可以是在传统的微服务容器编排解决方案的基础上新增的一个专用于代码打包的软件工具或组件(以下简称打包服务容器)。本实施例在执行所述步骤S10之前,需预先在所述打包服务容器中配置整个微服务项目打包所需要的环境(如maven环境、gradle环境、npm环境、jdk环境等),然后在对应的打包环境中执行代码文件的打包操作。本实施例及下述各实施例中所谓的环境可指对微服务应用服务程序(微服务项目)打包时所依赖的打包配置。所述代码仓库中可以是设置在远端的数据库,其中存放有不同微服务项目对应的源代码。
应理解的是,所述文件打包指令中可携带有用来从代码仓库中获取待打包的微服务项目源码的数据信息,这些数据信息可以是微服务项目对应的项目标识,也可以是微服务项目的源码(源代码)存放在代码仓库中的代码仓库地址或存放路径等。
在具体实现中,打包服务容器在接收到文件打包指令时,响应于该文件打包指令,从代码仓库中拉取待打包的微服务项目源码。
进一步地,考虑到实际应用中,打包服务容器需要通过拉取代码仓库中的源码才能进行下一步的打包过程,而代码托管一般都会采用git(一种开源的分布式版本控制系统)或者svn(一种开放源代码的版本控制系统)的方式。这两种代码托管方式都是采用C/S的架构进行设计的,存放源码的为非本地的服务端仓库,因而从服务端仓库拉取代码就需要预先配置好相应的客户端。因此本实施例打包服务容器在进行打包操作前,需要先在打包服务容器中配置对应的git/svn客户端,然后通过git/svn客户端从代码仓库中拉取对应的微服务项目源码。
应理解的是,采用git/svn客户端拉取源码的过程其实就是文件在两个服务器间进行传输的过程,因此传输过程中可能会存在超时或者丢包的情况。为了保证源码从代码仓库中拉取时的完整性,本实施例优选通过源码哈希值校验机制来保证代码拉取的完整性。
本实施例中,所述源码的哈希值校验机制可具体包括:对所述微服务项目源码进行哈希值计算,获得待校验哈希值;然后从所述代码仓库中获取所述微服务项目源码对应的基准哈希值;再判断所述待校验哈希值与所述基准哈希值是否一致;在所述待校验哈希值与所述基准哈希值一致时,再执行下述步骤S20,若所述待校验哈希值与所述基准哈希值不一致,就需要重新从代码仓库中拉取所述微服务项目源码。
本实施例中,所述基准哈希值可以是微服务项目源码在存放至代码仓库时对应的哈希值。所述哈希值计算可以通过消息摘要算法来实现,例如哈希算法、MD5算法、MAC算法等,具体算法的选择本实施例不加以限制。
步骤S20:根据所述微服务项目源码确定对应的源码打包环境以及源码打包方式;
可理解的是,打包服务容器在打包过程中可能会面临着不同编程语言开发的应用服务程序,而每一个应用服务程序的打包方式又是各不相同的。比如,java应用程序的打包方式存在maven打包方式、ivy打包方式、gradle打包方式等。每一种打包方式要想成功的将应用程序打包出正常的、可执行的程序包,就需要在相应的打包环境下来进行打包操作。
在具体实现中,打包服务容器在获取到微服务项目源码后,即可确定对应的源码打包环境以及源码打包方式,然后执行后续的打包操作。
进一步地,考虑到不同的微服务项目的打包环境和打包方式不一定相同,若针对每一个微服务项目,打包服务容器都采用遍历数据库的方式去确定该微服务项目对应的源码打包环境和源码打包方式,将会大大影响打包效率。因此本实施例中可预先在打包服务容器中构建一个代码语言类型(也可称为编程语言类型)和源码打包环境之间的映射关系,使得打包服务容器在获取到微服务项目源码时,先确定源码所属的代码语言类型,然后在映射关系中查找对应的源码打包环境,再获取对应的源码打包方式。
具体的,打包服务容器可获取所述微服务项目源码对应的代码语言类型;然后根据所述代码语言类型在预先构建的映射关系中查找对应的源码打包环境,所述映射关系中包含代码语言类型和源码打包环境之间的对应关系;再获取所述源码打包环境对应的源码打包方式。
需要说明的是,本实施例中所述映射关系可以映射表的方式进行存储,也可以键值对Map<K,V>的方式进行存储。其中,以键值对Map<K,V>的方式进行存储时,K为代码语言类型,V为源码打包环境。
步骤S30:基于所述源码打包环境,按所述源码打包方式对所述微服务项目源码进行打包,获得可执行的程序包。
可理解的是,不同打包环境对应的打包方式不同,不同打包方式对应的打包命令也不同。为在打包过程中快速获取每一种打包方式所对应的打包命令,本实施例可将每类打包方式对应的打包命令编写在相应的dockerfile文件中,需要打包时对dockerfile文件进行解析即可获取。
在具体实现中,打包服务容器可运行微服务项目对应的源码打包环境,然后根据源码打包方式中所包含的打包命令对微服务项目源码进行打包,获得可执行的程序包。
进一步地,由于现有的微服务容器编排中,打包好的程序包需要放置到指定的目录微服务容器才能进行加载,因此本实施例打包服务容器采用将可执行的程序包共享至预先采用docker容器(volume)技术构建的共享数据容器中,以使微服务的容器可从所述共享数据容器中拉取对应的程序包并直接进行程序包的加载,省去了程序包需要存放在指定目录才能加载的操作。
需要说明的是,docker volume,即docker的数据卷容器,它是docker容器的一种数据持久化的技术。该数据卷容器是可以在多个其他容器间进行数据共享,其他容器也可以对该数据卷容器进行数据读取。在本方案中,打包服务容器将打包好的程序包写进共享的数据卷容器中,其他各个微服务的容器可从该数据卷中读取自己需要的程序包。
进一步地,本实施例中微服务从共享数据容器中获得程序包时,也将进行程序包的完整性校验。具体的,打包服务容器从远端的代码仓库拉取完整的微服务项目源码并打包好之后,获取程序包的散列值作为该程序包的校验码,其他的容器(包括共享数据容器和微服务容器1…n)读取所需要的程序包之后会再次对读取到的程序包进行散列值计算得到散列值,然后将两个散列值进行比对,再根据比对结果判断程序包的完整性,从而能够保证每一次程序包的传输都能不会出现程序包不完整的情况。
本实施例通过上述方式在接收到文件打包指令时,从代码仓库中获取待打包的微服务项目源码;根据微服务项目源码确定对应的源码打包环境以及源码打包方式;基于源码打包环境,按源码打包方式对微服务项目源码进行打包,获得可执行的程序包。由于本实施例在进行源码打包时是从远端的代码仓库中获取源码,因而避免了对微服务项目进行打包时对本地代码的依赖,又因为本实施例是根据源码来确定对应的源码打包环境以及源码打包方式,再根据源码打包环境以及源码打包方式对源码自动进行打包,从而能够有效的减少人工参与打包操作,打包效率上也有明显的提高。
参考图3,图3为本发明文件打包方法第二实施例的流程示意图。
基于上述第一实施例,在本实施例中,所述步骤S10包括:
步骤S101:在接收到文件打包指令时,读取所述文件打包指令中携带的代码仓库地址;
应理解的是,考虑到传统的微服务程序代码的打包方式需要依赖本地代码,本实施例中优选采用将微服务项目源码存放在远端代码仓库中,使得打包服务容器能够根据微服务项目对应的代码仓库地址随时随地的获取待打包的微服务项目源码,进而避免对本地代码的依赖。
在具体实现中,打包服务容器可在接收到文件打包指令时,对指令进行解析,然后从解析结果中读取所述代码仓库地址。
步骤S102:根据所述代码仓库地址从代码仓库中进行源码拉取操作,并统计对应的源码拉取时长;
需要说明的是,为进一步保证代码拉取的完整性,本实施例在上述源码哈希值校验机制的基础上还增加了源码拉取的超时重试机制。
具体的,打包服务容器还将从执行源码拉取操作开始,统计本次源码拉取操作的源码拉取时长,然后将该源码拉取时长与预先设定的时长阈值进行比较,若在源码拉取时长未达到预设时长阈值时,打包服务容器已经完成了对待打包的微服务项目源码的拉取,则不会触发上述超时重试机制。
步骤S103:在所述源码拉取时长达到预设时长阈值时,检测对待打包的微服务项目源码的拉取是否完成;
需要说明的是,本步骤中检测对待打包的微服务项目源码的拉取是否完成可采用多种方式:
作为一种实施手段,该检测方式可以是:获取源码拉取时长达到预设时长阈值时已经拉取的微服务项目源码,然后计算这部分微服务项目源码的哈希值,再将计算的哈希值与微服务项目源码对应的基准哈希值进行比较,若不一致,则表明拉取未完成;反之则表明拉取完成。
作为另一种实施手段,该检测方式还可以是:获取源码拉取时长达到预设时长阈值时已经拉取的微服务项目源码对应的数据大小,将该数据大小与代码仓库中存放的微服务项目源码的数据大小进行比较,若不一致,则表明拉取未完成;反之则表明拉取完成。
当然,在具体实现中还可以采用其他的检测方式,本实施例此处仅做举例,并不代表对检测方式的限定。
步骤S104:若否,则停止源码拉取操作,并根据所述代码仓库地址重新从所述代码仓库中拉取待打包的微服务项目源码。
在具体实现中,若在源码拉取时长达到预设时长阈值时,对待打包的微服务项目源码的拉取还未完成,则立刻停止当前的源码拉取操作,然后根据代码仓库地址重新从代码仓库中拉取待打包的微服务项目源码。
本实施例打包服务容器在接收到文件打包指令时,读取所述文件打包指令中携带的代码仓库地址;根据所述代码仓库地址从代码仓库中进行源码拉取操作,并统计对应的源码拉取时长;在所述源码拉取时长达到预设时长阈值时,检测对待打包的微服务项目源码的拉取是否完成;若否,则停止源码拉取操作,并根据所述代码仓库地址重新从所述代码仓库中拉取待打包的微服务项目源码,本实施例通过建立这种源码拉取的超时重试机制能够有效的避免因打包服务容器与代码仓库所在服务器之间的通信信号不佳,导致源码拉取长时间无法完成的情况,保证了源码打包的顺利进行。
参考图4,图4为本发明文件打包方法第三实施例的流程示意图。
基于上述各实施例,在本实施例中,所述步骤S30可包括:
步骤S301:获取预置Dockerfile文件,并根据所述源码打包方式从所述预置Dockerfile文件读取对应的打包命令;
由上述第一实施例可知,每种打包方式对应的打包命令编写在相应的dockerfile文件中,因此打包服务容器在获取到预先配置的dockerfile文件时,可先对该dockerfile文件进行解析,然后根据源码打包方式从文件解析结果中匹配查找出对应的打包命令。
应理解的是,dockerfile文件的文件结构可大致分为四个部分:基础镜像信息、维护者信息、镜像操作指令和容器启动时执行指令。本实施例中的打包命令可存放在上述容器启动时执行指令这一部分中。
步骤S302:运行所述源码打包环境,并根据所述打包命令对所述微服务项目源码进行打包,获得可执行的程序包。
进一步地,为提高打包效率,本实施例中打包命令在存放时,还可以将这些命令的执行顺序一并存放,以便后续执行打包命令时及时获取。
在具体实现中,打包服务容器可先运行所述源码打包环境,然后从dockerfile文件中获取所述打包命令对应的命令执行顺序,根据所述命令执行顺序生成命令执行序列;最后再根据所述命令执行序列以及所述打包命令对所述微服务项目源码进行打包,获得可执行的程序包。其中,所述命令执行序列,即打包命令执行顺序构成的命令执行链。
进一步地,考虑到不同微服务项目的数据大小不同,需要打包的文件总量也不同,对于文件总量较大的微服务项目而言,采用单线程打包的方式会导致打包效率较慢,因此本实施例中打包服务容器可在微服务项目源码对应的数据大小超过一定的大小时,采用多线程异步操作的方式进行源码的打包。
具体的,打包服务容器可先获取所述微服务项目源码对应的数据大小,并判断所述数据大小是否超过预设阈值;然后在所述数据大小超过所述预设阈值时,采用异步操作根据所述命令执行序列以及所述打包命令对所述微服务项目源码进行打包,获得可执行的程序包。
本实施例通过获取预置Dockerfile文件,并根据所述源码打包方式从所述预置Dockerfile文件读取对应的打包命令;运行所述源码打包环境,并根据所述打包命令对所述微服务项目源码进行打包,获得可执行的程序包,能够保证打包命令的准确获取,也能够保证源码打包时的打包效率。
此外,本发明实施例还提出一种存储介质,所述存储介质上存储有文件打包程序,所述文件打包程序被处理器执行时实现如上文所述的文件打包方法的步骤。
参照图5,图5为本发明文件打包装置第一实施例的结构框图。
如图5所示,本发明实施例提出的文件打包装置包括:
源码拉取模块501,用于在接收到文件打包指令时,从代码仓库中获取待打包的微服务项目源码;
环境配置模块502,用于根据所述微服务项目源码确定对应的源码打包环境以及源码打包方式;
源码打包模块503,用于基于所述源码打包环境,按所述源码打包方式对所述微服务项目源码进行打包,获得可执行的程序包。
本实施例文件打包装置在接收到文件打包指令时,从代码仓库中获取待打包的微服务项目源码;根据微服务项目源码确定对应的源码打包环境以及源码打包方式;基于源码打包环境,按源码打包方式对微服务项目源码进行打包,获得可执行的程序包。由于本实施例在进行源码打包时是从远端的代码仓库中获取源码,因而避免了对微服务项目进行打包时对本地代码的依赖,又因为本实施例是根据源码来确定对应的源码打包环境以及源码打包方式,再根据源码打包环境以及源码打包方式对源码自动进行打包,从而能够有效的减少人工参与打包操作,打包效率上也有明显的提高。
基于本发明上述文件打包装置第一实施例,提出本发明文件打包装置的第二实施例。
在本实施例中,所述源码拉取模块501,还用于对所述微服务项目源码进行哈希值计算,获得待校验哈希值;从所述代码仓库中获取所述微服务项目源码对应的基准哈希值;判断所述待校验哈希值与所述基准哈希值是否一致;在所述待校验哈希值与所述基准哈希值一致时,执行所述根据所述微服务项目源码确定对应的源码打包环境以及源码打包方式的操作。
进一步地,所述源码拉取模块501,还用于在接收到文件打包指令时,读取所述文件打包指令中携带的代码仓库地址;根据所述代码仓库地址从代码仓库中进行源码拉取操作,并统计对应的源码拉取时长;在所述源码拉取时长达到预设时长阈值时,检测对待打包的微服务项目源码的拉取是否完成;若否,则停止源码拉取操作,并根据所述代码仓库地址重新从所述代码仓库中拉取待打包的微服务项目源码。
进一步地,所述环境配置模块502,还用于获取所述微服务项目源码对应的代码语言类型;根据所述代码语言类型在预先构建的映射关系中查找对应的源码打包环境,所述映射关系中包含代码语言类型和源码打包环境之间的对应关系;获取所述源码打包环境对应的源码打包方式。
进一步地,所述源码打包模块503,还用于获取预置Dockerfile文件,并根据所述源码打包方式从所述预置Dockerfile文件读取对应的打包命令;运行所述源码打包环境,并根据所述打包命令对所述微服务项目源码进行打包,获得可执行的程序包。
进一步地,所述源码打包模块503,还用于运行所述源码打包环境;获取所述打包命令对应的命令执行顺序,根据所述命令执行顺序生成命令执行序列;根据所述命令执行序列以及所述打包命令对所述微服务项目源码进行打包,获得可执行的程序包。
进一步地,所述源码打包模块503,还用于获取所述微服务项目源码对应的数据大小,并判断所述数据大小是否超过预设阈值;在所述数据大小超过所述预设阈值时,采用异步操作根据所述命令执行序列以及所述打包命令对所述微服务项目源码进行打包,获得可执行的程序包。
本发明文件打包装置的其他实施例或具体实现方式可参照上述各方法实施例,此处不再赘述。
需要说明的是,在本文中,术语“包括”、“包含”或者其任何其他变体意在涵盖非排他性的包含,从而使得包括一系列要素的过程、方法、物品或者系统不仅包括那些要素,而且还包括没有明确列出的其他要素,或者是还包括为这种过程、方法、物品或者系统所固有的要素。在没有更多限制的情况下,由语句“包括一个……”限定的要素,并不排除在包括该要素的过程、方法、物品或者系统中还存在另外的相同要素。
上述本发明实施例序号仅仅为了描述,不代表实施例的优劣。
通过以上的实施方式的描述,本领域的技术人员可以清楚地了解到上述实施例方法可借助软件加必需的通用硬件平台的方式来实现,当然也可以通过硬件,但很多情况下前者是更佳的实施方式。基于这样的理解,本发明的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来,该计算机软件产品存储在一个存储介质(如只读存储器/随机存取存储器、磁碟、光盘)中,包括若干指令用以使得一台终端设备(可以是手机,计算机,服务器,空调器,或者网络设备等)执行本发明各个实施例所述的方法。
以上仅为本发明的优选实施例,并非因此限制本发明的专利范围,凡是利用本发明说明书及附图内容所作的等效结构或等效流程变换,或直接或间接运用在其他相关的技术领域,均同理包括在本发明的专利保护范围内。
Claims (10)
1.一种文件打包方法,其特征在于,所述方法包括:
在接收到文件打包指令时,从代码仓库中获取待打包的微服务项目源码;
根据所述微服务项目源码确定对应的源码打包环境以及源码打包方式;
基于所述源码打包环境,按所述源码打包方式对所述微服务项目源码进行打包,获得可执行的程序包。
2.如权利要求1所述的方法,其特征在于,所述根据所述微服务项目源码确定对应的源码打包环境以及源码打包方式的步骤之前,所述方法还包括:
对所述微服务项目源码进行哈希值计算,获得待校验哈希值;
从所述代码仓库中获取所述微服务项目源码对应的基准哈希值;
判断所述待校验哈希值与所述基准哈希值是否一致;
在所述待校验哈希值与所述基准哈希值一致时,执行所述根据所述微服务项目源码确定对应的源码打包环境以及源码打包方式的步骤。
3.如权利要求1所述的方法,其特征在于,所述在接收到文件打包指令时,从代码仓库中获取待打包的微服务项目源码的步骤,包括:
在接收到文件打包指令时,读取所述文件打包指令中携带的代码仓库地址;
根据所述代码仓库地址从代码仓库中进行源码拉取操作,并统计对应的源码拉取时长;
在所述源码拉取时长达到预设时长阈值时,检测对待打包的微服务项目源码的拉取是否完成;
若否,则停止源码拉取操作,并根据所述代码仓库地址重新从所述代码仓库中拉取待打包的微服务项目源码。
4.如权利要求1所述的方法,其特征在于,所述根据所述微服务项目源码确定对应的源码打包环境以及源码打包方式的步骤,包括:
获取所述微服务项目源码对应的代码语言类型;
根据所述代码语言类型在预先构建的映射关系中查找对应的源码打包环境,所述映射关系中包含代码语言类型和源码打包环境之间的对应关系;
获取所述源码打包环境对应的源码打包方式。
5.如权利要求1至4任一项所述的方法,其特征在于,所述基于所述源码打包环境,按所述源码打包方式对所述微服务项目源码进行打包,获得可执行的程序包的步骤,包括:
获取预置Dockerfile文件,并根据所述源码打包方式从所述预置Dockerfile文件读取对应的打包命令;
运行所述源码打包环境,并根据所述打包命令对所述微服务项目源码进行打包,获得可执行的程序包。
6.如权利要求5所述的方法,其特征在于,所述运行所述源码打包环境,并根据所述打包命令对所述微服务项目源码进行打包,获得可执行的程序包的步骤,包括:
运行所述源码打包环境;
获取所述打包命令对应的命令执行顺序,根据所述命令执行顺序生成命令执行序列;
根据所述命令执行序列以及所述打包命令对所述微服务项目源码进行打包,获得可执行的程序包。
7.如权利要求6所述的方法,其特征在于,所述根据所述命令执行序列以及所述打包命令对所述微服务项目源码进行打包,获得可执行的程序包的步骤,包括:
获取所述微服务项目源码对应的数据大小,并判断所述数据大小是否超过预设阈值;
在所述数据大小超过所述预设阈值时,采用异步操作根据所述命令执行序列以及所述打包命令对所述微服务项目源码进行打包,获得可执行的程序包。
8.一种文件打包装置,其特征在于,所述文件打包装置包括:
源码拉取模块,用于在接收到文件打包指令时,从代码仓库中获取待打包的微服务项目源码;
环境配置模块,用于根据所述微服务项目源码确定对应的源码打包环境以及源码打包方式;
源码打包模块,用于基于所述源码打包环境,按所述源码打包方式对所述微服务项目源码进行打包,获得可执行的程序包。
9.一种文件打包设备,其特征在于,所述设备包括:存储器、处理器及存储在所述存储器上并可在所述处理器上运行的文件打包程序,所述文件打包程序配置为实现如权利要求1至7中任一项所述的文件打包方法的步骤。
10.一种存储介质,其特征在于,所述存储介质上存储有文件打包程序,所述文件打包程序被处理器执行时实现如权利要求1至7任一项所述的文件打包方法的步骤。
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010602486.1A CN111752595A (zh) | 2020-06-29 | 2020-06-29 | 文件打包方法、装置、设备及存储介质 |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
CN202010602486.1A CN111752595A (zh) | 2020-06-29 | 2020-06-29 | 文件打包方法、装置、设备及存储介质 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN111752595A true CN111752595A (zh) | 2020-10-09 |
Family
ID=72677848
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN202010602486.1A Pending CN111752595A (zh) | 2020-06-29 | 2020-06-29 | 文件打包方法、装置、设备及存储介质 |
Country Status (1)
Country | Link |
---|---|
CN (1) | CN111752595A (zh) |
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN113127052A (zh) * | 2021-04-29 | 2021-07-16 | 欧冶云商股份有限公司 | 一种基于多目标文件托管的项目信息交付方法 |
CN113220337A (zh) * | 2021-03-30 | 2021-08-06 | 建信金融科技有限责任公司 | 一种版本构建方法、装置、计算机设备和存储介质 |
-
2020
- 2020-06-29 CN CN202010602486.1A patent/CN111752595A/zh active Pending
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN113220337A (zh) * | 2021-03-30 | 2021-08-06 | 建信金融科技有限责任公司 | 一种版本构建方法、装置、计算机设备和存储介质 |
CN113127052A (zh) * | 2021-04-29 | 2021-07-16 | 欧冶云商股份有限公司 | 一种基于多目标文件托管的项目信息交付方法 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN108595329B (zh) | 一种应用测试方法、装置及计算机存储介质 | |
US10871953B2 (en) | Application update method and apparatus | |
CN106484611B (zh) | 基于自动化协议适配的模糊测试方法和装置 | |
EP3353648A1 (en) | Methods and systems for uploading a program based on a target network platform | |
CN109558320B (zh) | 系统测试方法、装置、系统、设备及计算机可读存储介质 | |
CN107368339B (zh) | 容器入口程序运行方法、系统、设备及存储介质 | |
CN111752595A (zh) | 文件打包方法、装置、设备及存储介质 | |
CN110765464A (zh) | 漏洞检测方法、装置、设备及计算机存储介质 | |
CN113050984A (zh) | 资源调取方法、装置、电子设备及存储介质 | |
CN113407383A (zh) | 主备系统切换方法、装置、服务器及主备系统 | |
CN111400102A (zh) | 应用程序的变更监控方法、装置、设备及存储介质 | |
CN114598687B (zh) | 一种https数据包的抓取方法、系统及终端 | |
CN110543429A (zh) | 测试用例调试方法、装置及存储介质 | |
CN112416698B (zh) | 监控系统的扩展方法及装置、存储介质及电子设备 | |
CN114721784B (zh) | 应用运行方法、装置、电子设备及可读介质 | |
CN116756016A (zh) | 多浏览器测试方法、装置、设备、介质及程序产品 | |
CN110795156A (zh) | 移动存储器加载方法、瘦客户端、存储介质及装置 | |
CN113204483B (zh) | 应用检测方法、装置、服务器、检测程序组件以及存储介质 | |
CN112104513B (zh) | 可视化软件负载方法、装置、设备及存储介质 | |
CN111427770B (zh) | 一种资源测试方法及相关设备 | |
US20120184333A1 (en) | Apparatus and method for providing and executing content | |
CN113064601B (zh) | 动态加载文件的确定方法、装置、终端及存储介质 | |
CN111190725B (zh) | 任务处理方法、装置、存储介质及服务器 | |
CN114826635A (zh) | 端口服务探测方法、装置、设备及计算机可读存储介质 | |
CN112416792A (zh) | 应用软件兼容性检测方法、装置、设备及存储介质 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
PB01 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination |