CN113791977A

CN113791977A - 代码开发的处理方法、装置、电子设备与存储介质

Info

Publication number: CN113791977A
Application number: CN202111056953.6A
Authority: CN
Inventors: 丁皖苏; 贺东东
Original assignee: Shanghai Xianta Intelligent Technology Co Ltd
Current assignee: Shanghai Xianta Intelligent Technology Co Ltd
Priority date: 2021-09-09
Filing date: 2021-09-09
Publication date: 2021-12-14

Abstract

本发明提供了一种代码开发的处理方法、装置、电子设备与存储介质，代码开发的处理方法，包括：若所述目标代码为测试分支的待发布代码，则确定目标环境为单元测试环境；若所述目标代码为主开发分支的待发布代码，则确定目标环境为开发环境；若所述目标代码为发布分支的待发布代码，则确定目标环境包括集成测试环境、预生产环境与真实生产环境；所述发布分支的代码源自所述主开发分支；将所述目标代码发布于所述目标环境；若有新版本的代码发布于所述真实生产环境，则将所述新版本的代码更新于所述主分支。

Description

代码开发的处理方法、装置、电子设备与存储介质

技术领域

本发明涉及代码开发领域，尤其涉及一种代码开发的处理方法、装置、电子设备与存储介质。

背景技术

现有相关技术中，可基于分支对代码的流转进行管理，在此基础上，可将分支的代码发布到各种环境中完成代码的测试、上线，然而，一般只会采用主分支、发布分支与开发分支，对应的，通常只会采用测试环境与生产环境。可见，分支的类型与环境的类型都比较有限，进而，对代码的管理策略也就比较简单，无法满足多样的代码开发需求，也不利于对代码进行细致的规范化管理。

例如，在实际代码开发过程中，团队内部多个技术人员共同开发，所以同一份代码同时会存在于多个分支，对于代码规范管理十分不利。另外，多个团队之间也会有功能依赖，需要把不同团队的代码都部署到相同的环境进行测试、上线。

发明内容

本发明提供一种代码开发的处理方法、装置、电子设备与存储介质，以解决无法满足多样的代码开发需求的问题。

根据本发明的第一方面，提供了一种代码开发的处理方法，包括：

确定目标代码；

若所述目标代码为测试分支的待发布代码，则确定目标环境为单元测试环境；所述测试分支的待发布代码源自功能开发分支；

若所述目标代码为主开发分支的待发布代码，则确定目标环境为开发环境；所述开发主分支的至少部分待发布代码源自所述功能开发分支；

若所述目标代码为发布分支的待发布代码，则确定目标环境包括集成测试环境、预生产环境与真实生产环境；所述发布分支的代码源自所述主开发分支；

将所述目标代码发布于所述目标环境；

若有新版本的代码发布于所述真实生产环境，则将所述新版本的代码更新于所述主分支。

可选的，若所述目标代码为所述发布分支的待发布代码，则：

所述将所述目标代码发布于所述目标环境，包括：

将所述目标代码发布于所述集成测试环境；

在所述目标代码在所述集成测试环境被验证通过后，将所述目标代码发布于所述预生产环境；

在所述目标代码在所述预生产环境被验证通过后，将所述目标代码发布于所述真实生产环境。

可选的，所述将所述目标代码发布于所述真实生产环境之前，还包括：获取到手动触发指令。

可选的，所述将所述目标代码的镜像发布于所述目标环境，包括：

若所述目标环境包括所述集成测试环境，则在获取到第一手动触发指令后，将所述目标代码发布于所述集成测试环境；

若所述目标环境包括所述单元测试环境，则在获取到第二手动触发指令后，将所述目标代码发布于所述单元测试环境。

可选的，所述的代码开发的处理方法，还包括：

若所述目标代码为修复分支的待发布代码，则确定所述目标环境包括所述集成测试环境；所述修复分支的待发布代码包括源自所述主分支并经过修复的代码。

可选的，所述开发主分支产生于所述主分支，所述功能分支产生于所述开发主分支，所述测试分支产生于所述功能分支。

