项目开发管理之开发、测试到上线

一.项目运行环境

前后端分离。 前端：react、angular等。包括各个不同业务的前端系统

后端：java, jdk-17.0.9版本. 使用spring cloud 微服务架构，其中包含：前端支持系统、客户管理系统、订单管理系统、合同系统、客户关系系统、数据查询中台、消息同步系统、邮件发送系统、政策管理系统等

系统使用Jenkins进行部署，系统之间通过http协议进行访问，数据库采用sql server和oracle。

二.项目的开发过程

1.代码分支管理

代码分支主要分为mater分支、feature类分支、bau类分支、project类分支、develop类分支、release类分支。

master可以理解为上一个版本release的最终代码；

feature类用于developer在提交自己开发的需求；

bau类分支用于系统升级、bug修复等需求。bau分支是新版本开始时从master拉的；

project类分支用于管理新需求的版本。project分支是新版本开始时从master拉的；

develop类用于管理环境；

release类分支这里面放的是经过ci和release后，并且各方检查都通过、真正有效的代码

1.1.开发分支：feature

所有的开发都是在feature下面，这些分支都是从master拉过来的。保证是上一个release的版本。

比如要加客户查询功能，从master拉feature/xxxx-???????分支，xxxx代表需求标记，???????表示开发说明,如feature/CP-123456-add-cusomer-delete-func

1.1.1.bau

如果是针对系统维护、代码bug修复、优化或者提升性能方面的需求。就需要讲开发好的feature/xxxx-???????分支的代码，提交到要上线的bau分支。如：bau/2024_Nov_11_Bau

这个过程因为要合并代码，所有需要提交pr(pull request)。负责review代码、approval和merge代码的必须是小组长或者项目经理。不能是自己想合就合的

1.1.2.project

和bau的流程一样，只是这个要合到对应的project分支上，如: project/2024_Oct_18_Customer_query。也需要制定的人来合pr

1.1.3.conflict如何解决？

一般情况是不会有冲突的发生，因为不同的需求通过不同的分支进行。但是有时候不同需求需要使用同一功能，或者设计公共部分的修改。

这个时候，先修改的后提交，则会产生代码的冲突。如何解决冲突？

基于目标分支，统一拉一个feature分支，然后再将要合入的原分支merge到该feature分支，最后由feature分支合到目标分支。

比如bau/2024_Nov_11_Bau合develop/env-1有冲突。首先基于develop/env-1拉分支：feature/CP-123456-resolve-conflict-from-bau-to-env-1,然后将bau/2024_Nov_11_Bau的代码拉到该feature分支，并解决冲突后提交新代码。最后从feature/CP-123456-resolve-conflict-from-bau-to-env-1提pr，将代码合到develop/env-1。这样后面bau/2024_Nov_11_Bau合develop/env-1就不会有冲突了。

1.2.环境分支：develop

主要是用于多环境。有的公司不单单有dev、sit、uat，还存在dev-1、dev-2、sit-1、sit-2、uat-1、uat-2等环境。就有对应的develop/env-1，develop/env-2.

当然，处开env分支，要上线的prod分支也在这里：develop/prod

1.2.1.合环境分支的方法

如果project分支要部署到2环境，则需要从project/2024_Oct_18_Customer_query提pr到develop/env-2

如果bau分支要部署到1环境，则需要从bau/2024_Nov_11_Bau提pr到develop/env-1

1.2.2.上线前合代码到prod分支

如果project分支要上线，则需要从project/2024_Oct_18_Customer_query提pr到develop/prod

如果bau分支要上线，则需要从bau/2024_Nov_11_Bau提pr到develop/prod

1.2.3.develop上的代码如何到release分支？

需要经过ci的集成和release的检查。

ci，持续集成（Continuous Integration, CI），不断把新代码集成到要环境的分支，并完成自动化构建、测试，主要是降低代码的集成风险；

release过程可能包括测试、代码检查、打包以及版本管理(如将'1.2.10-SNAPSHOT'版本，变为’1.2.10‘，即开发版本到稳定版本)

release过程还有一个重要的功能，就是将develop/env-1的代码，自动合到release/env-1上

1.2.4.最后代码合到master

上线的过程，是将release/prod的代码，cd到prod环境的过程。

上线完成后，需要将release/prod的代码pr到master，至此完成所有的版本管理

1.3.系统配置参数

在微服务中，系统的配置和代码是分开的。并且由于服务器环境的不同，本地启动和服务器上的启动，配置也可能会有所不同。

通常情况，会单独出来一个配置中心，用来做配置的管理。不同环境的服务根据配置，去不同的分支进行配置获取。

