目录

Web 应用程序的开发环境
开发中的服务器
开发服务器上容易出现的问题
1：如何在每个开发者的机器上搭建服务器
2：如何单独搭建开发服务器
3：如何按照接口/标准限制影响范围
各方法组合使用
概括

Web 应用程序的开发环境

开发环境中包含各种元素。例如集成开发环境（IDE）、编辑器、编译器、代码格式化（formatting）和解析等与编码工作直接相关的工具和测试工具、任务运行器、源代码版本控制等外围工具，甚至bugs。/ 内容丰富，如问题跟踪和数据库等运维工具。

如果把这些都处理好，考虑的东西就会非常多，所以在本文中，我们将重点放在开发时的服务器区域，这也与负责运营方（Ops）的区域重叠。

开发中的服务器

在开发Web应用程序时，需要一个服务器来检查运行情况。
首先，我认为通常是检查手头机器上的操作或内部设置的开发服务器然后将其投入生产的流程。

如果您想在您的机器上检查正在开发的 web 应用程序的运行情况，您可以在您的机器上安装 web 服务器，或者由编程语言和框架（和外围工具）（例如 Ruby on Rails）提供的 web 服务器。在这种情况下，您将使用由“rails server”命令启动的开发服务器（development server）。

开发服务器上容易出现的问题

这里的一个常见问题是它在开发环境中有效，但在生产环境中无效。由于开发服务器和生产服务器的设置不同，使用的数据不同，行为的不同（例如，在生产环境中使用编译的资产（JS/CSS/图像等）等），它不起作用正如在生产环境中所预期的那样。

理想情况下，最好在最终运行 Web 应用程序的生产服务器本身上检查操作，或者在与生产环境条件几乎相同的服务器上检查操作，但由于以下各种原因，通常很难。让我们做吧。

• 我不想影响已经运行的应用程序和生产环境的数据
• 我不想将仅在开发过程中需要的资源投入生产
• 出于安全考虑，我们限制了可以访问生产环境的用户。
• 准备一个相当于生产环境的环境需要花钱
• 生产环境和手头机器在网络上是相互分离的，手头机器上的变化反映需要时间。

因此，需要在考虑应用的特点、与后续流程的平衡等各方面的权衡后，搭建一个不同于生产环境的服务器环境。具体而言，以下项目是要考虑权衡的要点。

• 环境建设和变更申请手续简便
• 应用更改的速度
• 安全
• 安全生产环境稳定运行
• 成本

下面，我们将介绍三种具体的方法。其实，不是只使用其中一种方法，我认为它会根据应用程序的特点和组织的要求组合/调整使用，因此将每种方法组合使用。我还将解释案例做。

1：如何在每个开发者的机器上搭建服务器

这是一种在每个开发人员的机器上安装 Web 服务器或构建虚拟环境的方法。
不需要准备单独的服务器，但您需要允许您在自己的机器上运行 Web 服务器或虚拟环境的规范。您还需要考虑在自己的机器上构建环境的工作量。

为了尽可能消除与生产环境的差异，需要注意以下几点。

• 接近生产环境的设置，最好是相同的设置
• 明确环境搭建流程，方便部署到每个成员
• 改变环境时通知成员

通过使 Web 服务器/应用程序服务器和中间件的类型、版本和设置尽可能与生产环境相似，可以减少麻烦。
但是，可能存在无法准备与生产环境相同的设置的情况，例如您只能在开发环境中准备测试证书时，或者当生产环境是另一个大型系统的子系统时。在这种情况下，请考虑您的环境中的实际下降点，例如允许对不容易影响应用程序操作的部分进行差异。

一种可以更轻松地部署首选项的工具

有多种方法可以将服务器首选项部署到每个成员。
还有一种方法是编写程序手册，每个成员根据程序手册构建环境，但是如果手动完成，可能会出现忘记更新程序手册或遗漏应用程序等人为错误。

配置工具的使用

因此，如果您将其设为可执行脚本或使用配置工具，则部署环境会更容易。

著名的配置工具包括 Puppet、Chef 和 A​​nsible。

