|
|
@@ -249,7 +249,6 @@ code > span.in { color: #60a0b0; font-weight: bold; font-style: italic; } /* Inf
|
|
|
<li><a href="#自动化部署">自动化部署</a></li>
|
|
|
<li><a href="#依赖与包仓库">依赖与包仓库</a><ul>
|
|
|
<li><a href="#构建软件包">构建软件包</a></li>
|
|
|
-<li><a href="#生成上传安装包">生成、上传安装包</a></li>
|
|
|
<li><a href="#目标平台安装配置">目标平台安装/配置</a></li>
|
|
|
</ul></li>
|
|
|
</ul></li>
|
|
|
@@ -2818,12 +2817,15 @@ System.<span class="fu">out</span>.<span class="fu">println</span>(<span class="
|
|
|
<img src="chapters/chapter4/hierarchy-vs-graph.png" alt="大教堂与集市" /><figcaption>大教堂与集市</figcaption>
|
|
|
</figure>
|
|
|
<p>过去我们需要大系统的内部构建我们使用的依赖，现在我们更多地借助于外部的库来实现这些功能。这也意味着，如果在这一个节点里出现了意外——软件被删除，那么这个系统将陷入瘫痪的状态。如之前在NPM圈发生了“一个 17 行的模块引发的血案”——即left-pad 工具模块被作者从NPM上撤下，所有直接或者间接依赖这个模块的NPM的软件包都挂掉了。因为我们依赖于公有的包服务，所以系统便严重依赖于外部条件。</p>
|
|
|
-<p>这时候一种简单、有效的方案就是搭建自己的包服务。如使用Java技术栈的项目，就会去搭建自己的Maven私有服务。</p>
|
|
|
+<p>这时候一种简单、有效的方案就是搭建自己的包服务。如使用Java技术栈的项目，就会使用Nexus搭建自己的Maven私有服务。我们的软件依赖包将会依赖于我们自己的服务，此时会产生的主要问题可能就是：我们的软件包不是最新的。但是对于追求稳定的项目来说，这个并不是必须的需求，反而这也是一个优势。</p>
|
|
|
<h3 id="构建软件包">构建软件包</h3>
|
|
|
+<p>在一些编译型语言里，在我们运行包测试后，我们将会得到一个软件包。在Java语言里，这个包就是jar包。它是Java中所特有一种压缩文档，可以将其理解为.zip包。 只是JAR包中有一个META-INF.MF文件，当你找成JAR包时，它会自动生成。Jar包无法直接安装使用，虽然我们可以直接运行这个Jar包，但是我们需要通过一些手段将这个Jar包拷贝到我们的服务器上，然后运行。在特定的时候，我们还需要修改配置才能完成我们的工作。</p>
|
|
|
+<p>因此，使用RPM或者DEB包会是一种更好的选择。RPM全称是 Red Hat Package Manager（Red Hat包管理器），它工作于Red Hat Linux以及其它Linux和UNIX 系统，可被任何人使用。如下图是RPM包的构建过程：</p>
|
|
|
<figure>
|
|
|
<img src="chapters/chapter4/rpm-deploy.jpg" alt="RPM Build Process" /><figcaption>RPM Build Process</figcaption>
|
|
|
</figure>
|
|
|
-<h3 id="生成上传安装包">生成、上传安装包</h3>
|
|
|
+<p>要构建一个标准的RPM包，我们需要创建.spec文件，这个文件包含软件打包的全部信息——如包的Summary、Name、Version、Copyright、Vendor等等。在产生完这一个配置文件事，执行rpmbuild 命令，系统会按照步骤生成目标RPM包。</p>
|
|
|
+<p>生成对应的软件包后，我们就可以将其上传到Koji上，它是Fedora 社区的编译系统。</p>
|
|
|
<h3 id="目标平台安装配置">目标平台安装/配置</h3>
|
|
|
<h1 id="数据分析">数据分析</h1>
|
|
|
<p>有时候，对于我们的决定只要有一点点的数据支持就够了。也就是一点点的变化，可能就决定了我们产品的好坏。我们可能会因此而作出一些些改变，这些改变可能会让我们打败巨头。</p>
|
Fengda HUANG