网站部署：让我们数数有多少种方法！

部署是指将网站从本地环境迁移到实时服务器的过程。看似简单的事情实际上可能非常复杂。实现部署的方式有很多。它们范围从用户友好的软件和服务，到更复杂的命令行工具，再到具有许多移动部件的完整系统。

我不是这方面所有内容的专家，但我在日常工作中也设置了一些不同的部署系统，并使用过许多不同的系统。我认为我们可以尝试在这里尽可能多地收集和分解它们。

直接操作

如果您直接在服务器上编辑文件，那么您基本上根本没有部署步骤。您可以使用支持 FTP 的编辑器（如 Coda 或 Adobe Dreamweaver）来实现这一点。很多人这样做，因此像 Media Temple 这样受欢迎的主机甚至有关于 设置 的文档。

您甚至可以使用类似 WebDAV 的工具将 远程服务器挂载为本地硬盘，并使用您喜欢的任何本地编辑器。Transmit 具有一个 “磁盘”功能，使这变得非常容易。

这里吸引力很强，因为您可以快速获得实时结果。但是，通常不建议这样做。因为

• 这很危险，人们会立即看到错误
• 没有测试
• 没有更改记录 - 什么/谁/何时
• 您无法撤消更改
• 在团队中，您可以覆盖其他人的工作
• 如果没有额外的设置，您无法处理大型、长期项目

手动使用 FTP

一种非常原始的部署技术是，简单地在本地工作，并在准备好后，使用 FTP 软件（如 Transmit）将文件移动到实时服务器。

虽然这种方法有效，但可能会很繁琐。我修改了哪些文件？哦，算了，我直接移动所有文件。天啊，这太慢了。

这仍然存在与上面许多相同的缺点。您仍然有覆盖他人工作的风险，您仍然无法轻松地撤消更改，等等。

以这种方式使用 FTP 并不自动意味着您没有使用版本控制，但可能性很大。如果您使用了版本控制，您将完全独立地管理它，并且会感觉格外繁琐。而且，仍然没有任何东西可以防止您犯错（例如，在从存储库拉取之前将文件发送到 FTP）。如果您正在使用版本控制，您可能已经在寻找一种将其与部署结合起来的方法。

版本控制部分

版本控制非常重要，并且将在我们讨论的每个其他部署事物中发挥作用。但是，版本控制本身并不会自动为您处理部署。在不进行过多详细说明的情况下，项目保存在存储库（或“存储库”）中。它们可以有多个贡献者。文件保持同步。贡献者的工作是确保他们拥有最新的代码，以及他们的新代码是否合适。所有更改都有记录。

Git 可能是最常见的版本控制工具，但请注意 Subversion（“SVN”）和 Mercurial 类似，并且发挥相同的作用。

在服务器上安装版本控制，并从此处拉取

版本控制软件就是这样，软件。您购买的服务器上可能没有标准配置（即使是那些通常自动包含 PHP 等内容的“完全加载”服务器）。但是，您也可能能够在这些服务器上安装它。

然后，就像您可以从本地机器执行git push和git pull一样，您也可以 SSH 到服务器并从那里执行git pull，这会将最新文件从该存储库下载到实时服务器上。

这就是简单的部署。

Jeremy Harris 有一篇文章对此进行了扩展，向您展示了如何从本地机器推送并将.git 目录保留在 Web 根目录之外。Joe Maller 有一篇文章介绍了在服务器上使用“Hub”区域。

Cron 作业

Cron 作业是服务器上的定时/自动任务。每 2 分钟运行一次 X。我见过有人运行一个 Cron 作业，每隔几分钟执行一次 git pull，这就是他们的部署策略。

接收后钩子/Webhook

GitHub 有一项名为 接收后钩子 的功能，当存储库已推送到其中时，它会将 POST 请求发送到您选择的 URL。您可以使用该 POST 请求运行一个脚本，该脚本将运行部署所需的命令，例如git pull。

