Merge pull request #5189 from bestony/master

校对完成 @geekpi
This commit is contained in:
Xingyu.Wang 2017-02-25 14:27:43 +08:00 committed by GitHub
commit 4386983ec4

View File

@ -1,19 +1,18 @@
开发和部署的不同
============================================================
![The difference between development and deployment](https://opensource.com/sites/default/files/styles/image-full-size/public/images/business/BUS_OpenSourceExperience_520x292_cm.png?itok=APna2N9Y "The difference between development and deployment")
图片提供 : 
![The difference between development and deployment](https://opensource.com/sites/default/files/styles/image-full-size/public/images/business/BUS_OpenSourceExperience_520x292_cm.png?itok=APna2N9Y "The difference between development and deployment")
opensource.com
图片提供 : opensource.com
多年,我是一名 Smalltalk 程序员,这种经验给让我在观察编程世界时有不同的想法。例如,源代码应该存储在文本文件中的想法需要一些习惯
多年,我是一名 Smalltalk 程序员,这种经验给让我在观察编程世界时有不同的想法。例如,花时间来适应源代码应该存储在文本文件中的想法。
我们作为程序员通常区分“开发”和“部署”特别是我们在一个地方开发使用的工具不同于我们之后部署软件时的地点和工具。在Smalltalk世界里没有这样的区别。
我们作为程序员通常区分“开发”和“部署”,特别是我们在一个地方开发使用的工具不同于我们之后部署软件时的地点和工具。在 Smalltalk 世界里,没有这样的区别。
Smalltalk 构建于虚拟机包含了你的开发环境IDE、调试器、文本编辑器、版本控制等的想法上如果你必须修改任何代码你将修改内存中运行副本。如果你想快照运行中的机器你可以这样做如果你想分发你的代码你可以发送一个运行的机器镜像包括IDE、调试器、文本编辑器、版本控制等的副本到用户。这就是 90 年代软件开发的工作原理(对我们中的一些人来说)。
Smalltalk 构建在包含了你的开发环境IDE、调试器、文本编辑器、版本控制等的虚拟机的想法之上如果你不得不修改任何一处代码你要修改内存中运行副本。如果你可以为运行中的机器打个快照如果你想做的话,如果你想分发你的代码,你可以发送一个运行的机器镜像包括IDE、调试器、文本编辑器、版本控制等的副本到用户。这就是 90 年代软件开发的工作原理(对我们中的一些人来说)。
如今部署环境与开发环境有了很大的不同。对于初学者,你不望那里有任何开发工具。一旦部署就没有版本控制、没有调试、没有开发环境。有记录和监视这些在我们的开发环境中没有并且有一个“构建管道”它将我们的软件从我们开发形式转换为部署形式。例如Docker 容器试图重新抓住 1990 年代 Smalltalk 程序员部署经验的一些简单性,而不希望对开发体验做同样的事情。
如今部署环境与开发环境有了很大的不同。对于初学者,你不要期望那里有任何开发工具。一旦部署,就没有版本控制、没有调试、没有开发环境。有的是记录和监视这些在我们的开发环境中没有并且有一个“构建管道”它将我们的软件从我们开发形式转换为部署形式。例如Docker 容器试图重新抓住 1990 年代 Smalltalk 程序员部署经验的一些简单性,而不希望对开发体验做同样的事情。
我想如果 Smalltalk 世界是我唯一的编程隐喻体验,无法区分开发和部署环境,我可能作为侥幸回顾一下它。但在我是一名 Smalltalk 程序员之前,我是一位 APL 程序员,这也是一个可以修改虚拟机镜像的世界,其中开发和部署是无法区分的。因此,我相信,当前的世界,人们编辑单独的源代码文件,然后运行构建管道以e创建在编辑代码时不存在的部署工作,然后将这些作品部署到用户。我们已经以某种方式将这种反模式软件开发制度化,并且不断发展的软件环境的需求正在迫使我们找到回到 20 世纪 90 年代更有效的技术的方法。因此会有 Docker 的成功。因此,我需要提出建议。
我想如果 Smalltalk 世界是我唯一的编程隐喻体验,无法区分开发和部署环境,我可能偶尔回顾一下它。但在我是一名 Smalltalk 程序员之前,我是一位 APL 程序员,这也是一个可以修改虚拟机镜像的世界,其中开发和部署是无法区分的。因此,我相信,当前的世界,人们编辑单独的源代码文件,然后运行构建管道以创建在编辑代码时不存在的部署工作,然后将这些作品部署到用户。我们已经以某种方式将这种反模式软件开发制度化,并且不断发展的软件环境的需求正在迫使我们找到回到 20 世纪 90 年代更有效的技术的方法。因此会有 Docker 的成功。因此,我需要提出建议。
我有两个建议:我们在运行时系统中实现(和使用)版本控制,我们通过更改运行系统来开发软件,而不是用新的运行系统替换它们。这两个想法是相关的。为了安全地更改正在运行的系统,我们需要一些版本控制功能来支持“撤消”功能。也许公平地说,我只提出一个建议。让我举例来说明。
@ -29,9 +28,9 @@ Smalltalk 构建于虚拟机包含了你的开发环境IDE、调试器、文
一种可能性是,诸如版本控制系统的工具不被设计为在生产环境中使用。例如,给某人许可推送到测试分支而不是生产分支是不可能的。对这个方案最常见的反对是,如果发现了一个漏洞,你会想要将某些提交标记为不可访问。这将是另一种更细粒度的权限的情况;开发人员将具有对所有提交的读取权限但外部用户不会。我们可能需要对现有工具进行一些额外的工作以支持这种模式但是这些功能很容易理解并已被设计到其他软件中。例如Linux (或 PostgreSQL实现了对不同用户的细粒度权限的想法。
随着云环境变得越来越普及这些想法变得更加相关云总是在运行。例如我们可以看到AWS 中等价的 “文件系统”S3实现了版本控制所以你可能有一个不同的想法使用一台 web 服务器提供来自 S3 的资产,并使用会话信息选择不同版本的资产。重要的想法并不是实现是最好的,而是支持运行时版本控制的愿
随着云环境变得越来越普及这些想法变得更加相关云总是在运行。例如我们可以看到AWS 中等价的 “文件系统”S3实现了版本控制所以你可能有一个不同的想法使用一台 web 服务器提供来自 S3 的资产,并使用会话信息选择不同版本的资产。重要的想法并不是实现是最好的,而是支持运行时版本控制的愿
部署的软件环境应该是“版本感知”的原则扩展到除了服务静态资产的web服务器之外的其他工具。在将来的文章中我将介绍版本库数据库和应用程序服务器的方法。
部署的软件环境应该是“版本感知”的原则扩展到除了服务静态资产的web服务器之外的其他工具。在将来的文章中我将介绍版本库数据库和应用程序服务器的方法。
_在 linux.conf.au 中了解更多 Robert Lefkowitz 2017 年 [lca2017][1])在 Hobart[保持 Linux 伟大][2]的主题。_
@ -49,7 +48,7 @@ via: https://opensource.com/article/17/1/difference-between-development-deployme
作者:[Robert M. Lefkowitz][a]
译者:[geekpi](https://github.com/geekpi)
校对:[校对者ID](https://github.com/校对者ID)
校对:[Bestony](https://github.com/Bestony)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译,[Linux中国](https://linux.cn/) 荣誉推出