开发环境与工具部署服务

多年以来，我是一名Smalltalk程序员，这种经验使我从不同的角度来观察编程世界中的思想。 例如，将源代码存储在文本文件中的想法已经习惯了一些。

作为程序员，我们经常在“开发”和“部署”之间进行区分，特别是我们在一个地方使用与部署软件后使用的工具不同的工具来开发软件的想法。 在Smalltalk的世界中，没有这种差异。

Smalltalk是基于包含您的开发环境（IDE，调试器，文本编辑器，版本控制等）的虚拟机的思想而建立的，如果您必须修改任何代码，则可以修改内存中的运行副本。 如果要对运行中的计算机进行快照，则可以这样做，并且如果要分发代码，则可以将运行中的计算机映像的副本（包括IDE，调试器，文本编辑器，版本控制等）发送到用户。 这就是90年代（对于我们中的某些人）软件开发的工作方式。

如今，部署环境与开发环境大不相同。 对于初学者，您不希望有任何开发工具。 部署后，将没有版本控制，调试和开发环境。 有我们在开发环境中没有的日志记录和监视，还有一个“构建管道”，它将我们的软件从我们开发的形式转换为部署的形式。 例如，Docker容器试图重获1990年代Smalltalk程序员的部署经验的某些简单性，而又不希望为开发经验做同样的事情。

我想如果Smalltalk世界是我唯一的未能在开发环境和部署环境之间进行区分的编程隐喻经验，那么我可能会fl幸地回顾它。 但是在我成为Smalltalk程序员之前，我曾是APL程序员，那也是一个可破解的虚拟机映像的世界，在其中无法清晰地进行开发和部署。 因此，我很确信当前的世界是people幸，在这个世界中，人们编辑了单独的源代码文件，然后运行构建管道来创建在编辑代码时不存在的部署工件，然后将这些工件部署给用户。 我们已经以某种方式使这种软件开发反模式制度化，并且不断发展的软件环境的要求正迫使我们寻找回到1990年代更有效的技术的途径。 因此，Docker取得了成功。 因此，需要我将要提出的建议。

我有两个建议：我们在运行时系统中实现（和使用）版本控制，并且我们通过对正在运行的系统进行更改来开发软件，而不是用新的正在运行的系统替换它们。 这两个想法是相关的。 为了安全地对正在运行的系统进行更改，我们需要某种版本控制功能来支持“撤消”功能。 也许可以说我只提出一个建议。 让我举例说明。

让我们从想象一个静态网站开始。 您想要更改一些HTML文件。 那应该如何工作？ 如果您像大多数开发人员一样，将有两个，也许三个站点，一个站点用于开发，一个站点用于QA（或暂存），另一个站点用于生产。 您将直接在开发实例中编辑文件。 准备好后，您将“部署”对登台实例的更改。 在用户验收测试之后，您将再次部署，这一次将其投入生产。

使用Occam的Razor，让我们避免不必要地创建实体。 我们需要多少台机器？ 我们可以使用一台计算机。 我们需要多少个Web服务器？ 我们可以将单个Web服务器与多个虚拟主机一起使用。 我们可以使用一个虚拟主机，而不是多个虚拟主机吗？ 然后，我们将需要多个目录，并且需要使用URL的顶级路径来区分不同的版本，而不是虚拟主机名。 但是为什么我们需要多个目录？ 因为Web服务器将从文件系统提供静态资产。 我们的问题是目录有三个不同版本，我们的解决方案是制作目录的三个不同副本。 这不是Subversion和Git之类的版本控制系统要解决的问题吗？ 制作目录的多个副本以存储多个版本的策略可以追溯到CVS之前的日子。 为什么不使用裸Git仓库来存储文件呢？ 因为这样做，Web服务器将需要能够从git存储库中读取文件（请参阅mod_git ）。

那将是一个支持版本控制的运行时系统。

使用这样的Web服务器，将通过例如标识它的cookie来标识所提供的版本。 这样，任何人都可以推送到一个存储库，并且用户在启动会话时将继续看到他们分配的版本。 版本控制系统具有不变的提交； 会话开始后，开发人员可以随时随地轻松地推动更改，而不会影响正在运行的用户。 开发人员可以重置其会话以跟踪其新提交，因此开发人员或测试人员可以使用与普通用户相同的URL和相同的服务器查看正在开发或测试中的版本。 作为一个偶然的副作用，A / B测试只是将不同的用户分配给不同的提交的一种情况。 用于管理多个版本的所有git工具都在运行环境中使用。 而且，当然，git reset为我们提供了前面提到的“撤消”功能。

为什么每个人都不这样做？

一种可能性是诸如版本控制系统之类的工具并非设计用于生产环境。 例如，不允许某人允许推送到测试分支，但不允许其推送到生产分支。 此方案最常见的反对意见是，如果发现了漏洞，则希望将某些提交标记为不可访问。 这将是更细粒度权限的另一种情况； 开发人员将具有对所有提交的读取访问权限，但外部用户则没有。 我们可能需要对现有工具进行一些额外的工程设计来支持这种范例，但是这些功能很容易理解，并且已经在其他软件工件中进行了工程设计。 例如，Linux（或PostgreSQL）实现了针对不同用户的细粒度权限的想法。

随着云环境变得越来越普遍，这些想法也变得越来越相关：云始终在运行。 例如，我们可以看到，等效于AWS的“文件系统”（S3）实现了版本控制，因此您可能对此想法有所不同，其中涉及一个Web服务器为S3提供资产，并使用会话信息选择不同的版本。这些资产。 重要的思想不是哪种实现是最好的，而是渴望支持运行时版本控制。

已部署的软件环境应具有“版本意识”的原则，除提供静态资产的Web服务器外，还扩展到其他工具。 在以后的文章中，我将介绍版本库，数据库和应用程序服务器的版本管理方法。

在Hobart的linux.conf.au 2017（ ＃lca2017 ）中的Robert Lefkowitz的演讲中了解更多信息： 保持Linux 出色 。

翻译自: https://opensource.com/article/17/1/difference-between-development-deployment

开发环境与工具部署服务