Docker在Jenkins Slave上动态构建了Jenkins Slave的春季项目，以动态构建Spring Project。但是，在实际的CI/CD应用程序中，操作和维护可能是以下问题：
1.环境验证
Springboot项目的多个GIT分支对应于不同的环境。例如：开发分支对应于测试环境，主分支对应于生产环境。在操作和维护部署过程中有轻微的疏忽，这可能会导致使用误解环境配置并将不必要的问题引入测试和生产。因此，我们将增加环境验证以确保不同的分支使用正确的环境配置文件。
2.播放/滚动/重新启动
在发布过程中，我们不仅应该考虑版本的正常版本，而且还应该考虑版本的回滚，以防止新版本能够及时返回历史版本。OOM问题可能会导致Java的过程，过程死亡，因此我们最好需要重新启动功能来促进及时重新启动。在“谁开发和运行”的概念中，我们的CI/CD考虑了上述三个函数。
3.操作验证
发行/回滚将涉及应用程序的应用。为了避免重复构造，我们需要验证GIT分支版本的Git分支版本的版本，以防止版本/回滚过程中重复更新引起的应用程序重新启动。
Jenkins不使用多个分支组装线，因此不同的GIT分支对应于不同的任务。开发分支对应于Docker-Test-XXXX。
在服务器上执行的Docker操作是不同的。例如，版本/回滚涉及镜像和容器的停止删除，并且重新启动操作不需要。
为了确保正确的操作和维护操作，我们开发了Docker项目部署的规范：
1. job_name命名规范
格式规范：Docker-Environment-Project名称
生产：Docker-prod-XXXX
测试：Docker-Test-XXXX
2.全局变量
app_name项目名称
image_name镜像名称，格式：业务/系统
Monitor_url监视器URL
3.环境验证
通过Job_name提取产品/测试关键字，并匹配GIT分支的主/开发以执行环境验证。
4.操作验证
版本：当Git具有新版本时，将执行邮政操作；
向后回滚：向后滚动到任何版本
重新启动：重新启动容器
5. Docker相关规格
（1）镜像命名规范，格式：业务/系统
例如：helloworld/helloworld
（2）集装箱命名规格，格式：系统名称，例如Helloworld
（3）标签规范，格式：consith，例如7E2C56522188C98F6294D91C8568DFCEDF994E42
（1）整个工作周期存在全局变量。我们只需要根据项目的实际情况设置变量即可。其他内容无需更改。
（2）构建名称是一个内置的名称。它由jenkins构建的-in bualtial_number和git_commit组成，以帮助我们确定任务的哪个版本是研究问题。
构建过程主要执行环境验证和操作验证操作
（1）环境验证，确定GIT分支是否与当前的工作测试/产品一致，并停止操作的后续版本；
（2）操作验证
版本：是否已更新GIT的相应分支以防止未更新时多次，从而导致多次重新启动；
主要使用jenkins构建的变量：
git_previous_successful_commit上次成功git版本编号
git_commit当前构建任务git版本编号
回滚：确定远程分支是否具有与参数匹配的版本号，如果没有合法，则是非法的，并且回滚被停止；
代码显示如下：
登录到远程服务器，通过“ SSH Publishers”插件执行与Docker相关的操作。
在：
删除詹金斯从服务器上新构建的镜像和虚拟悬架图像，以使从属上的环境保持纯净。
以上是我对Docker+Jenkins在连续集成/交付过程中的一些理解。通过对Docker的持续探索实践，我希望继续优化该解决方案。我认为远程服务器最终登录的操作过程仍然太麻烦了。在发布/回滚过程中，您需要停止，删除容器并删除镜像。因此，将对Docker-Compose进行优化，以带来更简洁的配置管理。
此外，以上是通过SSH登录的Docker单机器部署，但是Docker的服务器 - 客户仪架构应具有更方便的方式，例如Shep和K8s。这些需要在将来不断学习和总结。