可选的，所述的代码开发的处理方法，还包括：以各代码集合为服务，构建各服务的镜像；

对应的，发布于所述目标环境的代码为所述目标代码的镜像。

根据本发明的第二方面，提供了一种代码开发的处理装置，包括：

代码确定模块，用于确定目标代码；

环境确定模块，用于：

发布模块，用于将所述目标代码发布于所述目标环境；

更新模块，用于：若有新版本的代码发布于所述真实生产环境，则将所述新版本的代码更新于所述主分支。

根据本发明的第三方面，提供了一种电子设备，包括处理器与存储器，

所述存储器，用于存储代码；

所述处理器，用于执行所述存储器中的代码用以实现第一方面及其可选方案涉及的处理方法。

根据本发明的第四方面，提供了一种存储介质，其上存储有计算机程序，该程序被处理器执行时实现第一方面及其可选方案涉及的处理方法。

本发明提供的代码开发的处理方法、装置、电子设备与存储介质中，采用主分支、发布分支、主开发分支、功能分支、测试分支等多样的分支，还采用了开发环境、单元测试环境、集成测试环境、预生产环境与生产环境这些多样的环境，丰富了代码管理的分支与分布的环境，基于此而构建的代码管理流程可满足多样的代码开发需求，也有助于对代码进行细致的规范化管理。

同时，基于本发明所形成的代码管理规则，主开发分支、功能开发分支、发布分支等实现了代码的区别化，避免或降低了同一份代码存在于很多分支的可能性，便于实现分支和环境的规范、清晰与纯净，此外，由于多个团队之间的代码开发也会有功能依赖，进而，本发明通过测试分支、单元测试环境的设计，以及集成测试环境的设计，可有助于实现相依赖功能之间的联调、联合测试，满足需求。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动性的前提下，还可以根据这些附图获得其他的附图。

图1是本发明一实施例中代码开发的处理方法的流程示意图一；

图2是本发明一实施例中代码开发的处理方法的流程示意图二；

图3是本发明一实施例中代码开发的处理方法的流程示意图三；

图4是本发明一实施例中代码开发的处理方法的流程示意图四；

图5是本发明一实施例中分支流转示意图；

图6是本发明一实施例中代码开发的处理方法的流程示意图五；

图7是本发明一实施例中的系统框图；

图8是本发明一实施例中的架构图；

图9是本发明一实施例中构建镜像的流程示意图；

图10是本发明一实施例中部署服务的流程示意图；

图11是本发明一实施例中代码开发的处理装置的程序模块示意图一；

图12是本发明一实施例中代码开发的处理装置的程序模块示意图二；

图13是本发明一实施例中电子设备的构造示意图。

具体实施方式

下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”、“第三”“第四”等(如果存在)是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例能够以除了在这里图示或描述的那些以外的顺序实施。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。

下面以具体地实施例对本发明的技术方案进行详细说明。下面这几个具体的实施例可以相互结合，对于相同或相似的概念或过程可能在某些实施例不再赘述。

请参考图1，本发明实施例的方案中，采用了主分支(即master分支)、发布分支(即release分支)、测试分支(test分支)、开发主分支(dev/devlop分支)、功能开发分支(feature分支)。

进一步的举例中，还可采用修复分支(即hotfix分支)、性能分支(perf分支)等。

针对于此的说明可例如下表所示：

基于以上分支，请参考图1并结合图5，其中步骤S102、S104、S106的判断顺序可以任意变化而不限于图1所示，图1仅为一种示例性的方案，本发明实施例提供了一种代码开发的处理方法，包括：

S101：确定目标代码；

S102：所述目标代码是否为测试分支的待发布代码；

若是，则可实施步骤S103：确定目标环境为单元测试环境；

所述测试分支的待发布代码源自功能开发分支；该测试分支可产生于功能开发分支，即：所述方法可以包括：基于功能开发分支，产生测试分支，所产生的测试分支中的代码可以是自功能开发分支而来的(例如合并对应功能开发分支的代码而形成)；

