SpringCloud微服务包含多个SpringBoot可运行的应用程序，在单应用程序下，版本发布时的打包部署还相对简单，当有多个应用程序的微服务发布部署时，原先的单应用程序部署方式就会显得复杂且不可控。那么我们就会思考使用简单的部署方式，解决自动化发布、自动化部署、微服务监控等问题。
我们使用目前行业通用的解决方案，Jenkins+GitLab+Maven+Docker+Kubernetes来实现可持续自动化部署微服务的功能。下面将从工程中Maven打包文件配置、Dockfile文件编写开始到Kubernetes配置来说明如何实现SpringCloud微服务可持续自动化部署功能。
在项目打包部署时，我们系统的配置文件需要根据不同的环境来区分开发、测试、生产环境的配置，在之前的SpringBoot工程中，我们用到spring.profiles.active配置属性，使用application.yml、application-dev.yml、application-test.yml、application-sit.yml、application-uat.yml、application-prod.yml来区分不同环境的配置文件。在SpringCloud中，我们用到了Nacos注册中心，Nacos的Config默认读取的是bootstrap.yml配置文件，如果将Nacos Config的配置写到application.yml里面，工程启动时就会一直报错。下面是SpringCloud加载配置文件的顺序：
- bootstrap.yml（bootstrap.properties）先加载，用于应用程序上下文的引导阶段，可以用来配置application.yml中使用到的参数，由父Spring ApplicationContext加载。
- application.yml（application.properties）后加载，用于配置各工程模块中使-用到的参数。
所以在SpringCloud工程中我们通过使用bootstrap.yml、bootstrap-dev.yml...等不同的配置文件来区分不同的环境，有些框架是放到同一个yml配置文件中，然后不同的配置放到不同的spring.profiles.active下面，类似于下面这种:
spring:
profiles: dev
开发配置项: 开发配置项
spring:
profiles: test
测试配置项: 测试配置项
但是，在实际开发过程中，我们开发、测试的配置文件有时会经常修改，而生产部署环境确很少改动，当多人员开发时，难免会有部分人员不小心将配置文件改动影响到生产环境配置，即使没有影响，开发人员在改动时也要小心翼翼，害怕哪里改错。当我们将这些配置分开时，开发、测试的配置文件无论如何改动，都不会影响到生产环境文件，这正是我们想要的结果。所以我们将不同环境的配置放到不同的配置文件中。我们将配置文件分为bootstrap.yml、bootstrap-dev.yml、bootstrap-test.yml、bootstrap-prod.yml