NetTuts 有一篇文章 “完美的工作流程” 解释了如何设置此功能。他们使用了运行 SSH 命令的 PHP 文件，但根据我的经验，许多主机都将其锁定，甚至没有允许的选项。

Bitbucket（另一个版本控制主机）也具有 POST 服务管理。

第三方部署 Web 服务

有一些 Web 应用程序已将其业务定位于帮助部署。

Atlassian 制作 BitBucket（版本控制）和 Jira（问题管理），因此他们制作 Bamboo（执行部署并某种程度上将这些产品联系在一起）也就不足为奇了。

命令行界面 (CLI) 工具

一种花哨的说法是：通过在终端中键入命令来工作的工具。它们通常具有配置，您可以通过命令本身传递配置，使用配置文件，或者两者兼而有之。

Capistrano

Capistrano 并非严格意义上的部署工具。它用于在服务器上执行命令。尽管部署是它的一个非常常见的用途，并且它也起源于此。

Capistrano 最初旨在简化和自动化 Web 应用到分布式环境的部署，并且最初捆绑了一套用于部署 Rails 应用的任务。

它使用 Ruby 编写，但可以用于任何用途。

随着网站变得越来越复杂，仅仅从中央仓库拉取代码可能无法满足需求。例如，可能涉及多个服务器。或者拉取这些文件可能需要一些时间，而这段中间时间可能会破坏你的应用。使用 Capistrano，你可以将其配置为准备服务器，将新文件拉取到新位置，更新指向最新版本的 符号链接，清理权限，重启服务，并在多个服务器上执行所有这些操作。 此图 演示了这一点。

它曾经有一个 Web UI，但看起来有点过时了。

RailsCasts 有 一系列屏幕录制 来帮助你学习 Capistrano。

rsync

rsync 专门用于文件传输。

rsync 是一个用于 Unix 系统的文件传输程序。rsync 使用“rsync 算法”，该算法提供了一种非常快速的文件同步方法。它通过仅发送文件中的差异来实现这一点，而无需事先在链接的两端都存在这两组文件。

rsync 是一个命令，因此它通常由任务运行器（如 Make）运行，或者更常见的是 Rake，因为它也是用 Ruby 编写的。

git-ftp

也许你已经察觉到一个反复出现的主题了。

我没有传输整个项目，而是想，为什么不只传输自上次以来更改的文件呢？Git 可以告诉我这些文件。

git-ftp 将文件推送到你的服务器，就像任何 FTP 客户端一样，但它确切地知道要发送哪些文件，因为它使用了 Git，而 Git 知道这些信息。

git ftp push -u <user> -p - ftp://host.example.com/public_html

Dandelion

Dandelion 类似于 git-ftp，但它从配置文件中工作，因此你可以更具体地指定你希望发生的事情并简化命令（dandelion deploy）。它还可以推送到 AWS。

Ansible

Ansible:

Ansible 配置操作系统、部署应用程序、运行并行命令并编排 IT 流程（如零停机滚动更新）。它默认使用 SSH，因此无需安装任何特殊软件即可开始管理远程机器。模块可以用任何语言编写。

grunt-ftp-deploy

就构建工具/任务运行器而言，Grunt 正在努力成为王者。它使用 Node.js 编写，Node.js 有自己的包管理器（NPM），类似于 Ruby Gems。

其中一个页面是 grunt-ftp-deploy，它通过 FTP 将文件从你的本地机器移动到服务器。你可以配置任务，然后以你喜欢的任何方式运行 Grunt 任务。这是一个相当“愚蠢”的任务，因为它甚至没有尝试只移动已更改的内容或引用版本控制。它只是移动所有内容。

Static Sites

“静态”网站是指不需要任何服务、数据库或其他任何东西的网站。只需要一个 Web 服务器和一堆资源文件（例如 .html、.css、.js、图片）。