S104：所述目标代码是否为主开发分支的待发布代码；

若是，则可实施步骤S105：确定目标环境为开发环境；

其中，所述开发主分支的至少部分待发布代码源自所述功能开发分支；该开发主分支可产生于主分支，即：所述方法可以包括：基于主分支，产生开发主分支，所产生的开发主分支的部分代码可以是开发形成的，也可以是自主分支获取到的；

S106：所述目标代码是否为发布分支的待发布代码；

若是，则可实施步骤S107：确定目标环境包括集成测试环境、预生产环境与真实生产环境；

所述发布分支的代码源自所述主开发分支，发布分支也可产生于主开发分支；

S108：将所述目标代码发布于所述目标环境；

S109：若有新版本的代码发布于所述真实生产环境，则将所述新版本的代码更新于所述主分支。

其中的各环境可理解为：

单元测试环境，即用于对开发多组功能所形成的代码的组合进行测试的环境。

开发环境，即用于对开发单组功能所形成的代码进行测试的环境；

集成测试环境，即对开发各组功能所形成的所有代码的组合进行集成测试的环境；

预生产环境，即在进入真实生产环境前完成最后一次测试的环境；

真实生产环境，即真实发布从而被用户感知的环境，可参照本领域任意已有或改进的生产环境、真实生产环境理解。

各分支的作用可例如下图所示：

主分支(master分支)，可理解为用于备份代码，其为一个被保护的分支，不可以人为修改。每次版本发布到生产环境以后自动将生产环境的最新代码git merge合并到master分支。下一次再开发时其他所有分支都是从master分支拉出来的；

主开发分支(即dev/devlop分支)，用于多个开发进行集成联调，只能发布到开发环境dev；其可从master分支产生，开发调试完成后，合并进release分支；

功能开发分支(即features分支)，可以是由开发人员创建做自己负责部分的一组功能的分支，其可从dev/develop分支产生，功能完成后，合并进develop分支；

测试分支(即test分支)，可以是测试团队用于单元测试和第三方联调环境的分支，只能发布到单元测试环境test，其可从features分支产生；

发布分支(即release分支)，可以从develop分支产生，其可发布到集成测试环境、预生产环境与真实生产环境依次进行测试。

可见，所述开发主分支产生于所述主分支，所述功能分支产生于所述开发主分支，所述测试分支产生于所述功能分支。

具体而言，以图2为例，步骤S107之后执行的步骤S108可以包括：

S1081：获取到手动触发指令；

S1082：将所述目标代码发布于所述集成测试环境；

S1083：所述目标代码是否在所述集成测试环境被验证通过；

若是，则可实施步骤S1084：将所述目标代码发布于所述预生产环境；

S1085：所述目标代码是否在所述预生产环境被验证通过；

若是，则可实施步骤S1086：将所述目标代码发布于所述真实生产环境。

可见，从release分支打出来的代码包要依次顺序发到3个环境，首先发到集成测试环境(sit)进行多个团队的联合代码验证，验证通过后再发到预生产环境(pre)进行上线前最后一次测试，验证通过后发布到真实生产环境(prod/prd)，发完之后最新的代码合并到master分支。

以上方案中，采用主分支、发布分支、主开发分支、功能分支、测试分支等多样的分支，还采用了开发环境、单元测试环境、集成测试环境、预生产环境与生产环境这些多样的环境，丰富了代码管理的分支与分布的环境，基于此而构建的代码管理流程可满足多样的代码开发需求，也有助于对代码进行细致的规范化管理。

其中一种实施方式中，参照于图5可见，在步骤S108中：

可见，在需要发布到集成测试环境、单元测试环境时(例如将test分支的待发布代码发布到单元测试环境，将release分支、hotfix分支的待发布代码发布到集成测试环境等)，可以引入手动触发，与之不同的是，在发布到开发环境时，可以实现自动触发。

其中一种实施方式中，请参考图4，所述方法，还可以包括：

