翻译自:https://blog.risingstack.com/continuous-deployment-of-node-js-applications/css
持续部署是...
不,让咱们退一步来看持续集成、持续交付、持续部署的区别。html
持续集成是一天屡次/持续地把开发的成果和主分支合并到一块儿的过程。有助于:前端
大部分工做是靠自动测试完成的。node
持续交付是只将代码部署到一个能够被QA团队或者客户审查的环境。当改动被批准,他们才能够被部署到生产环境。git
你能够把持续部署当作是持续交付的下一步。在这一步,传递到自动测试的变动会被自动地部署到生产环境。持续部署很是依赖于某些基础设施,这些基础设施将测试、集成、部署新功能的过程自动化。
在这篇文章里,咱们将梳理这些自动化步骤、讲述大部分的原则。
一个简化的持续部署工做流以下:
github
假设咱们要作这样一件事,当一个新的功能将要被开发出来而且咱们想看到它运行在生产环境。咱们要看一下这个代码变动从提交到在生产环境运行起来的所有声明周期。docker
每次将代码提交到主分支,都应该触发一个包含测试的新构建。可是当添加新的功能时,你不会想在生产环境中看到半成品的功能。npm
为了解决这个问题,持续部署的建立通常伴随着功能开关。功能开关是指一个切换功能,能够容许开发者发布包含未完成内容的产品版本。这些未完成的功能会被生产环境中的开关隐藏起来。浏览器
// 用一个伪造的例子来说述风格切换 // https://www.npmjs.org/package/feature-toggles var featureToggles = require('feature-toggles'); // 定义切换 var toggles = { foo: true, bar: false }; // 把它们加载到模块中 featureToggles.load(toggles); // 检查某个功能是否被开启 if (featureToggles.isFeatureEnabled('foo')) { // do something }
当这个功能已经完成,这个功能开关能够被移除。服务器
可是在哪触发一个新的构建呢?针对这个例子,你须要一个持续集成工具。已经有不少现成的工具,如 Jenkins、Travis、Codeship、Strider,其中Strider是用Node.js编写的,Jenkins和Strider是开源的,能够在你的基础设施上进行操做。
当前,咱们在闭源项目使用Strider,开源项目使用Travis。
上述每一个工具都支持提交钩子,因此如今就建立一个吧!如此一来,你的持续集成工具不用像日常同样拉取代码。
当你选的工具收到了一个新的提交通知,它会启动一个新的构建。构建能够包含不少步骤,有些能够同时运行。说到Node.js应用,将经历以下步骤:
自动化测试是构建步骤中最关键的部分。
你的模块必须被单元测试覆盖,你也须要有集成测试来检查各部分可否协同工做。对于这类测试,你可使用mocha/tap/Jasmine和断言库,如chai.
基于你构建的应用是包含前端的仍是只有API,你能够选择不一样的端到端测试工具。
若是你的程序没有前端页面,只有API,你能够用hippie或supertest作端到端的测试。
当开发包含前端页面的程序时,你还能够对用户界面进行测试。使用Protractor来测试AngularJS程序或者使用Nightwatch。为了确保程序在全部支持的浏览器中运行,须要在Selenium集群上运行端到端测试。也可使用Sauce Labs或者 Browserstack 服务。
我要不断地强调这件事:没有足够的测试覆盖率,持续集成将致使一系列的生产问题。
若是全部的测试都已经经过,那么就能够从构建打包了。发布包必须包含运行应用程序的每一个文件。因此你的成产服务不用再进行从新构建。
一个简单的tar filename.tar *
能够作这件事。而后确保文件位置能够被生产服务器访问,这样你才能获取到它。如AWS的S3或者任何的其它存储。
因为咱们刚建立的发布包包含程序全部的静态资源,咱们只须要进行以下操做:
毫无疑问,这些步骤必须自动化,无需任何手动操做。像Ansible、Chef或者Puppet能够帮忙。
若是发生了错误,迟早会发生。确保有一个回滚的脚本。最快、最简单的方式是将symlink指向到前一个构建并重启node应用。
推荐阅读:
具备可操做性的运行Node.js的建议。