GitHub Pages

GitHub 提供了一项名为 GitHub Pages 的服务，该服务可以很乐意为你提供静态网站服务。你甚至可以 使用自己的域名 与它们一起使用。你只需创建一个名为 gh-pages 的仓库的分支，它就会自动生效。这样，部署就简单地变成了推送到该仓库的该分支。

有一个 grunt 任务 专门用于此。

Jekyll

仅仅因为一个网站是静态的并不意味着它很糟糕/简单/架构很差。有一些静态网站的构建工具允许你将模板和内容组合在一起并输出一个网站。 Jekyll 就是其中之一，它专门为与 GitHub Pages 协同工作而构建。

Octopress

Octopress 建立在 Jekyll 之上，提供了配置、模板等，以便你能够更快地上手。

Jekyll 和 Octopress 本身并不一定帮助部署，它们只是与 GitHub Pages 关系密切，而 GitHub Pages 是一种部署形式。

Amazon S3

亚马逊提供 Web 服务，你实际上可以在其中 运行服务器，但它也提供 S3，它只是一个简单的文件存储服务。你实际上可以在 S3 上 托管静态网站，甚至可以使用自己的域名。

甚至有一组名为 s3cmd 的命令行工具，你可以对其进行配置并运行命令以部署静态网站（即 s3cmd sync）。

Platform as a Service (PaaS)

希望现在已经很清楚了，仅仅部署本身就可以很复杂。整个 Web 平台堆栈可能非常复杂。难怪一些公司已经开始提供服务来简化它。这些公司提供托管、服务器管理、数据库以及所有这些东西。简单的部署通常是软件包的一部分。

企业级平台即服务（PaaS）有很多。看看SalesForce、RedHat和IBM，这只是冰山一角。

另一方面，Mixture.io可以直接从其桌面开发工具进行托管/部署。

持续集成服务器

来自维基百科

持续集成（CI）是在软件工程中，每天多次将所有开发人员的工作副本合并到共享主干的做法。

其理念是，单个开发人员不会长时间检出分支，以至于它与主仓库有很大差异，并且合并两者变得困难。

将此概念扩展到服务器意味着在实际服务器上运行该代码以确保一切正常。运行构建 - 它是否通过？运行您的测试 - 它们是否通过？经常这样做意味着尽早发现问题，并且永远不会出现巨大的深层问题。

这与部署相关，因为人们使用它们在所有步骤都通过时自动部署代码。例如：例如：

1. 提交/推送新代码到仓库
2. CI工具运行您配置的所有构建/测试
3. 如果通过，则进行部署
4. 如果未通过，则会通知您，并且不会进行部署

我实际上几乎不理解所有这些，因此如果您有任何错误，请在评论中更正我。有很多不同的工具，因此我不会尝试解释我做得很不好的事情，我只会列出它们

• Travis CI（自然适用于GitHub）
• Jenkins CI（可以与GitHub一起使用）
• CircleCI
• Codeship

CMS 特定

如今，CMS 拥有如此庞大的社区，因此出现特定于它们而非仅特定于其父语言的工具也就不足为奇了。

WordPress

• WP-Stack 是 WordPress 网站的样板，假设使用 Git 和 Capistrano。
• WordPress-Starter 类似，但包含 S3 备份
• 我们没有过多讨论数据库部署。我不确定关于它还有什么可说的。我一直对数据库迁移的笨拙感到惊讶。WP Migrate DB Pro 是一个特定于 WordPress 的好工具，用于保持它们同步。

Drupal

Drupal 有一个名为 Drush 的命令行界面，它有一个名为 Drush Deploy 的部署脚本。

就这么多了吗？

不，可能还没有。我甚至没有提到像 Puppet 和 Salt Stack 这样的东西，我甚至不太理解它们。

欢迎在评论中添加任何其他信息、我出错的地方、我遗漏的地方或您如何进行部署。