每个软件项目都有两种类型的in构成：信息比项目的源代码存储库的范围更广；隐式地绑定到项目源代码的信息代码。这个分离是很重要的，因为如果你把一种信息储存在另一个地方，你就会让自己面对痛苦的世界。让我们看一个例子："当FooBar项目被构建时，我们需要将它部署到一个登台环境中。"这条信息的范围比FooBar项目的源代码更广。源代码不知道登台环境的IP地址。源代码不知道用于部署到登台环境的凭据。将这些东西存储在源代码管理中是很诱人的……当然是的，毕竟我们都有过这样的经历。但最终，这是错误的做法：你不能重新部署旧版本来验证错误，因为IP地址或凭据已经更改，等等，另一个示例："我们通过使用Bargle命令行参数运行SuperBuzzDing构建工具来构建FooBar项目。"这段信息与源代码耦合得非常紧密你正在建造。当你使用FooBar的2.0版本时，你可能需要在命令行中添加更多的位。或者构建一个完全不同的过程完全。传统上，Jenkins采用的方法是，它不需要您正在构建的源代码存储库中的任何内容。像你这样的松耦合。这在一定程度上是好的。它允许您将大于单个项目的信息保留在该项目之外。更改登台环境并不需要更改源代码。但这种灵活性是有代价的。我们没有标准位置来存储与源代码紧密耦合的信息。有文化的构建提供了这样一个位置，并在这样做中启用了一些非常有用的功能。有文化的建筑使用自述文件.md在软件项目的根目录中存储生成指令的文件。在大多数正常的项目中，自述文件要么丢失，要么彻底过时。通过使用此文件作为生成说明的源，我们可以确保该文件保持正确和最新。如果构建工具从批处理文件/shell脚本更改为Makefile再到Ant生成.xml对一个小牛pom.xml文件，没关系，因为自述文件.md将用代码更新（或者Jenkins将报告一个失败的构建）。另一个与项目源代码非常相关的重要信息是构建源代码所需的确切的工具链。该项目的1.0版可能需要Windows上的Ruby1.8，2.0版可能需要Windows或Linux上的Ruby1.9，3.0版可能构建在Ruby2.0上，但仅限于Linux。这是人们通常保存在自述文件中的信息。通过利用这些信息，Jenkins能够针对所有目标环境验证构建指令，并确保指令不仅正确，而且在所有受支持的平台上都是正确的。literate构建提供的最后一个难题是，现在可以让Jenkins自动为项目的所有分支创建工作岗位。因为每个分支现在都存储自己的相关构建指令，所以可以在创建每个分支时创建分支项目作业（如果选择销毁）。这使得开发风格更加灵活，其中创建分支的管理开销要少得多。套用几位詹金斯的管理员的话来说："我讨厌分支机构，因为我必须去为每个分支机构创造5到6个工作岗位，然后两周后分支机构又消失了。"有了literate builds插件，Jenkins会自动创建这些工作，并在它们消失后再次删除它们。詹金斯管理员可以自由地回到他或她的主要工作。我将用一个有文化的建筑的例子来结束这篇文章比如：FooBar项目==============这是一个FooBar项目，它允许您阻止Foo进入您的计算机。环境------------项目可以在以下环境中构建：*"ruby-2.0"、"java-1.7"、"maven-3.0.5"、"rake-10.0.3"`*`linux`*`windows`*`osx`如何构建------------*在`windows上`呼叫mvn.bat公司清洁验证呼叫蝙蝠耙*在`linux上`mvn清洁验证；耙*打开`osx`mvn clean verify；rake上面的例子是一个不错的、干净的例子自述文件.md文件和供詹金斯使用的生成说明。有关literate构建的更多信息，请参见以下内容资源：詹金斯家族wiki页面：https://wiki.jenkins ci.org/display/jenkins/Literate+plugin插件的自述文件.md（狗食）：https://github.com/jenkinsci/literate-pluginOur自己的wiki页面识字项目示例：https://github.com/jenkinsci/literate-api/tree/master/src/test/resources/org/cloudbees/literate/api/v1/MarkdownModelTest-斯蒂芬康诺利云蜂cloudbees.com斯蒂芬康诺利有超过20年的软件开发经验。他参与了许多开源项目，包括Jenkins。Stephen是Jenkins项目的首批非Sun成员之一，他开发了天气图标。斯蒂芬住在爱尔兰都柏林，那里的天气图标特别有用。在Twitter和他的博客上关注斯蒂芬。