S109：所述目标代码是否为修复分支的待发布代码；

若是，则可确定所述目标环境包括所述集成测试环境，例如可进入步骤S107；所述修复分支的待发布代码包括源自所述主分支并经过修复的代码。

可见：

修复分支(即hotfix分支)，用于紧急修复生产环境问题，从master分支产生，修复上线(即修复、测试后发布至生产环境)后，可合并进master分支。

其中一种实施方式中，请参考图6，所述的代码开发的处理方法，还包括：

S110：以各代码集合为服务，构建各服务的镜像；

其中的镜像，即容器镜像(image)，其可理解为是一个随时可以运行的软件包，包含运行应用程序所需的一切：代码和它需要的所有运行时、应用程序和系统库，以及一些基本设置的默认值。

后文中将对服务的镜像构建过程，服务部署发布过程进行详细描述。其可适于在例如图7所示的系统中实现，通过图8所示的架构实现，镜像构建的过程可例如图9所示，服务部署发布的过程可例如图10所示。

为便于理解后文相关描述，以下对部分术语进行简单说明：

Docker，是一个虚拟环境容器，可以将开发环境、代码、配置文件等一并打包到这个容器中，并发布和应用到任意平台中。

Kubernetes，简称K8s，是一个可移植的，可扩展的开源平台，用于管理容器化的工作负载和服务。

集群cluster是计算、存储和网络资源的集合，k8s利用这些资源运行各种基于容器的应用。

命名空间(namespace)，是一种资源隔离单位，其可以为Kubernetes集群提供虚拟的隔离作用。一个命名空间中的计算、存储、网络等资源与其他命名空间独立。

工作负载，是在Kubernetes上运行的应用程序。

Pod，是可以在Kubernetes中创建和管理的、最小的可部署的计算单元。

服务，可以简单理解为一个微服务，实现某些业务功能的代码集合。

Jenkins，是一个开源软件项目，其可以是基于Java开发的一种持续集成工具，用于监控持续重复的工作，旨在提供一个开放易用的软件平台，使软件项目可以进行持续集成。

Rancher，是采用容器的团队提供了完整的软件堆栈，解决了跨任何基础设施架构管理多个Kubernetes集群的运维和安全挑战，同时为DevOps团队提供了用于运行容器化工作负载的集成工具。

CI的全称是Continuous Integration，表示持续集成。

在CI环境中，开发人员将会频繁地向主干提交代码。这些新提交的代码在最终合并到主干前，需要经过编译和自动化测试流进行验证，然后变成可以进行发布的构建产物。

CD，全称是：Continuous delivery，缩写也是CD，它是一种软件工程手法，表示持续交付；其可以让软件产品的产出过程在一个短周期内完成，以保证软件可以稳定、持续的保持在随时可以释出的状况。它的目标在于让软件的建置、测试与释出变得更快以及更频繁。这种方式可以减少软件开发的成本与时间，减少风险。

Gitlab，是目前世界上最先进的分布式版本控制系统，用来管理开发代码和分支。

JIRA，是Atlassian公司出品的项目与事务跟踪工具，被广泛应用于缺陷跟踪、客户服务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域。

Harbor，是一个镜像仓库，用于存放Docker镜像。

SonarQube，是一个用于代码质量管理的开源平台，用于管理源代码的质量。

请参考图9，构建镜像的过程中，可以对服务进行打包镜像，镜像(Image)是一个随时可以运行的软件包，包含运行应用程序所需的一切：代码和它需要的所有运行时、应用程序和系统库，以及一些基本设置的默认值。

具体地，步骤S110的过程可以包括：

S1101：在页面上显示服务的远程代码分支；

具体的，运维发布平台可保存了每个服务的git地址，首先根据服务git地址，获取服务的远程代码分支并在发布平台页面上进行展示；

S1102：根据用户所选择的分支形成标签(即tag)；

具体的，步骤S1102可以包括：

S11021：用户可以在页面上选择要用哪个分支的代码进行打包镜像，根据用户所选发布分支，区分实施以下过程；

