使用 Deploybot 部署到 Live 和 Staging

如果您从事 Web 开发已经有一段时间了，那么您可能在尝试更新站点时搞砸了文件传输。 在最好的情况下，您将一堆易于识别的文件添加到目录中，然后删除它们以修复错误。 是的，这会花费你时间，而且很烦人，但不会造成任何伤害。

在最坏的情况下，您不正确地传输了一堆主题文件。 然后你必须弄清楚哪些被覆盖，哪些根本不属于，以及你将如何恢复主题的正确工作状态。

今天我们将使用 Git 和 Deploybot 来解决这个问题，以自动化您的部署过程。

什么是自动化部署？

一个基本的自动化部署有四个部分，如下图所示。

大多数开发人员只从他们的代码和服务器开始。 他们对站点的工作副本进行更改，然后通过 FTP 将这些更改直接推送到服务器。 Coda 或 Dreamweaver 等工具具有直接的 FTP 集成，因此您可以在编码环境中执行此操作。

许多开发人员采取的下一步是添加一个临时站点，这样他们就不会直接修改实时服务器。 您可以使用 VVV 或 MAMP 之类的东西来做到这一点。 这通常也意味着您正在使用像 Git 这样的版本控制系统来管理您对本地工作站点所做的更改。

添加临时站点时，也会增加复杂性。 您如何将您的代码更改从本地工作站点转移到您的客户可以看到更改的临时站点？ 是的，正如我已经说过的，您可以使用 FileZilla、Transmit 或 Forklift 之类的基本 FTP 客户端在您进行更改时移动文件，但这很容易出错，这就是自动化部署过程将为您节省大量时间的地方。

您无需获取更改的文件并将它们推送到暂存服务器，而是使用另一个系统自动检测 Git 存储库中的更改，并仅将这些更改推送到您的客户端可用于检查工作的暂存站点。

但是，这仍然使您的实时站点成为手动部署，这更加可怕，因为如果您关闭实时工作站点，这可能意味着损失真金白银。 相反，让我们假设您要将部署系统设置为自动部署到登台，然后在您准备就绪时，只需单击一下即可将系统部署到实时环境。

所以现在你有一个看起来像这样的系统。

让我们深入研究，以便向您展示我如何为与我合作的每个客户设置此部署过程。 这些是我开始一个新项目后立即采取的步骤。 在开始对客户项目进行任何其他工作之前，我始终确保我的部署过程已设置并正常工作。

如何构建你的 Git 存储库

您要做的第一个选择是，您将在哪个目录中设置您的自动部署？ 除非我的客户特别要求对他们的 WordPress 安装进行完整的源代码控制，否则我会使用 wp-content 目录来设置我的自动部署系统。 通过发出初始化 git 存储库的命令在终端中开始。

混帐初始化

现在是时候忽略您不想一直部署的文件了。 这些文件包括备份文件、图像以及许多代码编辑器添加到目录中的任何自定义项目文件。 你可以在下面看到我常用的 .gitignore 文件。

配置/app_config.yml

配置/数据库.yml

配置/*.sphinx.conf

config/s3_credentials.yml

*~

*.cache

*。日志

*.pid

时间/**/*

.DS_Store