具体分为dev、sit、uat和prod的配置分支，不同分支还会配置环境序号，比如dev-1、dev-2、sit-1、sit-2、uat-1、uat-2等

如何进行分支管理？

比如要修改订单系统的sit-2的配置，首先从sit分支拉feature分支：feature/CP-123456-add-cusomer-delete-func-sit,然后修改sit-2的配置，提pr合到sit分支。其他所有分支都是如此，包括pod

1.4.cicd配置参数

将jvm的启动参数、cicd的运行配置都放在这里。分支管理同配置参数

1.5.sql脚本

使用flyway进行管理。flyway的sql也放到cicd的工程中。这样的好处就是：脚本的修改和代码分开了，并且flyway会对其进行校验和记录

2.接口注册

要对外暴露的接口，需要统一在gateway上面进行注册和管理。gateway的好处有很多，比如服务管理、流量监控、调用链路追踪等。

当然，如果不进行注册暴露的话，该接口一律是不允许访问的。

所有每次的新接口开发完上线，这一步要非常注意。

此外，接口注册可以通过配置Jenkins的job来进行导入，这样管理起来比较方便。而注册和导出的步骤就需要到gateway的特定环境中进行。

3.系统防火墙

在大多数公司中，系统之间访问的防火墙是向devops提申请单，然后通过服务器之间的命令来进行配置。

其实也可以使用network policy的一些策略来完成，devops组可以通过类似配置参考，然后跑Jenkins的方式，将经过approval的防火墙策略直接运行到对应的服务器。

这样就可以更加自动化的部署，并且还可以防止手动操作带来的问题。

4.测试

4.1.自测ut

一些对代码有着更加规范管理的公司，会要求developer完成开发后，对所写的代码进行ut单元的覆盖。

ut通常是通过将bean和特定返回进行mock，然后对指定的逻辑输出进行判断，查看其是否满足预期的结果。

这样做还可以提高代码的检查覆盖率，是的开发的逻辑更加清晰。

4.2.uat环境的测试

专业的测试人员对功能进行测试，有其专门测试的case；

当然也有一些功能是测试无法覆盖的，或者业务并不关系的，这类测试就不需要安排测试人员了。由IT内部进行评估即可

5.代码review与评审

5.1.review的资料

这一步的前提，是developer已经完成了需求的开发，并且pr已经通过小组长进行merge了，也在uat环境上进行部署了。

review的人一般是比小组长更加一级的人员，可以是项目的技术经理，也可能是架构师等。

5.1.1.pr的url

代码方面，主要是从feature合到bau/project分支的pr，里面需要涵盖所有的代码改动，负责review的人会进行所有代码的确认和评估；

配置方面，需要放入配置参数或者sql脚本等修改的pr url。

5.1.2.测试的文档

所有的需求开发完后都需要写测试文档。测试的范围和用例由developer先自行安排，如果review的人觉得有遗漏的地方，则需要进行补充。

此部分相当于要保证所有的功能不受影响，并且开发的需求得到了验证。

5.2.代码评审

上线前，所有的代码都会从bau/project合到project。这个时候就会有这样的pr：涵盖了本次要上线的所有的代码。

代码评审的作用就是要所有相关人员拉到一起，对所有改动的代码进行评审。任何人员都可以提出相应问题，同时所有的代码都要对应的developer确认。

确认无误后，才可以进行merge。

至此，开发的代码正式合到了prod分支

6.sign off

签字

直白一点说，就是测试、ba都签字确认了所有的功能和代码都满足要求了。一旦上线后出现相同的bug，那就是测试人员的测试不足；出现需求不符合预期，则是ba的问题。而这些都与开发人员无关。

更多时候，就是告诉大家：代码已经封版了，不会再修改了。很少遇到扯皮的时候，也不希望有

7.implementation plan

之前我们说了所有的代码和配置都需要合到prod的分支上，但是由于代码的部署需要经过ci和release，才能cd的。所有在发布前，就需要跑完prod分支的代码部分的cd和release。

implementation plan的主要目的就是，让发布的人可以按照这些步骤一步一步的来。尽量保证“任何一个人按照步骤都可以完成发布”。

更加不客气的说，有些公司为了保证发布过程的顺利，在执行implementation plan，会安排非常新手的同事，一次来验证“是否所有的工作都在发不前得到了保证”。我个人觉得这个idea是非常可取的。

因为这样一来就可以更好地推动项目相关人员，在上线就保证准备好了一切。而发布的流程和步骤越简单、越清晰，这样发布的过程就会更加顺利。

三.项目的上线过程

按照implementation plan，“傻瓜式”的操作即可

虽然不要求任何小白都可以按照步骤完成，但是其的作用就是让发布更加简单和高效