一位老极客的眼中的开发和部署

admin

多年前，我曾是一名 Smalltalk 程序员，这种经验让我以一种不同的视角来观察编程的世界，例如，需要花时间来适应源代码应该存储在文本文件中的这种做法。 -- Robert M. Lefkowitz

编译自： https://opensource.com/article/17/1/difference-between-development-deployment
作者： Robert M. Lefkowitz
译者： geekpi

多年前，我曾是一名 Smalltalk 程序员，这种经验让我以一种不同的视角来观察编程的世界，例如，需要花时间来适应源代码应该存储在文本文件中的这种做法。
我们作为程序员通常会区分“开发”和“部署”，特别是我们在开发的地方所使用的工具不同于我们在之后部署软件时的地点和工具时。而在 Smalltalk 世界里，没有这样的区别。
Smalltalk 构建于虚拟机包含了你的开发环境（IDE、调试器、文本编辑器、版本控制等）的思路之上，如果你需要修改任何一处代码，你得修改内存中运行副本。如果需要的话，你可以为运行中的机器做个快照；如果你想分发你的代码，你可以发送一个运行中的机器的镜像副本（包括 IDE、调试器、文本编辑器、版本控制等）给用户。这就是上世纪 90 年代软件开发的方式（对我们中的一些人来说）。
如今，部署环境与开发环境有了很大的不同。起初，你不要期望那里（指部署环境）有任何开发工具。一旦部署，就没有版本控制、没有调试、没有开发环境。有的是记录和监视，这些在我们的开发环境中都没有，而有一个“构建管道”，它将我们的软件从开发形式转换为部署形式。作为一个例证，Docker 容器则试图重新找回上世纪 90 年代 Smalltalk 程序员部署体验的那种简单性，而避免同样的开发体验。
我想如果 Smalltalk 世界是我唯一的编程方面的体验，让我无法区分开发和部署环境，我可能会偶尔回顾一下它。但是在我成为一名 Smalltalk 程序员之前，我还是一位 APL 程序员，这也是一个可修改的虚拟机镜像的世界，其中开发和部署是无法区分的。因此，我相信，在当前的时代，人们编辑单独的源代码文件，然后运行构建管道以创建在编辑代码时尚不存在的部署作品，然后将这些作品部署给用户。我们已经以某种方式将这种反模式的软件开发制度化，而不断发展的软件环境的需求正在迫使我们找回到上世纪 90 年代的更有效的技术方法。因此才会有 Docker 的成功，所以，我需要提出我的建议。
我有两个建议：我们在运行时系统中实现（并使用）版本控制，以及，我们通过更改运行中的系统来开发软件，而不是用新的运行系统替换它们。这两个想法是相关的。为了安全地更改正在运行的系统，我们需要一些版本控制功能来支持“撤消”功能。也许公平地说，我只提出了一个建议。让我举例来说明。
让我们开始假设一个静态网站。你要修改一些 HTML 文件。你应该如何工作？如果你像大多数开发者一样，你会有两个，也许三个网站 - 一个用于开发，一个用于 QA（或者预发布），一个用于生产。你将直接编辑开发实例中的文件。准备就绪后，你将把你的修改“部署”到预发布实例。在用户验收测试之后，你将再次部署，这次是生产环境。
使用 Occam 的 Razor，让我们可以避免不必要地创建实例。我们需要多少台机器？我们可以使用一台电脑。我们需要多少台 web 服务器？我们可以使用具有多个虚拟主机的单台 web 服务器。如果不使用多个虚拟主机的话，我们可以只使用单个虚拟主机吗？那么我们就需要多个目录，并需要使用 URL 的顶级路径来区分不同的版本，而不是虚拟主机名。但是为什么我们需要多个目录？因为 web 服务器将从文件系统中提供静态文件。我们的问题是，目录有三个不同的版本，我们的解决方案是创建目录的三个不同的副本。这不是正是 Subversion 和 Git 这样的版本控制系统解决的问题吗？制作目录的多个副本以存储多个版本的策略回到了版本控制 CVS 之前的日子。为什么不使用比如说一个空的的 Git 仓库来存储文件呢？要这样做，web 服务器将需要能够从 git 仓库读取文件（参见 mod_git[1]）。
这将是一个支持版本控制的运行时系统。
使用这样的 web 服务器，使用的版本可以由 cookie 来标识。这样，任何人都可以推送到仓库，用户将继续看到他们发起会话时所分配的版本。版本控制系统有不可改变的提交； 一旦会话开始，开发人员可以在不影响正在运行的用户的情况下快速推送更改。开发人员可以重置其会话以跟踪他们的新提交，因此开发人员或测试人员就可能如普通用户一样查看在同台服务器上同一个 URL 上正在开发或正在测试的版本。作为偶然的副作用，A/B 测试仅仅是将不同的用户分配给不同的提交的情况。所有用于管理多个版本的 git 设施都可以在运行环境中发挥作用。当然，git reset 为我们提供了前面提到的“撤销”功能。
为什么不是每个人都这样做？
一种可能性是，诸如版本控制系统的工具没有被设计为在生产环境中使用。例如，给某人推送到测试分支而不是生产分支的许可是不可能的。对这个方案最常见的反对是，如果发现了一个漏洞，你会想要将某些提交标记为不可访问。这将是另一种更细粒度的权限的情况；开发人员将具有对所有提交的读取权限，但外部用户不会。我们可能需要对现有工具进行一些额外的改造以支持这种模式，但是这些功能很容易理解，并已被设计到其他软件中。例如，Linux （或 PostgreSQL）实现了对不同用户的细粒度权限的想法。
随着云环境变得越来越普及，这些想法变得更加相关：云总是在运行。例如，我们可以看到，AWS 中等价的 “文件系统”（S3）实现了版本控制，所以你可能有一个不同的想法，使用一台 web 服务器提供来自 S3 的资源文件，并根据会话信息选择不同版本的资源文件。重要的并不是哪个实现是最好的，而是支持这种运行时版本控制的愿景。
部署的软件环境应该是“版本感知”的原则，应该扩展到除了服务静态文件的 web 服务器之外的其他工具。在将来的文章中，我将介绍版本库，数据库和应用程序服务器的方法。
作者简介：
Robert M. Lefkowitz - Robert（即 r0ml）是一个喜欢复杂编程语言的编程语言爱好者。 他是一个提高清晰度、提高可靠性和最大限度地简化的编程技术收藏家。他通过让计算机更加容易获得来使它普及化。他经常演讲中世纪晚期和早期文艺复兴对编程艺术的影响。
via: https://opensource.com/article/17/1/difference-between-development-deployment
作者：Robert M. Lefkowitz[2] 译者：geekpi 校对：Bestony
本文由 LCTT 原创编译，Linux中国 荣誉推出

[1]: mod_git - https://github.com/r0ml/mod_git
[2]: Robert M. Lefkowitz - https://opensource.com/users/r0ml

声明:本文转载自网络。版权归原作者所有,如有侵权请联系删除。