接下来的几篇文章开始讲讲DevOps如何去进行落的。前几篇可能会引入一些技术方面的内容去逐步代入，后面可能会花1-2两篇讨论一下我的一些DevOp s在企业落地的观点。
记得我们在第一篇就讨论了研发同学在构建部署自己的应用的时候如何借助于『别人』进行，今天我们就来讨论下这个『别人』到底是谁。
对于强类型语言来说，正常一个应用会经历编译、检查、打包等环节，当然现在一些弱类型的脚本语言其实也有一系列的打包流程，比如javascript可以通过nodejs所支撑的工具打成统一的bundle。所以其实对于现代语言来说，一旦进行工程化，肯定都会涉及到包的管理以及一些规范的打包流程。所以我们要做的第一件事情就是要了解这些流程是怎么运转的，知道了流程的运转，我们才能将流程进行工具流水化。
下面以java为例，我们看一下java生成包所经历的过程。 java应用的构建与打包其实也经历了很多个过程。比如早期的时候，通过人工导出WAR或者JAR的方式，后来出现Ant，通过编写Ant脚本进行包的构建，再后来有了maven，通过maven所提供的全生命周期的插件对一个java应用进行管理，其中也包括对JAR包的管理，再后来有了gradle，而gradle提升了构建的速度。目前大部分企业还是专门以maven的方式进行java应用的全生命周期管理。 那maven是如何来管理应用的生命周期的呢？
我们知道一个java应用包括如下几个方面的内容： 1、业务代码。这部分就是一个应用最核心的部分； 2、JAR包。JAR包可以把它理解成支撑java业务代码的一些现成的开箱即用的工具，其是java应用很重要的一个组成部分； 3、各种配置文件。比如xml、yaml、properties等等，其会随着构建一起到最终的制品中去。 那么知道了一个常规java的组成结构后，我们就可以接着思考如下的一些问题。 首先，对于支撑java业务代码的这些工具的JAR，是否有统一管控的地方？ maven就很完美地解决了这个问题。它是如何解决的呢？其通过一个类似于物料清单的文件对你的java应用所依赖的JAR进行统一的管控。比如如下所示：
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>${slf4j.version}</version>
</dependency>
通过如上的这种管理方式，它就将所有的你的java应用所依赖的JAR进行管理了。目前所有主流的语言都有自己的包管理文件，比如前端项目的package.json，基于go的mod，比如python的setuptools或者pip等等，其实都是一种应用工程化的表现。 那么就有人要问了，既然你的JAR都通过物料清单进行管理了，那么它是从哪里去获取这些物料的呢？
这里就要介绍一个很重要的概念-制品库。
所谓的制品库，实际上就是你的代码最终变成产品去交付并进行版本管理的地方，比如你用java编写了一个通用工具，那么这个工具打包成JAR后你就可以放到制品库去，别人知道了你的JAR拉取的地址信息后，就可以使用了。目前制品库的产品还是比较多，比如java的代表nexus，js的代表npm库，docker镜像的代表docker registry或者自行搭建的harbor等，而且也有很多公有的制品库，这些公有的制品库支撑着全世界各地的应用的日常运转。以java为例的话，企业内还是以nexus为主。
所以，有了物料清单文件以及成熟的制品库后，你不光可以去使用别人的工具，也可以将自己的工具提供给别人使用，所以这本质上就是一种共享的理念。
以java为例，有了物料清单文件和制品库仅仅是解决了我们JAR的管理问题，那对于应用最重要的编译和打包又怎么进行呢？ 其实maven这类成熟的工具已经帮我们解决了。
在物料清单中，除了对JAR的管理，其实也包含maven所提供的插件管理。比如如下：
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
</plugin>
其就是代表着一类插件-编译java代码的插件，比如maven还提供了打JAR的插件、打WAR的插件、将制品上传到制品库的插件等等，maven给我们提供了插件的时候，也没忘给我们提供命令脚本，比如：
mvn clean compile、mvn clean package、mvn clean install，有了这些命令，我们就可以通过程序去驱动这些命令进行日常的打包操作。
知道了编译打包流程还不行，我们还要考虑如何能够让代码流动起来。 什么意思呢？比如一旦我们代码做了提交后，就会自动地给我们应用做打包构建操作；或者我们有工具能够获取到我们代码仓库的分支，并对这个分支的代码进行一键打包构建。那如何进行呢？
其实我个人觉得也非常简单。 我们就拿本地为例，假如我在本地修改了一个应用的某段代码，那么这个时候脚本或者工具能够知道我的代码有了变化，那么就开始进行构建打包操作。我用一段python的伪代码来演示一下：
import os
def test_package():
codes = find_codes()
for code in codes:
md5_str = md5(code)
if md5_str != old_md5_str:
success = os.system("mvn clean install")
if success == 0:
//如果是制品，就deploy，比如不是，此处不运行
os.system("mvn clean deploy")
break
如上代码只是我们为了说明这个流程写的一个无法运行的案例，实际上肯定不会这么来做，远比这么简单。 那么有了这个思路之后，我们就可以进行常规的打包构建过程了。 所以自动化构建打包其实也没有那么复杂，只需要去寻找应用中所存在的规律即可。 况且其实如今也有很多开源的工具给我们做这些事情。 那么，到底有哪些开源工具能帮我们做这些自动化打包构建的事情以及自动化部署又是如何来做呢？ 我们下一篇再继续探索。
—————–EOF——————