DAY01

服务列表

在虚拟机中提供了一些基础服务，具体如下：

可以看到，每个服务都有对应的域名地址访问，需要在本机配置 hosts 映射才能访问。

​​

​

192.168.150.101 git.sl-express.com
192.168.150.101 maven.sl-express.com
192.168.150.101 jenkins.sl-express.com
192.168.150.101 auth.sl-express.com
192.168.150.101 rabbitmq.sl-express.com
192.168.150.101 nacos.sl-express.com
192.168.150.101 neo4j.sl-express.com
192.168.150.101 xxl-job.sl-express.com
192.168.150.101 eaglemap.sl-express.com
192.168.150.101 seata.sl-express.com
192.168.150.101 skywalking.sl-express.com
192.168.150.101 api.sl-express.com
192.168.150.101 admin.sl-express.com

项目代码列表

在虚拟机中的 gogs 服务中已经提供了项目中所涉及都的项目代码，目前项目拥有****19 个微服务，1 个网关，1 个 parent 工程，2 个公共依赖工程。如下：

GitFlow 工作流程

在 gitflow 流程中，master 和 develop 分支属于长期分支，长期分支是相对稳定，所有开发完成或测试通过的提交最终都要合并到这两个分支上，他俩也有一些区别：

• master：发布上线时，基于 master 打 tag，基于 tag 进行发布，不允许在该分支上开发，始终保持该分支的稳定。
• develop：开发阶段使用的分支，提交到该分支代码都是相对稳定的，不能直接基于此分支开发，如果开发新的功能，需要基于此分支创建新的分支进行开发功能，待功能开发、测试通过后合并到 develop 分支。

对于新功能的开发，基于 Develop 分支创建 Feature 分支，功能开发完后合并到 Develop 分支，禁止未开发完成的代码合并到 Develop 分支。

在开发中，新功能的代码已经全部合并到 Develop 分支，此时需要基于 Develop 分支创建 Release 分支，在 Release 分支中不再添加新的功能，只是做 bug 的修复，等测试完成 bug 全部修复之后，需要将 Release 分支合并到 Master 分支和 Develop 分支，并且基于 Master 打出版本的 tag。

如果发布到生成环境的版本出现 bug，比如：生产环境的 v1.0 版本出现 bug 需要尽快修复，此时就需要基于 master 创建 hotfix 分支，并且基于 hotfix 分支修复 bug，待 bug 修复完成后需要将代码合并到 master 和 develop 分支。

​

​

项目代码列表

在虚拟机中的 gogs 服务中已经提供了项目中所涉及都的项目代码，目前项目拥有****19 个微服务，1 个网关，1 个 parent 工程，2 个公共依赖工程。如下：

Jenkins

持续集成

持续集成是指，开发人员将代码合并到远程仓库后，需要【自动】的完成构建、部署等操作。

下面以 Spring Boot web 项目举例，说明使用 Jenkins 进行持续集成的过程。

​​

过程说明：

• 本地开发环境推送代码到远程仓库
• 推送完成后，git 服务会向 Jenkins 发送通知
• Jenkins 接收到通知后，开始触发构建（也可以手动触发构建）
• 【git pull】从 git 仓库中拉取最新的代码
• 【maven package】通过 maven 进行打包，Spring Boot 项目会打成可执行的 jar 包
• 【docker build & push】构建 docker 镜像，一般会将 docker 镜像上传到公司内部私服
• 【ssh remote】通过 ssh 命令登录到远程服务器（部署的目标服务器）
• 【docker pull】通过公司内部私服拉取 docker 镜像
• 【docker run】基于拉取到的镜像，运行容器
• 最后，完成构建

登录业务

登录业务分别在四个终端都有涉及，这里的讲解以【管理端为例】，快递员端和司机端作为练习，由学生来完成。

四端的需求文档地址：