S11022：如果用户所选则的分支为release/hotfix分支，则tag必须在前端页面选择用户在Gitlab中手动创建的tag；

S11023：如果用户所选则的分支非S11022中所述分支，则tag由发布系统自动生成，其值为tag＝分支名称+时间戳(例：dev-20210628152056)。

步骤S1102之后，可以实施：

S1103：在数据库构建镜像表中增加一条构建数据，状态为构建中；

S1104：拼装调用Jenkins构建镜像Job所需的参数；

其中的参数包括(但不限于)：name(服务名称)，branch(分支)，tag(标签名称)，build_method(构建方法)，git_url(git地址)，type(服务类型：java、python、golang、php、nodej s等)，url(构建镜像Job完成后回调发布系统的地址)；

S1105：调用Jenkins构建镜像Job；

步骤S1105具体过程可例如包括：

步骤S11051：根据branch和git_url拉取源代码；

步骤S11052：判断服务属于哪类服务类型，根据服务类型选择不同打包命令；

步骤S11052例如可包括：

S110521：如果是Java服务：则选择：

mvn-U clean package-Dmaven.test.skip＝true；

S110522：如果是NodeJs服务，则选择：

1.npm install&&npm run build；

2.yarn&&yarn run build；

S110523：如果是Python服务：则选择：echo'Starting Build Python.'；

S110524：如果是Golang服务：则选择：echo'Starting Build Golang.'；

S110525：如果是PHP服务：则选择：echo'Starting Build PHP.'。

步骤S11052之后，可以包括：

S11053：如果是Java项目并且branch为dev异步调用Sonarqube代码检查Job；

步骤S11053例如可以包括：

S110531：检测完成后回调发布平台(参数中的url)；

S110532：发布平台根据检测结果更新数据库中构建记录的代码检测结果。

S110533：根据打包结果构建镜像；

步骤S110533具体可以包括：

S1105331：构建镜像，其可例如：

#dockerfile:dockerfile文件所在位置

#harbor_url:harbor镜像仓库地址

#center:服务所在中心

#env:所选择的环境

#name:服务名称

#tag:标签

docker build-f Dockerfiles/${dockerfile}-t${harbor_url}/${center}/${env}/${name}:${tag}

S1105332：将构建完成的镜像推送至Habor镜像仓库，其可例如：

#harbor_url:harbor镜像仓库地址

#center:服务所在中心

#env:所选择的环境

#name:服务名称

#tag:标签

docker push${harbor_url}/${center}/${env}/${name}:${tag}

S1105333：删除本地镜像，其可例如：

Shell

#harbor_url:harbor镜像仓库地址

#center:服务所在中心

#env:所选择的环境

#name:服务名称

#tag:标签

docker rmi${harbor_url}/${args.center}/${args.env}/${args.name}:${args.tag}

S1105334：通过发布平台回调地址通知发布平台构建镜像结果；

若成功，则将镜像地址及结果更新到数据库镜像表中

若失败，则更新构建镜像结果

最终，构建镜像完成。

请参考图10，服务部署发布的过程中，可以将图9所示的构建过程构建的镜像发布到线上k8s集群，完成服务的部署，部署后用户可以在线上访问到已发布的服务。

部署发布的过程可例如包括：

S1201：确定要发布的服务、环境与镜像；

该过程可理解为步骤S101确定目标代码的过程，以及步骤S102至S107、S107等确定目标环境的过程的一种可选方案。

进而，在步骤S1201中，用户可主动选择要发布的服务、环境、镜像进行申请发布；选择环境时，可以是限制可供选择的环境或自动选择对应的环境：

以步骤S102与步骤S103为例，在用户选择测试分支的目标代码(服务和/或其镜像)的情况下，可将环境自动选择为单元测试环境(或限制为只能选择单元测试环境)；

以步骤S104与步骤S105为例，在用户选择主开发分支的目标代码(服务和/或其镜像)的情况下，可将环境自动选择为开发环境(或限制为只能选择开发环境)；