数据库/cstore/**

分贝/狮身人面像/**

文档/API

文档/应用程序

文档/插件

文档/*.dot

覆盖率/*

db/*.sqlite3

*.tmproj

*.sw?

*.esproj

_笔记*

dwsync.xml

播客.xml

*.kpf

*上传/*

*.swp

*。主意

*.sublime-项目

*.sublime-工作区

*/node_modules/*

标签

*.bak

缓存/*

管理wp/*

亩插件/ *

dp.php

上升气流/*

语言/*

数据库.php

插件/wp-rocket/cache.json

根据需要随意添加或删除。 几乎我从事的每个项目都需要某种自定义条目来忽略某些特定于我的本地工作站点的文件，对于这些文件，暂存站点和实时站点将有自己的自定义文件，我不想覆盖这些文件。

从这里开始，是时候设置您需要让您的部署系统运行的分支了。 我使用两个主要分支。 首先是对应于我的现场生产站点的主分支。 其次，是一个我标记为 staging 的分支，它对应于我希望我的客户用来检查我们所做更改的临时站点。

当你初始化你的 Git 存储库时，你已经有了你的主分支，所以使用这个命令来添加一个暂存分支并检查它。

git checkout -b 暂存

此命令创建并签出一个新分支。 如果您是 git 新手，可以在 Git 文档中找到有关可用命令的更多信息。

现在您需要将项目推送到源代码控制系统中。 Github 和 Bitbucket 是两个流行的选择，它们都可以与我们将使用的名为 Deploybot 的自动化部署系统一起使用。 当您使用任一站点创建新存储库时，它们将为您提供进一步的指导，将您的本地存储库添加到您在 Github 或 Bitbucket 中的在线版本。

• Bitbucket 存储库设置文档
• Github 存储库设置文档

设置部署机器人

当我第一次作为开发人员从事更复杂的工作时，我的朋友 Duane 一直在向我推荐 Deploybot，而我在网上抱怨手动 FTP 部署搞砸了。 在我最终按照别人告诉我的事情做之前，我接受了很多建议，但多年来我一直是一个快乐的 Deploybot 客户。

虽然还有其他方法可以部署您的站点，但其中许多方法都涉及通过代码编辑器与 Git Webhooks 或一些自动部署配置文件进行交互。 这些其他工具有很多强大的功能，但如果您刚刚开始使用自动化部署，那么直接使用像 Deploybot 这样的工具就是开始的地方。

要开始注册 Deploybot 帐户并将 Github 或 Bitbucket 连接到您的帐户。 今天我将使用我现有的 Bitbucket 帐户。 首先将新存储库添加到您的 Deploybot 帐户。

找到要为自动部署设置的存储库后，单击页面底部标记为连接的按钮。 当 Deploybot 完成对存储库的初始化时，这会将您返回到存储库页面。 通常，这会在一两分钟内完成，因此请装满咖啡，然后回来完成部署过程的设置。

设置存储库后，单击它以转到其主页。 由于我们还没有设置 sFTP 信息，它上面会有一个大框告诉您设置服务器。 单击按钮以创建环境和服务器。

让我们从部署到我们的暂存环境开始。 因此，将您的服务器标记为登台。 选择自动部署并确保将分支设置为暂存。

完成后单击页面底部的保存按钮以移动到您的服务器配置。

在下一页上，再次将其标记为暂存服务器，并从您的站点输入您的 sFTP 信息。 如果您不确定在哪里可以找到它们，请阅读这份有用的指南。

输入您的 sFTP 信息后，您可以向下滚动到底部并保存。 然后，Deploybot 将测试您的连接，以确保您提供的信息有效。 现在是时候为站点进行初始部署以确保一切正常。 我经常将 test.txt 文件添加到部署中，作为验证部署是否正常工作的简单方法。

要开始部署到您的环境历史记录，然后单击部署。

现在，您将看到一个页面，其中包含您最后的 git 提交消息，作为您将在此部署旁边的 Deploybot 中看到的注释。 对于大的改变，我会改变它，但如果我只是改变 CSS 或一些小的东西，提交消息可以保留。 由于这是暂存，因此对我们暂存分支的每一次提交都将自动部署，这意味着您的提交消息将显示出来。 这只是我们需要手动对暂存站点进行的初始提交。

现在验证您的文件是否已发布到临时站点，我们可以设置实时部署。

对于您的实时部署，请确保您没有选择自动部署，并确保您选择主分支作为您的部署源。 当我们准备好将更改推送到我们的实时站点时，我们希望这是手动部署。

为此，您需要检查您的主分支，然后将您的更改从暂存分支合并到主分支。

您可以使用这些命令来做到这一点。

git结账大师

git 合并暂存

git push 起源大师

现在，当您转到您的 Deploybot 帐户时，您将能够手动部署您的更改，就像我们在初始部署到暂存环境时所做的那样。 对于您的实时环境，请确保您更改部署消息以适应正在推送到您的实时站点的更改。 您还应该创建站点的备份。 您可以通过访问站点上的备份导航然后创建手动备份来执行此操作。

就是这样，您已经为暂存环境和实时环境设置了自动部署系统。

其他部署注意事项

虽然这个系统对于大多数开发人员来说是向前迈出的一大步，但它并非没有问题。 最大的问题是，如果您有大量更改，您仍在等待 FTP 完成传输已更改的文件。 这可能意味着有人访问了您的网站，但并非您的网站需要运行的所有文件都存在。

对于许多客户来说，这不是问题，但如果是针对您的站点，那么您需要考虑设置一个原子部署系统。 这种类型的部署系统会移动所有文件，验证它们是否正常工作，然后更改服务器上的文件设置，以便新目录现在是运行站点的目录。

链接到新文件夹的过程需要很短的时间，只有计算机会注意到。 这也意味着如果您以后发现问题，您可以将系统链接更改回网站的旧版本，以回滚到正常工作的版本。 这又只需要很短的时间并减少停机时间。

无论您选择做什么，立即停止使用 FTP 客户端来部署您的客户端文件。 每次部署文件没有出错时，Deploybot 每月的少量成本都会得到补偿。