由于团队原来已经有日志收集机制，所以，暂且不需要实现。以上步骤只代表一个优先级。如果团队人力充足，可以同时一起做。
虽说有了计划，但是团队不具备相应的能力，什么计划都白搭。
1. 打包自动化
之所以使用“打包”这个听起来不怎么“高端”的词，而不是使用“构建”。是因为“构建”这个词，太容易引起歧义。而且打包这个词很形象，就是把源代码编译后，链接，最后打包成一个可执行包。当然不同的编程语言，打包过程可能不同。
因为大多数团队都没有写自动化测试的习惯（我们团队也不例外），让他们写自动化测试，他们只会觉得自己的工作量增加了。所以，我在团队中导入持续交付实践时，一开始就不要求自动化测试。团队意识的转变需要很长的过程。这是使用“打包”的第二个原因：它不包括自动化测试。
要实现自动化打包，其实并不难。基本步骤就是：
-
搭建制品库：Nexus。
-
搭建自动化服务：Jenkins。
-
在Jenkins中创建pipeline任务。
-
在业务代码仓库中加入Jenkinsfile，将打包逻辑写到Jenkinsfile中。
所谓打包逻辑就是你在本地开发时，利用IDE或命令将源代码编译成可执行文件的过程。打包自动化的过程，就是将你在本地执行的打包过程“搬”到自动化系统上执行，再加上一些优化。
在这个阶段中，我们需要实现：
-
统一制品库：收回所有人上传制品的账号。只能由Jenkins打包上传。
-
统一版本号：比如使用格式
年-月-日-commitId-构建号来定义所有的后端应用。注意，不管使用哪种方式，你必须很容易的根据版本号找回相应的源码。 -
统一分支管理：使用主干开发，分支发布的模式。我们根据团队情况有稍微做了一些改变。发布并没有切分支出来，而在发布后发现某版本有Bug，我们就会从该版本的代码切一个分支出来改，打包，部署。最后再将该分支的commit cherry pick回master分支。
2. 实现基础监控
没有监控，在我们这个行业太常见了。所以，在我加入团队后，发现几乎没有任何监控，也就没有什么好惊讶的了。所以，在解决打包问题之后 ，紧接着就是给所有的机器加上监控。至少机器的CPU、硬盘、内存等要监控起来。
上一阶段，我们已经把Jenkins搭建起来，所以，Prometheus就开始自动化部署了。
使用Prometheus的原因很多，但是关键是它的配置是代码化的，非常容易版本化。持续交付的原则：将几乎所有的事情自动化、把所有的东西都纳入版本控制。像Zabbix，使用需要使用界面进行操作的，就被我排除了。
在这个阶段中，我们需要实现：
-
尽量不要动老机器的配置。要做的就是在该机器上安装node-exporter方便监控。
-
新机器使用
HashcorpPacker进行标准化操作系统 。新机器统一使用新的标准化的操作系统 。 -
使用Prometheus监控所有的机器。同时，需要对告警进行分级。我们根据紧急程度，将告警发往不同的钉钉群。
-
中间件的监控，找到相应的exporter即可。
3. 实现所有的配置项版本化
“配置”是一个非常容易产生分歧的词。它可以是一个名词，也可以是一个动词。作为名词，我们把它称为配置项，以区别于动词。另一个使用“配置项”的原因是，当人们讨论配置时，大脑里通常是 properties、 yaml等这类文件格式，又或者是像 consul、 ctripcorp/apollo等这类分布式配置中心。而笔者所说的配置项是独立于任何文件格式及其被使用的方式的。
笔者认为这样理解“配置”更合理：