以步骤S106与步骤S107为例，在用户选择发布分支的目标代码(服务和/或其镜像)的情况下，可将环境自动选择为集成测试环境(或限制为只能选择集成测试环境)；此外，因为预生产环境、真实生产环境为集成测试环境之后所需依次测试的环境，所以，选择集成测试环境，亦即选择了集成测试环境、预生产环境、真实生产环境。

以步骤S109为例，在用户选择修复分支的目标代码(服务和/或其镜像)的情况下，可将环境自动选择为集成测试环境(或限制为只能选择集成测试环境)；此外，因为预生产环境、真实生产环境为集成测试环境之后所需依次测试的环境，所以，选择集成测试环境，亦即选择了集成测试环境、预生产环境、真实生产环境。

步骤S1201的过程中，如果是pre/prd环境则工单号必须填写；校验工单号；

进一步的，如果用户填入工单号为关闭、完成状态、者不存在或非待发布状态，则提示用户核实后在提交；如果当前工单号的状态为待发布状态则允许提交发布申请。

S1201之后可以包括：

S1202：参数校验；

具体的，步骤S1202可以包括：

S12021：当前环境K8s集群是否存在；

S12022：所选服务是否存在；

S12023：所选则服务是否绑定能力中心；

S12024：所选择的镜像是否存在；

S12025：当前服务是否绑定名称空间；

S12026：判断服务所绑定空间在K8s集群中是否存在；

S12027：校验当前环境下当前服务是否配置部署参数；

S12028：校验表单参数；校验的内容包括：镜像ID不能为空；集群ID不能为空；命名空间不能为空。

步骤S1202之后可以包括：

S1203：根据参数及helm模板生成yaml；

具体方案中，步骤S1203可以包括：

S12031：根据参数生成模板名称及deployment(工作负载)名称；

如果是当前发布申请为灰度发布则deployment名称后增加-gray后缀；

S12032：判断当前服务类型，并基于服务类型生成模板；

步骤S12032可以包括：

S120321：如果是Java服务，则实施以下步骤：

更新Skywaking版本；

如果是接入istio的服务，则：生成istio的模板，具体包括：拼装模板参数，以及：执行命令生成模板；

如果不是接入istio的服务，则：拼装模板参数，并执行命令生成模板；

步骤S12032还可以包括：

S120322：如果非java服务，则实施以下步骤：拼装模板参数，并执行命令生成模板；

具体的实现方式可例如：

#template_service_name模板名称

#temp_deploy_date当前时间戳

#_type服务类型

helm template

{template_service_name}./temp_helm_chart/helm-chart-{temp_deploy_date}/{_type}

步骤S1203之后，可以包括：

S1204：供用户预览部署模板，查看模板中参数是否正确；

S1205：部署；

步骤S1205的过程例如可以包括：

S12051：部署服务

步骤S12051具体包括：

S120511：判断服务是否为有状态服务

S120512：如果是Deployment(无状态服务)，通过第三方库调用K8s的API；具体的实现方式可例如：

#name工作负载名称

#namespace命名空间

/apis/apps/v1/namespaces/{namespace}/deployments/{name}

S120513：如果是StatefulSet(有状态服务)，通过第三方库调用K8s的API；具体的实现方式可例如：

#name工作负载名称

#namespace命名空间

/apis/apps/v1/namespaces/{namespace}/statefulsets/{name}

步骤S12051之后可以包括：

S12052：部署状态确认；

S12053：如果部署失败，更新部署记录为失败状态，同时飞书机器人通知相关负责人发布失败；

S12053：如果部署成功，则可实施：

S120531：下线老的服务；

S120532：更新数据库中模板的数据

S120533：飞书机器人通知相关负责人发布成功；

S120534：如果发布环境为生产环境，并且分支为release或hotfix，合并分支；具体可以包括：

通过第三方库调用Gitlab的API，根据tag创建临时分支，临时分支＝'merge_'+tag；

调用Gitlab的API将临时分支合并至master分支；

