travis-ci自动部署

by Amir Off

由Amir Off

如何使用Travis CI设置高级自动部署 (How to set up advanced automatic deployment with Travis CI)

This post is a sequel to my previous Advanced Web Development and Deployment Workflow tutorial. In that tutorial, I showed how I automated my development and deployment workflow. A lot has changed since then due to the rapid development of web tools and technologies — and of course due to my need to improve my workflow as a web developer.

这篇文章是我以前的Advanced Web Development and Deployment Workflow教程的续篇。 在该教程中，我展示了如何自动化开发和部署工作流。 此后，由于Web工具和技术的飞速发展，而且由于我需要改善作为Web开发人员的工作流程，因此发生了许多变化。

我的用例 (My Use Case)

I use a shared hosting service for my personal portfolio website and most of the code is comprised of front-end static assets:

我为个人投资组合网站使用共享托管服务，并且大部分代码由前端静态资产组成：

In the past, I had to run a Gulp.js task to minify, uglify and process all of the source code. It outputs it in a bundle folder along with the index.html file that is ready to be deployed to my hosting service via FTP.

过去 ，我必须运行Gulp.js任务来缩小，丑化和处理所有源代码。 它将它与index.html文件一起输出到捆绑文件夹中，该文件可以通过FTP部署到我的托管服务中。

To automate the process, I used DeployBot. It is a service which allows you to use your existing repositories and deploy to a number of locations like FTP, SFTP, Amazon etc.

为了自动化该过程，我使用了DeployBot 。 它是一项服务，允许您使用现有的存储库并部署到许多位置，例如FTP，SFTP，Amazon等。

Where DeployBot falls short for me is that it only operates like a tunnel that deploys my GitHub repository whenever a change was committed to the repository. This meant that it would require me to upload my bundled code to a separate branch — I called it “deployment” in my case — and it uploaded all the files from that branch to the hosting server via FTP.

DeployBot对我而言不足之处在于，它仅像隧道一样运行，每当将更改提交到GitHub存储库时，它就会部署我的GitHub存储库。 这意味着需要我将捆绑的代码上传到一个单独的分支(在我的情况下称为“部署”)，并且它将所有文件从该分支通过FTP上传到托管服务器。

I saw this as a bad practice and a temporary comfort solution. My code on GitHub should a be “source” code and not a bunch of minified and uglified JavaScript and CSS assets and other processed files.

我认为这是一种不好的做法，是一种暂时的舒适解决方案。 我在GitHub上的代码应该是“源代码”，而不是一堆精简JavaScript和CSS资产以及其他处理的文件。

解决方案 (The Solution)

To eliminate the problem I had with DeployBot, I had to ditch it for Travis CI — a continuous integration and delivery service that integrates with GitHub. This way I was able to remove the “deployment” branch that I had in my repository and let Travis CI do all the work of running the Gulp.js tasks for me and further deploy it to my hosting server via FTP. All I had to do was push my source code and Travis CI would do the rest. No more running the Gulp.js tasks manually then checking out the “deployment” branch and pushing it manually to Github.

为了消除DeployBot带来的问题，我不得不放弃Travis CI，它是与GitHub集成的持续集成和交付服务。 这样，我可以删除存储库中的“ deployment”分支，并让Travis CI为我完成所有运行Gulp.js任务的工作，然后通过FTP将其进一步部署到我的托管服务器上。 我所要做的就是推送我的源代码，而Travis CI将完成其余的工作。 不再需要手动运行Gulp.js任务，而是检出“ deployment”分支并将其手动推送到Github。

In the code below I am defining the script file “.travis.yml” that is required for Travis CI to run:

在下面的代码中，我定义了Travis CI运行所需的脚本文件“ .travis.yml ”：

? At line 18 the FTP credentials are extracted from Travis CI

？ 第18行，从Travis CI提取FTP凭证

This is a great feature since it allows me to set protected environment variables, the FTP login credentials “$FTP_USER” and “$FTP_PASSWORD” in this case. These variables are encrypted and embedded in the “.travis.yml” script file at runtime. This way I can commit my source code to GitHub without exposing any sensitive data.

这是一个很棒的功能，因为它允许我设置受保护的环境变量，即FTP登录凭据“ $ FTP_USER ” 在这种情况下为“ $ FTP_PASSWORD ”。 这些变量在运行时被加密并嵌入到“ .travis.yml ”脚本文件中。 这样，我可以将源代码提交到GitHub，而不会暴露任何敏感数据。

For them to work I had to use a package called vinyl-ftp. It’s described as,

为了让他们工作，我必须使用一个名为Vinyl-ftp的软件包。 它被描述为

A vinyl adapter for FTP. Supports parallel transfers, conditional transfers, buffered or streamed files, and more. Often performs better than your favorite desktop FTP client.

用于FTP的乙烯基适配器。 支持并行传输，条件传输，缓冲或流式文件等等。 通常，性能要比您喜欢的台式机FTP客户端好。

? At line 9 and 10, the deploy task parses the user and password from the argument options that the Travis CI script runs:

？ 在第9和10行，部署任务从Travis CI脚本运行的参数选项中解析用户和密码：

$ gulp deploy --user $FTP_USER --password $FTP_PASSWORD

I had to install another popular npm package called minimist to be able to parse the “user” and “password ” arguments like in the CLI above.

我必须安装另一个名为minimist的流行npm软件包，才能像上面的CLI一样解析“ user”和“ password”自变量。

In addition to installing the previous two npm packages, I had to refactor my Gulp.js tasks file to allow me to run a development build so that I could work on code locally. Continuous production deployment is great, but I still wanted to be able to run my code locally and still have an actual development environment with an actual development build. ?

除了安装前两个npm软件包之外，我还必须重构Gulp.js任务文件，以允许我运行开发版本，以便可以在本地处理代码。 持续的生产部署很棒，但是我仍然希望能够在本地运行我的代码，并且仍然拥有一个具有实际开发版本的实际开发环境。 ？

? At line 2, I check for build arguments then run the build task accordingly.

？ 在第2行中，我检查了构建参数，然后相应地运行了构建任务。

If the task detects the “prod” argument like in the Travis CI build script:

如果任务在Travis CI构建脚本中检测到“ prod ”参数，则：

$ gulp build --prod

it skips the development task which is designed for local development builds and runs the production task instead.

它跳过了专为本地开发构建而设计的开发任务，而是运行生产任务。

Executing the build without the “prod” argument will trigger the development task that watches for file changes and reloads the page —very much like any development environment.

在没有“ prod ”参数的情况下执行构建将触发开发任务，该任务监视文件更改并重新加载页面，这与任何开发环境都非常相似。

$ gulp build

结论 (Conclusion)

No more switching between branches and manually copying and pushing bundled assets to GitHub. I can just work locally and push to GitHub and Travis CI takes care of the rest.

无需在分支之间进行切换，也无需手动将捆绑的资产复制并推送到GitHub。 我可以在本地工作，然后推送到GitHub，其余部分由Travis CI负责。

I hope you enjoyed reading! Please follow and share for more tech stuff ??

希望您喜欢阅读！ 请关注 并分享更多的技术资料？

翻译自: https://www.freecodecamp.org/news/advanced-automatic-deployment-with-travis-ci-1da32f7930ce/

travis-ci自动部署