mirror of
https://github.com/LCTT/TranslateProject.git
synced 2025-01-25 23:11:02 +08:00
geekpi
GitHub
commit
10332b3364
@ -1,61 +0,0 @@
|
||||
translating---geekpi
|
||||
|
||||
The difference between development and deployment
|
||||
============================================================
|
||||
|
||||
Image by :
|
||||
|
||||
opensource.com
|
||||
|
||||
For many years, I was a Smalltalk programmer, and that experience gives me a different viewpoint from which to observe ideas in the programming world. For example, the idea that source code should be stored in text files took some getting used to.
|
||||
|
||||
We as programmers often make a distinction between "development" and "deployment," specifically the idea that we develop software in one place using tools that are different from the place and tools that we use after we deploy the software. In the Smalltalk world, there is no such difference.
|
||||
|
||||
Smalltalk was built on the idea of a virtual machine that contained your development environment (IDE, debugger, text editor, version control, and more), and you if you had to modify any code, you would modify the in-memory running copy. If you wanted to snapshot your running machine you could do so, and if you wanted to distribute your code, you would send a copy of your running machine image (including the IDE, debugger, text editor, version control, and more) to the user. That's how software development worked (for some of us) in the '90s.
|
||||
|
||||
Today, the deployment environment is vastly different from the development environment. For starters, you have no expectation that any of your development tools are there. Once deployed, there is no version control, no debugging, no development environment. There is logging and monitoring, which we didn't have in our development environment, and there is a "build pipeline," which transforms our software from the form in which we develop into the form which we deploy. For example, Docker containers are an attempt to recapture some of the simplicity of the 1990's Smalltalk programmer's deployment experience without aspiring to do the same for the development experience.
|
||||
|
||||
I suppose that if the Smalltalk world had been my only programming metaphor experience that failed to differentiate between development and deployment environments, I might have looked back on it as a fluke. But before I was a Smalltalk programmer I was an APL programmer, and that was also a world of hackable virtual machine images in which development and deployment were indistinguishable. Therefore, I'm rather convinced that the current world in which people edit separate source code files and then run build pipelines to create deployment artifacts that didn't exist while editing code, and then deploy those artifacts to users, is the fluke. We have somehow institutionalized this software development anti-pattern, and the demands of the evolving software landscape are pressuring us to find a way back to the more effective techniques of the 1990's. Hence the success of Docker. Hence the need for what I am about to propose.
|
||||
|
||||
I have two suggestions: that we implement (and use) version control in runtime systems, and that we develop software by making changes to running systems, instead of replacing them with a new running system. These two ideas are related. In order to make changes safely to a running system, we need some versioning capability to support an "undo" capability. Perhaps it would be fair to say that I make only one suggestion. Let me illustrate by way of example.
|
||||
|
||||
Let's start by imagining a static website. You want to change some HTML files. How should that work? If you're like most developers, you'll have two, maybe three, sites—one for development, one for QA (or staging), and one for production. You'll directly edit the files in the development instance. When you're ready, you'll "deploy" your changes to the staging instance. After user acceptance testing, you'll deploy again, this time to production.
|
||||
|
||||
Using Occam's Razor, let's avoid creating entities needlessly. How many machines do we need? We could use a single computer. How many web servers do we need? We could use a single web server with multiple virtual hosts. Instead of multiple virtual hosts, could we use a single virtual host? Then we would need multiple directories and need to use the top-level path of the URL to differentiate the different versions instead of the virtual host name. But why do we need multiple directories? Because the web server will serve static assets from the file system. The problem we have is that there are three different versions of a directory, and our solution is to make three different copies of the directory. Is this not the very problem that version control systems like Subversion and Git are meant to solve? The strategy of making multiple copies of a directory to store multiple versions hearkens back to the days before CVS. Why not use, say, a bare Git repository to store the files? Because in order to do so, the web server would need to be able to read files from a git repository (see [mod_git][3]).
|
||||
|
||||
And that would be a run time system supporting versioning.
|
||||
|
||||
With such a web server, the version being served would be identified by, for example, a cookie identifying it. In this way, anybody could push to the one repository, and users would continue to see the version that they were assigned when they initiated their session. Version control systems have immutable commits; once a session begins, developers could cheerfully push changes whenever they felt like it without affecting running users. Developers could reset their sessions to track their new commits, so a developer or tester could be looking at a version in development or under test at the same URL and from the same server as the regular users. As a fortuitous side effect, A/B tests are simply a case of assigning different users to different commits. All of the git facilities for managing multiple versions are brought to bear in running environments. And, of course, a git reset offers us that "undo" capability we mentioned earlier.
|
||||
|
||||
Why doesn't everyone do this?
|
||||
|
||||
One possibility is that tools like version control systems were not designed to be used in production environments. For example, giving someone permission to push to the testing branch but not the production branch is not possible. The most common objection to this scheme is that if a vulnerability were discovered, you would want to mark certain commits as inaccessible. This would be another case of finer grained permissions; developers would have read access to all commits, but external users would not. We might need some additional engineering for existing tools to support this paradigm, but the features are easily understood and have been engineered into other software artifacts. For example, Linux (or PostgreSQL) implements the idea of fine grained permissions for different users.
|
||||
|
||||
As cloud environments become more common, these ideas become more relevant: the cloud is always running. We can see, for example, that the AWS equivalent of a "file system" (S3) implements versioning, so you might have a variation of this idea that involves a web server serving assets from S3, and using session information to select different versions of those assets. The important idea is not which implementation is the best, but the aspiration to support runtime versioning.
|
||||
|
||||
The principle that deployed software environments should be "version aware" extends to other tools besides web servers serving static assets. In future articles, I will reflect upon approaches for versioning libraries, databases, and application servers.
|
||||
|
||||
_Learn more in Robert Lefkowitz's talk at linux.conf.au 2017 ([#lca2017][1]) in Hobart: [Keeping Linux Great][2]._
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
作者简介：
|
||||
|
||||
|
||||
|
||||
Robert M. Lefkowitz - Robert (a/k/a r0ml) is a programming language enthusiast who enjoys obscure programming languages. He is a collector of programming techniques for improving clarity, increasing reliability, and maximizing brevity. He has a lifelong interest in democratizing computing by making it more accessible. He is a frequent speaker on the effects of the late Middle Ages and early Renaissance on the art of programming.
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/17/1/difference-between-development-deployment
|
||||
|
||||
作者：[Robert M. Lefkowitz][a]
|
||||
译者：[译者ID](https://github.com/译者ID)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://opensource.com/users/r0ml
|
||||
[1]:https://twitter.com/search?q=%23lca2017&src=typd
|
||||
[2]:https://www.linux.conf.au/schedule/presentation/107/
|
||||
[3]:https://github.com/r0ml/mod_git
|
||||
@ -0,0 +1,59 @@
|
||||
开发和部署的不同
|
||||
============================================================
|
||||
|
||||
图片提供 :
|
||||
|
||||
opensource.com
|
||||
|
||||
多年来，我是一名 Smalltalk 程序员，这种经验给让我在观察编程世界时有不同的想法。例如，源代码应该存储在文本文件中的想法需要一些习惯。
|
||||
|
||||
我们作为程序员通常区分“开发”和“部署”，特别是我们在一个地方开发使用的工具不同于我们之后部署软件时的地点和工具。在Smalltalk世界里，没有这样的区别。
|
||||
|
||||
Smalltalk 构建于虚拟机包含了你的开发环境（IDE、调试器、文本编辑器、版本控制等）的想法上，如果你必须修改任何代码，你将修改内存中运行副本。如果你想快照运行中的机器，你可以这样做，如果你想分发你的代码，你可以发送一个运行的机器镜像（包括IDE、调试器、文本编辑器、版本控制等）的副本到用户。这就是 90 年代软件开发的工作原理（对我们中的一些人来说）。
|
||||
|
||||
如今部署环境与开发环境有了很大的不同。对于初学者，你不希望那里有任何开发工具。一旦部署，就没有版本控制、没有调试、没有开发环境。有记录和监视，这些在我们的开发环境中没有，并且有一个“构建管道”，它将我们的软件从我们开发形式转换为部署形式。例如，Docker 容器试图重新抓住 1990 年代 Smalltalk 程序员部署经验的一些简单性，而不希望对开发体验做同样的事情。
|
||||
|
||||
我想如果 Smalltalk 世界是我唯一的编程隐喻体验，无法区分开发和部署环境，我可能作为侥幸回顾一下它。但在我是一名 Smalltalk 程序员之前，我是一位 APL 程序员，这也是一个可以修改虚拟机镜像的世界，其中开发和部署是无法区分的。因此，我相信，当前的世界，人们编辑单独的源代码文件，然后运行构建管道以e创建在编辑代码时不存在的部署工作，然后将这些作品部署到用户。我们已经以某种方式将这种反模式软件开发制度化，并且不断发展的软件环境的需求正在迫使我们找到回到 20 世纪 90 年代更有效的技术的方法。因此会有 Docker 的成功。因此，我需要提出建议。
|
||||
|
||||
我有两个建议：我们在运行时系统中实现（和使用）版本控制，我们通过更改运行系统来开发软件，而不是用新的运行系统替换它们。这两个想法是相关的。为了安全地更改正在运行的系统，我们需要一些版本控制功能来支持“撤消”功能。也许公平地说，我只提出一个建议。让我举例来说明。
|
||||
|
||||
让我们开始想象一个静态网站。你要修改一些 HTML 文件。你应该如何工作？如果你像大多数开发者一样，你会有两个，也许三个网站 - 一个用于开发，一个用于QA（或者预发布），一个用于生产。你将直接编辑开发实例中的文件。准备就绪后，你将“部署”你的修改到预发布实例。在用户验收测试之后，你将再次部署，这次是生产环境。
|
||||
|
||||
使用 Occam 的 Razor，让我们避免不必要地创建实例。我们需要多少台机器？我们可以使用一台电脑。我们需要多少台网络服务器？我们可以使用具有多个虚拟主机的单台 web 服务器，而不是多个虚拟主机，我们可以使用单台虚拟主机吗？然后，我们需要多个目录，并需要使用 URL 的顶级路径来区分不同的版本，而不是虚拟主机名。但是为什么我们需要多个目录？因为 web 服务器将从文件系统中提供静态文件。我们的问题是，目录有三个不同的版本，我们的解决方案是创建目录的三个不同的副本。这不是像 Subversion 和 Git 这样的版本控制系统解决的问题？制作目录的多个副本以存储多个版本的策略回到了 CVS 之前的日子。为什么不使用，也就是一个空的的 Git 仓库来存储文件？因为要这样做，web 服务器将需要能够从 git 仓库读取文件（参见[mod_git] [3]）。
|
||||
|
||||
这将是一个支持版本控制的运行时系统。
|
||||
|
||||
使用这样的 web 服务器，使用的版本可以由 cookie 来标识。这样，任何人都可以推送到仓库，用户将继续看到他们发起会话时分配的版本。版本控制系统有不可改变的提交; 一旦会话开始，开发人员可以在不影响正在运行的用户的情况下快速推送更改。开发人员可以重置其会话以跟踪他们的新提交，因此开发人员或测试人员就可能如普通用户一样查看在同台服务器上同一个URL上正在开发或正在测试的版本。作为偶然的副作用，A/B 测试仅仅是将不同的用户分配给不同的提交的情况。所有用于管理多个版本的 git 设施都在运行环境中发挥作用。当然，git reset 为我们提供了前面提到的“撤销”功能。
|
||||
|
||||
为什么不是每个人都这样做？
|
||||
|
||||
一种可能性是，诸如版本控制系统的工具不被设计为在生产环境中使用。例如，给某人许可推送到测试分支而不是生产分支是不可能的。对这个方案最常见的反对是，如果发现了一个漏洞，你会想要将某些提交标记为不可访问。这将是另一种更细粒度的权限的情况;开发人员将具有对所有提交的读取权限，但外部用户不会。我们可能需要对现有工具进行一些额外的工作以支持这种模式，但是这些功能很容易理解，并已被设计到其他软件中。例如，Linux （或 PostgreSQL）实现了对不同用户的细粒度权限的想法。
|
||||
|
||||
随着云环境变得越来越普及，这些想法变得更加相关：云总是在运行。例如，我们可以看到，AWS 中等价的 “文件系统”（S3）实现了版本控制，所以你可能有一个不同的想法，使用一台 web 服务器提供来自 S3 的资产，并使用会话信息选择不同版本的资产。重要的想法并不是实现是最好的，而是支持运行时版本控制的愿望。
|
||||
|
||||
部署的软件环境应该是“版本感知”的原则扩展到除了服务静态资产的web服务器之外的其他工具。在将来的文章中，我将介绍版本库，数据库和应用程序服务器的方法。
|
||||
|
||||
_在 linux.conf.au 中了解更多 Robert Lefkowitz 2017 年 （[＃lca2017][1]）在 Hobart：[保持 Linux 伟大][2]的主题。_
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
作者简介：
|
||||
|
||||
|
||||
|
||||
Robert M. Lefkowitz - Robert（a / k / a r0ml）是一个喜欢复杂编程语言的编程语言爱好者。 他是一个提高清晰度、提高可靠性和最大限度地简化编程技术的收藏家。他通过让计算机更加容易获得来使它普及化。他经常演讲中世纪晚期和早期文艺复兴对编程艺术的影响。
|
||||
|
||||
--------------------------------------------------------------------------------
|
||||
|
||||
via: https://opensource.com/article/17/1/difference-between-development-deployment
|
||||
|
||||
作者：[Robert M. Lefkowitz][a]
|
||||
译者：[geekpi](https://github.com/geekpi)
|
||||
校对：[校对者ID](https://github.com/校对者ID)
|
||||
|
||||
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出
|
||||
|
||||
[a]:https://opensource.com/users/r0ml
|
||||
[1]:https://twitter.com/search?q=%23lca2017&src=typd
|
||||
[2]:https://www.linux.conf.au/schedule/presentation/107/
|
||||
[3]:https://github.com/r0ml/mod_git
|
||||
Loading…
Reference in New Issue
Block a user