调用Gitlab的API删除临时分支；

飞书通知相关负责人，代码合并结果。

最终，可部署完成。

综上可见，在以上方案中，发布系统打通代码管理、测试系统、K8s管理、飞书通知等多种工具，所有操作和信息以可视化的形式提供给用户，使整个发布过程简单化和完整化。

并且，发布系统预先自定义了多种技术栈的发布模板，每次发布时只要通过helm就可以生成k8s发布服务所需的yaml格式的资源清单，此操作标准了各种技术栈的服务发布管理。

请参考图11，代码开发的处理装置2，包括：

代码确定模块201，用于确定目标代码；

环境确定模块202，用于：

发布模块203，用于将所述目标代码发布于所述目标环境；

更新模块204，用于：若有新版本的代码发布于所述真实生产环境，则将所述新版本的代码更新于所述主分支。

所述发布模块203，具体用于：

将所述目标代码发布于所述集成测试环境；

可选的，所述发布模块203，具体用于：

若所述目标环境包括所述集成测试环境，则在获取到手动触发指令后，将所述目标代码发布于所述集成测试环境；

若所述目标环境包括所述单元测试环境，则在获取到手动触发指令后，将所述目标代码发布于所述单元测试环境。

所述环境确定模块202，还用于：

可选的，请参考图12，代码开发的处理装置2，还包括：

构建模块205，用于以各代码集合为服务，构建各服务的镜像；

请参考图13，提供了一种电子设备30，包括：

处理器31；以及，

存储器32，用于存储所述处理器的可执行指令；

其中，所述处理器31配置为经由执行所述可执行指令来执行以上所涉及的方法。

处理器31能够通过总线33与存储器32通讯。

本发明实施例还提供了一种计算机可读存储介质，其上存储有计算机程序，该程序被处理器执行时实现以上所涉及的方法。

本领域普通技术人员可以理解：实现上述各方法实施例的全部或部分步骤可以通过程序指令相关的硬件来完成。前述的程序可以存储于一计算机可读取存储介质中。该程序在执行时，执行包括上述各方法实施例的步骤；而前述的存储介质包括：ROM、RAM、磁碟或者光盘等各种可以存储程序代码的介质。

最后应说明的是：以上各实施例仅用以说明本发明的技术方案，而非对其限制；尽管参照前述各实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分或者全部技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本发明各实施例技术方案的范围。

Claims

1.一种代码开发的处理方法，其特征在于，包括：

确定目标代码；

将所述目标代码发布于所述目标环境；

2.根据权利要求1所述的代码开发的处理方法，其特征在于，

若所述目标代码为所述发布分支的待发布代码，则：

所述将所述目标代码发布于所述目标环境，包括：

将所述目标代码发布于所述集成测试环境；

3.根据权利要求2所述的代码开发的处理方法，其特征在于，所述将所述目标代码发布于所述真实生产环境之前，还包括：获取到手动触发指令。

4.根据权利要求1所述的代码开发的处理方法，其特征在于，

所述将所述目标代码的镜像发布于所述目标环境，包括：

5.根据权利要求1所述的代码开发的处理方法，其特征在于，还包括：

6.根据权利要求1至5任一项所述的代码开发的处理方法，其特征在于，所述开发主分支产生于所述主分支，所述功能分支产生于所述开发主分支，所述测试分支产生于所述功能分支。

7.根据权利要求1至5任一项所述的代码开发的处理方法，其特征在于，还包括：以各代码集合为服务，构建各服务的镜像；

8.一种代码开发的处理装置，其特征在于，包括：

代码确定模块，用于确定目标代码；

环境确定模块，用于：

发布模块，用于将所述目标代码发布于所述目标环境；

9.一种电子设备，其特征在于，包括处理器与存储器，

所述存储器，用于存储代码；

所述处理器，用于执行所述存储器中的代码用以实现权利要求1至7任一项所述的处理方法。

10.一种存储介质，其上存储有计算机程序，该程序被处理器执行时实现权利要求1至7任一项所述的处理方法。