zoukankan      html  css  js  c++  java
  • 译Node.js应用的持续部署

    Node.js应用的持续部署

    翻译前

    翻译自:https://blog.risingstack.com/continuous-deployment-of-node-js-applications/

    正文

    持续部署是...
    不,让我们退一步来看持续集成、持续交付、持续部署的区别。

    持续集成

    持续集成是一天多次/持续地把开发的成果和主分支合并到一起的过程。有助于:

    • 尽早捕获异常
    • 防止「集成地狱」

    大部分工作是靠自动测试完成的。

    持续交付

    持续交付是只将代码部署到一个可以被QA团队或者客户审查的环境。当改动被批准,他们才可以被部署到生产环境。

    持续部署

    你可以把持续部署看成是持续交付的下一步。在这一步,传递到自动测试的变更会被自动地部署到生产环境。持续部署非常依赖于某些基础设施,这些基础设施将测试、集成、部署新功能的过程自动化。
    在这篇文章里,我们将梳理这些自动化步骤、讲述大部分的原则。
    一个简化的持续部署工作流如下:

    从源代码控制到生产环境

    假设我们要做这样一件事,当一个新的功能将要被开发出来并且我们想看到它运行在生产环境。我们要看一下这个代码变更从提交到在生产环境运行起来的全部声明周期。

    一切从一次提交开始

    每次将代码提交到主分支,都应该触发一个包含测试的新构建。但是当添加新的功能时,你不会想在生产环境中看到半成品的功能。

    功能开关

    为了解决这个问题,持续部署的创建一般伴随着功能开关。功能开关是指一个切换功能,可以允许开发者发布包含未完成内容的产品版本。这些未完成的功能会被生产环境中的开关隐藏起来。

    // 用一个伪造的例子来讲述风格切换
    // 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
    }
    

    当这个功能已经完成,这个功能开关可以被移除。

    持续部署工具

    但是在哪触发一个新的构建呢?针对这个例子,你需要一个持续集成工具。已经有很多现成的工具,如 JenkinsTravisCodeshipStrider,其中Strider是用Node.js编写的,Jenkins和Strider是开源的,可以在你的基础设施上进行操作。
    当前,我们在闭源项目使用Strider,开源项目使用Travis。
    上述每个工具都支持提交钩子,所以现在就创建一个吧!如此一来,你的持续集成工具不用像平常一样拉取代码。

    提交时构建

    当你选的工具收到了一个新的提交通知,它会启动一个新的构建。构建可以包含很多步骤,有些可以同时运行。说到Node.js应用,将经历如下步骤:

    • 从NPM安装依赖(公共的或者私有的)
    • 运行单元测试
    • 构建静态资源,如css和JavaScript
    • 运行集成测试和端到端的测试
    • 创建发布包(把node_modules文件夹也打包进去,这样部署的时候就不用依赖NPM了)

    自动化测试

    自动化测试是构建步骤中最关键的部分。
    你的模块必须被单元测试覆盖,你也需要有集成测试来检查各部分能否协同工作。对于这类测试,你可以使用mocha/tap/Jasmine和断言库,如chai.
    基于你构建的应用是包含前端的还是只有API,你可以选择不同的端到端测试工具
    如果你的程序没有前端页面,只有API,你可以用hippiesupertest做端到端的测试。
    当开发包含前端页面的程序时,你还可以对用户界面进行测试。使用Protractor来测试AngularJS程序或者使用Nightwatch。为了确保程序在所有支持的浏览器中运行,需要在Selenium集群上运行端到端测试。也可以使用Sauce Labs 或者 Browserstack 服务。
    我要不断地强调这件事:没有足够的测试覆盖率,持续集成将导致一系列的生产问题。

    创建发布包

    如果所有的测试都已经通过,那么就可以从构建打包了。发布包必须包含运行应用程序的每个文件。所以你的成产服务不用再进行重新构建。
    一个简单的tar filename.tar *可以做这件事。然后确保文件位置可以被生产服务器访问,这样你才能获取到它。如AWS的S3或者任何的其它存储。

    部署

    由于我们刚创建的发布包包含程序所有的静态资源,我们只需要进行如下操作:

    • 下载最新发布包
    • 解压到一个新的文件夹
    • 更新symlink,让它指向刚创建的文件夹
    • 重启Node应用

    毫无疑问,这些步骤必须自动化,无需任何手动操作。像Ansible、Chef或者Puppet可以帮忙。

    回滚

    如果发生了错误,早晚会发生。确保有一个回滚的脚本。最快、最简单的方式是将symlink指向到前一个构建并重启node应用。

    推荐阅读:
    具有可操作性的运行Node.js的建议。

  • 相关阅读:
    最短路径的三种实现方法
    c/c++小知识
    c++ char * const p问题
    C++ typedef 四个用途
    [转]c++面向对象基础
    [转]C++中引用(&)的用法和应用实例
    表情包。
    linux基础学习
    redis缓存在项目中的使用
    关于redis
  • 原文地址:https://www.cnblogs.com/BaiGuodong/p/5630920.html
Copyright © 2011-2022 走看看