* 置备工具将在下一篇和后续文章中详细介绍。

使用provisioning工具时，只能通过工具更改服务器等的设置，团队内部原则上禁止手动更改设置，以便更改每个开发人员之间的环境。在某些情况下，可能会有必要想办法减少这种差异。

虚拟环境

开发环境可能与操作系统不同，如Windows，生产环境可能是Linux。如果它与操作系统不同，则单独的配置工具可能无法吸收服务器设置的差异。

在这种情况下，使用 VirtualBox、Hyper-V 和 KVM 等可以构建虚拟环境的工具也是一个好主意。在虚拟环境中创建一台 Linux 机器并使用配置工具设置环境。

Vagrant 是一种使虚拟环境更易于使用的工具。vagrant 是一个工具，允许您创建虚拟机，使用配置工具设置环境，在开发机器和虚拟机之间交换文件，以及从命令行执行到虚拟机的端口转发。

通过使用这些工具，可以构建具有真实工作量的虚拟环境。

部署时的注意事项

在使用 Ansible 和 vagrant 等工具时，还需要想办法让工具的配置文件在成员之间更容易扩展。例如，您可以在应用程序源中包含该工具的配置文件，并将其放在版本控制系统（例如 git）上。另一种选择是将其与版本控制系统或 CI/CD 机制链接，以便在进行更改时通知每个成员。

2：如何单独搭建开发服务器

这是一种通过使用内部服务器或托管/云来准备与生产服务器分开的开发服务器的方法。单独构建服务器的成本很高，但是当您想准备一个即使开发人员不在也能工作的服务器时，或者当您想为客户提供一个用于检查操作的临时环境时，它是有效的。

为了处理生产环境和开发服务器之间的环境设置差异，需要像在每个开发人员的机器上构建服务器的情况一样使用配置工具进行设计。

你可以单独购买一台机器，搭建虚拟环境，通过签约VPS等方式保护服务器，也可以仅在必要时使用云来搭建服务器。

比如在云端，可以使用API​​来自动化服务器等资源的操作，所以一旦在GitHub上创建了Pull Request，就可以用来搭建服务器进行操作检查。

3：如何按照接口/标准限制影响范围

到目前为止，方法是搭建一个接近生产环境的服务器环境，包括Web服务器和中间件，但也有一种方法，通过根据特定的开发环境，在一定程度上保证在生产环境中的运行。接口/标准。

接口/标准的一个例子是 Python 中的 WSGI。WSGI 是一种用于连接 Web 服务器和 Web 应用程序的规范，并定义了如何交换请求/响应。任何兼容 WSGI 的 Web 应用程序也可以在兼容 WSGI 的 Web 服务器上运行。

除了 Python 之外，还有 Rack for Ruby 和 Java EE for Java，通过制作符合这些规范的 Web 应用程序（和框架），在任何也符合这些规范的基础设施上，您可以在 Java 中运行该应用程序。

在开发时，通过使用符合这个接口/标准的开发服务器（rails server, rucksack 等，用于 ruby​​），您可以在不知道诸如 Web server 等接口/标准之外的配置等细节的情况下工作开发者的一种方法是限制责任范围。

另外，近年来，能够将应用+执行环境打包成容器的“Docker”也开始流行。Docker 还有一个方面，就是可以根据接口/标准来限制开发者应该注意的范围。通过使用 Dockerfile 将用于构建和运行应用程序的环境打包为 Docker 映像，开发人员可以在不了解运行 Docker 容器的基础架构细节的情况下工作。运维端可以专注于运行Docker容器，可以在不了解应用实现细节的情况下工作。

各方法组合使用

如上所述，在构建实际开发环境时，会在考虑成本、速度、工作量等因素后组合使用这些方法。

<组合示例>

• 正常开发，使用你机器的开发服务器（rails server等）
• 在签入版本控制系统时使用虚拟环境或 Docker（在接近生产环境中）进行测试
• 接收评论时使用单独的开发服务器
• 审核通过后，通过CI/CD部署到staging环境

考虑每个人的环境、约束、应用特点等，考虑合适的方法。

概括