众所周知，IDEA 自带的热加载只支持方法内的热加载，而使用 HotSwapAgent 不仅支持方法内的热加载，并且可实现新增方法的热加载，甚至是新增类的热加载，可谓是提高开发效率的神器
本文主要介绍在 IDEA 下使用 HotSwapAgent 来进行 SpringBoot 下的热部署；
接下来我们开始配置 HotSwapAgent

1 安装 DCEVM

DCEVM 是个JDK的插件，提供类似 JRebel 的热加载功能，能够在运行时重新定义加载的类，实现“热加载、热插拔、热部署”，而 HotSwapAgent 插件则是实现了 Servlet 程序的热加载功能，并且 DCEVM + HotSwapAgent 开源免费，更适合广大开发者使用。
安装 DCEVM 需要和 JDK 版本相对应，你需要先确定自己的 JDK 版本是否是 DCEVM 所支持的版本
https://github.com/dcevm/dcevm/releases
写此文时，DCEVM 支持的最新 JDK 版本是Java 8u181
如果你的JDK版本不被支持，则需要去 Oracle Java Archive 这个页面下载对应版本 JDK 并安装
https://www.oracle.com/java/technologies/javase/javase8-archive-downloads.html
下载 JDK 需要自备 Oracle 的账号
下载并安装好对应版本 JDK 后，我们再次来确定 JDK 版本为对应版本

- 阅读剩余部分 -

最近拖延症犯了，一个文章标题写了一个月才写了个标题...

前言

自从入坑Drone CI/DI以来，我极力推荐在小微项目上使用Drone来完成自动构建，主要是轻量化，安装配置方便 ,
只需写一个docker compose文件即可完成Drone的安装配置，
只需写一个.drone.yml即可完成接入，极为方便；

Drone更深一层探究

经过我的不懈努力，经主管同意，最终也在公司项目上使用上了Drone来逐步替代Jenkins进行小项目微服务的自动构建部署 ；

但是实际使用中发现一个问题，即SpringBoot工程，通常是一个主工程下包含多个微服务子工程，使用drone不太好控制其中某一个工程的自动构建部署，总不能每次都重新构建整个服务，然后重启所有工程吧，这样效率也太低了 ；

//多工程目录结构，本文主要演示SpringBoot多工程项目自动构建部署
demoParant
├── common   //公共工程
├── api      //API工程
├── user     //用户工程
└── back     //后台工程

能想到的最简单实现的方式就是来通过不同的分支来触发不同的构建任务，这样理论上可行，但是实际操作会产生一堆分支，显得极为不整洁，并且正常开发也是开发一个分支，测试一个分支，生产一个分支，太多了操作起来也不方便 ；

所以最理想的方式也就是在同一个分支下，通过某种方式来触发不同的构建任务；

Drone的启发

在Drone CI下有一个默认功能，即在Commit log中输入[CI SKIP]即可跳过本次自动构建，于是我就想能否通过Commit log来控制本次部署具体哪个子工程，这样下来我只要在输入commit log的时候输入需要构建的工程，即可完成对应工程的自动构建部署，并且不影响同项目下的其他工程；

初步设想的原理就是在drone执行部署命令时，通过自定义脚本完成工程部署，并将commit log作为参数传入脚本，在脚本中判断commit log中是否指定某些工程的运行的参数，如果不指定则默认运行所有工程 ；

例如：我提交commit日志update Admin.java; add admin management interface; [CI API] [CI BACK];
这样一来，经过drone自动构建后，只重新部署了API工程和后台工程；

具体实现

具体实现可参考如下脚本：

- 阅读剩余部分 -

Dcoker是一个开源的应用容器引擎，介绍我就不介绍了，总之就是很牛批，用过的都相见恨晚
平时我们不是应用都是先搭建相关环境，然后把应用启动一通配置好
本地环境需要搭建一次，测试环境需要搭建一次，生产环境也需要搭建一次，这样重复的工作就做了几次，效率降低
使用了docker了？我们只需要构建一次镜像，然后不同的环境只需要把镜像拉下来启动就行了，是不是很简单？
如果配合CI/DI持续集成，持续部署，那就太爽歪歪了，我们只需要把代码提交到git，剩下打包/编译/测试/部署工作就全自动自己运行了，是不是大大提高了生产力？
废话不多说，今天先研究docker怎么构建SpringBoot，改天再研究CI/DI~

1 安装Docker

首先docker只支持CentOS7以上的系统，如果系统版本过低请升级系统
这里我使用的是CentOS7 x64
docker安装教程详见：Docker的基本操作与使用

2 准备SpringBoot应用

- 阅读剩余部分 -

因为线上部署的时候和本地往往使用不同的配置文件，所以研究了下SpringBoot配置文件存放位置及读取顺序
之前是直接手动指定配置文件启动来启动SpringBoot工程的，后来发现直接按照配置文件的加载顺序优先级放到对应的文件夹下即可进行配置文件的自动覆盖和互补

以下内容转载自：https://my.oschina.net/sdlvzg/blog/1612703

SpringBoot配置文件可以使用yml格式和properties格式

分别的默认命名为：application.yml、application.properties

存放目录

SpringBoot配置文件默认可以放到以下目录中，可以自动读取到：

• 项目根目录下
• 项目根目录中 config 目录下
• 项目的 resources 目录下
• 项目 resources 目录中 config 目录下

读取顺序

如果在不同的目录中存在多个配置文件，它的读取顺序是：

1、config/application.properties（项目根目录中config目录下）
2、config/application.yml
3、application.properties（项目根目录下）
4、application.yml
5、resources/config/application.properties（项目resources目录中config目录下）
6、resources/config/application.yml
7、resources/application.properties（项目的resources目录下）
8、resources/application.yml

注：
1、如果同一个目录下，有application.yml也有application.properties，默认先读取application.properties。
2、如果同一个配置属性，在多个配置文件都配置了，默认使用第1个读取到的，后面读取的不覆盖前面读取到的。
3、创建SpringBoot项目时，一般的配置文件放置在“项目的resources目录下”