在这篇文章中，我将向您展示如何管理依赖项以及使用Gulp构建前端应用程序，并将其安全地部署到服务器。
前端部署不再那么简单了
回想过去，一切都很简单：你只需将HTML上传到服务器，可能还带有一些(严重)压缩的图片，现在，大多数Web应用程序都需要在部署之前构建。该过程通常类似以下步骤：
- 首先，您得获取依赖项(npm、Composer、Yarn、Bower)
- 然后，连接并最小化资产、样式和脚本等。(Gulp、Grunt、Webpack、Babel)
列出的所有工具使项目工作更容易：控制依赖项，提高应用程序性能，从而提供更好的代码、优化和排错。
然而，在开发过程中有个事情可能会失控，那就是：部署！
正如我们以上所说，之前您只要将文件上传到服务器，OK，发布就搞定了！一些开发人员认为，他们如今依然想通过将依赖项(vendor、node_nodules等)和编译后的资产保存在存储仓/仓库中来保持这种简单性。如果您是这些开发人员之一并有这种想法，请千万不要这样做。这些东西是不应该放到您的存储仓/仓库之中！
永远不要将依赖项和编译过的工件放置于存储仓
- 具有依赖项和工件的存储仓正在快速增长。Git不是为处理大文件而设计的，文件越大，性能就越差。
- 如果您将工件存储在存储仓中，则需要记住在每次提交之前编译应用程序，以便可以将更改的工件与对源代码的更改一起提交。这是非常不理智的，因为如果您忘记更新存储仓中的工件，将应用程序部署到生产服务器可能会导致严重问题。
- 用于编译、最小化和连接文件的任务可能会产生不同的结果：就有如团队中开发人员使用不同版本的Node.js。将此类文件提交到存储仓将引发需要手动解决的持续冲突，这将使得分支合并变得非常麻烦。
- 在Node.js版本X中编译的应用程序可能无法在版本Y中正常工作 – 这是另一个人为因素问题，这使得很难100%确定生成的工件与生产服务器上的Node版本兼容。
部署包含更多步骤
好！既然我们知道将工件和依赖项保留在存储仓中不是一个好办法，那么问题是：我们应该如何将应用程序部署到服务器？如果没有持续部署工具，它通常类似以下步骤所示：
- 应用程序通过SFTP/SCP或Git上传到服务器，并使用脚本构建，该脚本将下载依赖项并直接在服务器上运行任务。
- 如果SSH访问不可用(例如，服务器是FTP)，则必须在部署之前在兼容的环境中构建应用程序。
永远不要手动部署
前面提到的人为因素增加了发布所耗的时间长度。更糟糕的是，它可能会产生很难发现和诊断的错误。
总而言之，整个部署过程应简化为单个操作:
- 使用一个可以在终端运行命令的修订版参数化脚本
- 使用一个可让您自动执行该过程的工具或应用程序
如何使用Buddy部署前端应用程序
在本文此部分中，我将向您展示如何在5分钟内创建一个交付流水线，该流水线将自动获取依赖项并运行Gulp任务。
注册并免费使用Buddy
访问Buddy网站https://buddy.red 并使用您的GitHub/Bitbucket帐户或工作电子邮件进行注册
如果您使用电子邮件地址进行Buddy帐户注册，请使用您的工作邮箱，例如，带您的企业网址域名邮箱或您所在企业的域名邮箱。Buddy暂不开放一般免费电子邮件地址。
选择您的Git托管与存储仓/仓库
Buddy支持GitHub、Bitbucket、GitLab或者其他任何私有或开源的Git存储仓，您还可以使用具有合并请求和分支权限的Buddy自带全功能Git托管。
创建一个交付流水线
设置您想要部署的分支并配置触发模式: 事件(自动触发)、手动(点击触发)或定时(设定时间间隔触发)。
添加构建操作
为将提取依赖项并生成应用程序的项目类型选择生成操作。在此例中，我将下载Node模块并运行Gulp任务，因此选择Node.js操作：
提供应用程序的构建命令并选择Node版本：
请确保保存更改以将操作添加至流水线：
添加部署操作
应用程序已生成并准备好上传到服务器。Buddy允许您在几乎任何地方、任何方式部署代码：
在此，我们将选择SFTP作为示例。单击该操作后，系统将提示您选择要从何处部署文件。确保选择文件系统，因为它包含上一步中构建的应用程序：
提供您的服务器访问信息于传输目标，您可根据所需提供相关的服务器IP地址、用户名、密码等相关信息，您也可以提供SSH密钥信息对部署目标进行配置。为了更好地保护您的相关服务的敏感信息，您也可以通过环境变量的方式对敏感数据进行加密保护。
添加通知操作
最后，最好添加一个通知操作，让我们随时了解已完成的部署：
如果使用任务管理器运行测试，还可以添加条件通知，以便在测试失败时向您发送消息:
万事俱备！现在，推送到触发分支，并查看Buddy流水线它将自动构建和部署您的应用程序。
标签：存储,Buddy,运维,部署,前端,应用程序,构建,自动化,服务器 From： https://www.cnblogs.com/code313/p/frontend-deployment.html