Merge branch 'v2' of https://github.com/dt-fe/weekly into v2

update 114
Merge pull request #188 from xuhongbo/patch-5
2019-08-05 09:11:22 +08:00 · 2019-08-05 09:11:20 +08:00 · 2019-07-29 22:54:20 +08:00 · 2019-07-29 20:13:54 +08:00 · 2019-07-29 13:23:28 +08:00 · 2019-07-29 13:23:16 +08:00
114 changed files with 4429 additions and 176 deletions
@@ -164,11 +164,11 @@ async function mount() {

 ```javascript
 async function mount() {
-  const result = await Promise.all(
+  const result = await Promise.all([
    fetch('a.json'),
    fetch('b.json'),
    fetch('c.json')
-  );
+  ]);

  render(...result);
 }
@@ -96,7 +96,7 @@

 最后考察候选人的发展潜力与工作态度，我们一般通过询问简单的算法问题，进一步了解候选人是否对技术真正感兴趣，而不只是对前端工程感兴趣。同时，算法问题也考察候选人解决抽象问题的能力，或者让候选人设计一个组件，通过对组件需求的不断升级，考察候选人是否能及时给出解决方案。

-最后时工作态度，首先会考察人品，对不懂的知识点装懂是违背诚信的行为，任何团队都不会要的。同时，**不正视自己技术存在的盲点，将是技术发展的最大阻碍**。不过这里也不怕被候选人套路，如果全部都回答不懂那也不用考虑了。
+最后是工作态度，首先会考察人品，对不懂的知识点装懂是违背诚信的行为，任何团队都不会要的。同时，**不正视自己技术存在的盲点，将是技术发展的最大阻碍**。不过这里也不怕被候选人套路，如果全部都回答不懂那也不用考虑了。

 # 3 总结

@@ -98,7 +98,7 @@ foo();

 我们谈到了一些意外情况下定义的全局变量, 代码中也有一些我们明确定义的全局变量. 如果使用这些全局变量用来暂存大量的数据, 记得在使用后, 对其重新赋值为 null.
 #### 2. 未销毁的定时器和回调函数
-在很多库中, 如果使用了观察着模式, 都会提供回调方法, 来调用一些回调函数. 要记得回收这些回调函数. 举一个 setInterval的例子.
+在很多库中, 如果使用了观察者模式, 都会提供回调方法, 来调用一些回调函数. 要记得回收这些回调函数. 举一个 setInterval的例子.
 ```javascript
 var serverData = loadData();
 setInterval(function() {
@@ -174,4 +174,4 @@ JS 这类高级语言，隐藏了内存管理功能。但无论开发人员是



-参考文章: [MDN 的内存管理介绍](https://developer.mozilla.org/zh-CN/docs/Web/JavaScript/Memory_Management)
+参考文章: [MDN 的内存管理介绍](https://developer.mozilla.org/zh-CN/docs/Web/JavaScript/Memory_Management)
@@ -0,0 +1,161 @@
+本期精读的文章是: [coinhive官方文档](https://coinhive.com)及[Monero官方文档](https://getmonero.org/)
+
+懒得看文章？没关系。
+
+咦，怎么是官方文档？
+
+本期精读有所不同，注重实操，先操作获取感性认识，然后再介绍相关的概念，由浅入深，力求不纠缠细节，但不遮盖环节。阅读本文需要对加密货币有一些基本常识 (如果你是一个开发者但是完全没了解过加密货币，可以参考[这里](http://piotrpasich.com/introduction-bitcoin-for-developers/))。希望同学们看完本文能对加密货币领域有一个更深更切实的感受。如果要了解更多细节，文末总结的延伸阅读链接列表是最好的开始。
+
+要注意一点，文中很多说明是默认基于XMR和BTC的，他们两个又同源，机制非常相似。**所以很多命题判断并不适用于所有的成千上万的加密货币.** 正相反，新的币种层出不穷，几乎所有的惯例都被打破，所有可能性都被尝试。这一点以下不再做说明。
+
+# 1 引言
+首先，干货。10行代码，5分钟，不需部署不需构建直接浏览器开挖。
+
+- 本地创建文件test.html，粘贴如下代码:
+  ```
+  <!doctype html>
+  <html>
+  <head>
+      <title>Mining</title>
+  </head>
+  <body>
+      <div class="coinhive-miner" 
+          style="width: 256px; height: 310px"
+          data-key="MUtCJzIDhrs01ERrf3qlqdawo35N0CYD">
+          <em>Loading...</em>
+      </div>
+      <script src="https://authedmine.com/lib/simple-ui.min.js" async></script>
+  </body>
+  </html>
+  ```
+
+- 本地双击打开。等待JS加载，点击widget "Start Mining"。开始挖矿! 如下图
+
+  ![mining](https://img.alicdn.com/tfs/TB13KIljiqAXuNjy1XdXXaYcVXa-880-686.png)
+
+  不错，数字已经在跳动，风扇开始工作，永无尽头的挖矿已经开始了。那么重要的是，挖出来的加密货币在哪呢？原来上面的代码里用的还是我的 API key，所以还没挖到你自己那里，所以请继续下面的步骤：
+
+- 在coinhive注册账号并登陆。它是做什么的？别急，后面会详细讲。在 `coinhive/settings` 找到自己的 `API keypair`，把 `public key` 复制出来，形如 `MUtCJzIDhrs01ERrf3qlqdawo35N0CYD`
+
+- 替换上面代码中的 data-key 部分，重新开始挖矿。好了，现在挖出的 Monero (这是啥？详见下一节) 已经会到你自己的 coinhive账户中。用下图来说明，你名下总计算过的 Hash 个数为 264K，当前难度换算为 0.00002 个 Monero(Symbol:XMR)。当前难度为 66G 一个 block，一个 block reward 5.87 XMR，得到一个 XMR 是 11.268G。264K/11.268G = 0.0000234。这就是你目前的收益。
+
+  ![coinhive dashbaord](https://img.alicdn.com/tfs/TB1LnMljiqAXuNjy1XdXXaYcVXa-2424-1118.png)
+
+- 查 bitfinex 可得现在 XMR 价格在 375 美元 (当你看到本文的时候，价格可能早就又波动到不知哪里去了)，所以你 (以及你忠实勤劳的电脑) 获得的实际收益为 0.000234 * 375 USD = 0.008775 USD，快到一分钱了 :)
+
+怎么样，有没有一种浏览器点开即玩一刀 999 级的感觉。以上操作的便捷直接，是建立在无数前人大量的开发和基础设施建设之上的。越是领域早期的工作，越步履维艰，收货也越丰厚。如今加密货币已经走到了一个成年期，逐渐稳定成熟起来。
+
+接下来我们聚焦到上面过程的每个环节，了解下拼图的每一块是怎样被构成全图的。
+
+# 2 聚焦
+让我们从最终端最接近用户的环节开始，逐一聚焦，最后走完整条链路。
+
+## 2.1 从浏览器说起
+本文标题叫浏览器挖矿，也是和贴合前端的部分。那么为什么可以在浏览器里挖矿？为什么可以很多用户在多个终端浏览器同时为同一个人 (你) 挖矿？
+
+我们知道，挖矿是对加密货币产生机制的俗称。主流大多采取 Proof of Work (PoW) 机制。最常见的 PoW 方式就是由网络中所有节点作为矿工，每个节点都基于 blockchain 前面 block 已有信息计算一个新信息。这个新信息的计算方式往往是某种 hash function，并且人为地被设置为需要巨大计算力和时间才能完成 (其具体难度一般也会实时调整)。当一个节点幸运地 (也依靠强大的算力) 第一个计算出结果后，会把这个结果广播到网络中。其他所有节点会验证这个结果 (我们知道非对称加密算法，验证便宜而计算昂贵)，一旦证实就会停下手里的计算，承认这个计算结果。新的计算结果创造出新的块，区块链的高度增加一层，然后计算继续下去。每一个块的生成一般在2-10分钟。这个过程就被叫做挖矿.
+
+既然是通用计算，既然是算一个 hash 值，那么民用级 CPU 和 GPU，浏览器或任何沙盒，虚拟机，移动设备当然就都可以。在我们的例子中，计算过程被做成分布式，每个用户可以各自计算，结果按 chunk 发回 master 汇总。这样就实现了终端用户 - 浏览器 - 共同贡献计算资源 - 换为 XMR 的过程。
+
+这就是对整个链路的一个描述。从中我们会生出一些疑问，比如:
+
+> 给我看看具体算什么 hash？为什么要算XMR而不是比特币或者其他？既然第一个算出的赢家通吃所有，为什么我的收益却是线性的？这种描述来看岂不是算力最大的一方**永远**都能算出结果而其他人颗粒无收吗?
+
+要看具体算法，没有问题。bitcoin 在[这里](http://www.righto.com/2014/02/bitcoin-mining-hard-way-algorithms.html)，XMR 则看[CryptoNote Standard 008](https://cryptonote.org/cns/cns008.txt)
+
+读完两个算法我们就有了以上疑问的答案:
+
+### 2.1.1 为什么要算XMR而不是比特币或者其他
+XMR 不是唯一选择，但是 BTC 是一个不可选的选择。因为 double SHA-265 在专业级 GPU 上会比 CPU 上快 10^4 倍 ([更多信息](https://en.bitcoin.it/wiki/Why_a_GPU_mines_faster_than_a_CPU))。这样一百万用户合力浏览器挖矿还不如一架子双路 Titan，就失去了分布到终端用户的意义。而 CryptoNight 在 GPU 上只比同价值 CPU 快 2 倍。另外 CryptoNight 算法也被设计为不适用[ASIC](https://en.wikipedia.org/wiki/Application-specific_integrated_circuit)。
+
+怎么实现的？CryptoNight 算法开宗明义地写明，运算主体是 Memory-Hard Loop，而不是 Computation-Hard Loop。每个循环都要在内存中检索。实际运行 CryptoNight 时，CPU 都会用最快，最接近 ALU 也是容量最小的 L3 Cache。换到 GPU，显存虽然很大，却没有 L3 Cache 一样的极致读写速度优化，而且由于内存读写成了瓶颈，GPU 中的大量 ALU 也没了用武之地。下图简略地描述了 CryptoNight 循环体的结构:
+
+![CryptoNight](https://img.alicdn.com/tfs/TB1KrQzjiqAXuNjy1XdXXaYcVXa-682-509.png)
+
+### 2.1.2 算力最大的一方永远都能算出结果
+看了比特币具体算法，你应该明白了 hash 是靠不停改变 nonce 来生成的。随机取一个值，算了不对，再随机取另一个 nonce 值..。既然是随机取，就不会存在赢家恒赢.
+
+### 2.1.3 为什么我的收益却是线性的
+这是一个隐蔽但是却非常重要的问题。答案是，本来确实是赢家通吃。如果你的算力足够大，挖矿时间足够长之后总会轮到你，但是收益会有大幅波动.
+
+就是因为如此，矿工们逐渐建立了矿池组织。大家把算力都投入到一起，合力算，然后不管这次实际是谁算出来，都按照贡献的算力比例分配收益。矿池是一个加密货币建立之初，完全推崇去中心化时没有预料到的结构，也产生了深远的影响。现在来自中国矿池的算力早已超过网络 50%，他们会在挖出的块中打上矿池标记，而这些矿池在加密货币的分叉，路线图中也扮演举足轻重的角色.
+
+所以你的算力并不是直接投入 XMR 网络中，而是投入一个矿池。在我们的例子里矿池就是 coinhive，只不过是一个比较特殊的矿池，特殊在矿池成员都运作在浏览器中。这就是为什么你会得到线性收益而不是 all or none.
+
+自古以来各行业都会自发产生行业工会，建立类似保险和行业守则 / 规范这些人人为我我为人人的机制。在 crypto 行业也不例外。这是意料之外而情理之中.
+
+## 2.2 在浏览器里发生了什么，或 coinhive 干了什么
+好，我们搞清了一些基本的 Monero 挖矿机制，下面来看看 coinhive。已经知道 coinhive 帮我们接入它的矿池，让再小的算力也能按比例得到产出。但是还有什么呢？最关键的一点，coinhive 是怎样把一个完整的 mining 过程拆分成小块，让一个或许并不强大的设备上的浏览器，也能快速接收 task，快速完成并且即时上传的呢?
+
+废话不多说，打开源码。本项目没有开源，构建完成后的在https://coinhive.com/lib/coinhive.min.js。先做初步 format 处理，发现有些工作完成在后端，worker shard 一侧。以下用松散的伪码总结一下 client side 的[main success scenario](https://wiki.ihris.org/wiki/Understanding_Use_Cases)流程 (注意很多地方简化了):
+
+```
+  - start
+  - loadWorkerResource
+  - load worker-asmjs.min.js
+  - CRYPTONIGHT_WORKER_BLOB = createObjectURL(Blob(response_of_worker-asmjs.min.js))
+  - _startNow -> _connectAfterSelfTest
+  - selfTest -> verify(testJob),
+    testJob = {
+      verify_id: "1",
+      nonce: "204f150c",
+      result: "6a9c7dea83b079ce0e012907dd6929bcb0aeec3c1f06c032ca7c3386432bca00",
+      blob: "0606c6d8cfd005cad45b0306350a730b0354d52f1b6d671063824287ce4a82c971d109d56d1f1b00000000ee2d1d4fd7c18bdc1b24abb902ac8ecc3d201ffb5904de9e476a7bbb0f9ec1ab04"
+    };
+    verify = if (!this._isReady) {
+        this.verifyJob = job
+    } else {
+        this.worker.postMessage(job)
+    }
+    // 实例化若干个JobThread，每个对应一个worker，worker实际执行asmjs.min.js
+  - _connect // verify成功，终于建立连接。根据public key固定hash到一个shard池然后随机选一个shard，建立websocket
+  - websocket.onmessage: if (type==job) work()
+  - work:
+    do { hash(input，output) } while !(meetTarget(output));
+    websocket.postMessage({nonce，output}) // hash done successfully。submit
+```
+
+看一下这个过程，结合[cns003 XMR blockchain specs](https://cryptonote.org/cns/cns003.txt)。XMR 的整体 hash input 很小，是:
+```
+  - size of [block_header，Merkle root hash，and the number of 
+    transactions] in bytes (varint)
+  - block_header,
+  - Merkle root hash,
+  - number of transactions (varint).
+```
+
+这样用 websocket 发过来毫无问题。之后就是完全独立的计算，调整 nonce 来算不同的 hash 结果。target 就是当前难度的一个指示.
+
+这样整条链路就比较清晰了。再思考一下以下问题:
+
+### 2.2.1 为什么XMR适宜分布式客户端计算
+因为能够利用每个用户的 CPU 和其中的**高速 L3 Cache**。这是中心化执行难以具备的条件.
+
+任何时候当考虑要不要把某项操作推到客户端进行时，都要想明白可以利用客户端的哪个资源，这个资源在客户端是否有明显优势，是否比后端中心化执行更有利。**很多时候答案是，优势并不明显。那么引入的网络通信成本，法规成本，额外开销可能就并不值得.**
+
+## 2.3 最后的步骤
+到了这里，最后剩余步骤就很标准模式化了。coinhive 作为矿场，代管着用户生产的加密货币。用户发请求提出 XMR，就需要提到一个自己的钱包地址保管，比如 [MyMonero](https://mymonero.com)。也可以直接提到 Exchange 交易所，在其中交易成其他币种，包括法币，然后电汇等等形式提现.
+
+如果对钱包或者交易所感兴趣 (这两个也是很大的话题，比如钱包分硬件钱包和软件钱包，离线冷钱包和线上热钱包，private key和recover seeds。交易所有多种多样的交易对，有杠杆，期货，空和多，多种挂单类型等等)，可以看[这里](https://www.blockchain-council.org/cryptocurrency/hot-wallet-vs-cold-wallet/)和[这里](https://github.com/txbits/txbits).
+
+# 3 更多讨论
+
+> 讨论地址是：[精读《全链路体验浏览器挖矿》 · Issue #55 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/55)
+
+**如果你想参与讨论，请[点击这里](https://github.com/dt-fe/weekly)，每周都有新的主题，每周五发布。**
+
+# 4 延伸阅读
+http://piotrpasich.com/introduction-bitcoin-for-developers
+
+https://en.wikipedia.org/wiki/Monero_(cryptocurrency)
+
+http://www.righto.com/2014/02/bitcoin-mining-hard-way-algorithms.html
+
+https://cryptonote.org/cns/cns001.txt
+cns001-008 是 Specs 集合
+
+https://en.bitcoin.it/wiki/Why_a_GPU_mines_faster_than_a_CPU
+
+https://en.wikipedia.org/wiki/Application-specific_integrated_circuit
+
+https://github.com/txbits/txbits
@@ -94,7 +94,7 @@ const incrementAsync = async count => {

 ### 将 action + reducer 改为两种 action

-redux 抽象的 action 与 reducer 的指责很清晰，action 负责改 store 以外所有事，而 reducer 负责改 store，偶尔用来做数据处理。这种概念其实比较模糊，因为往往不清楚数据处理放在 action 还是 reducer 里，同时过于简单的 reducer 又要写 action 与之匹配，感觉过于形式化，而且繁琐。
+redux 抽象的 action 与 reducer 的职责很清晰，action 负责改 store 以外所有事，而 reducer 负责改 store，偶尔用来做数据处理。这种概念其实比较模糊，因为往往不清楚数据处理放在 action 还是 reducer 里，同时过于简单的 reducer 又要写 action 与之匹配，感觉过于形式化，而且繁琐。

 重新考虑这个问题，我们只有两类 action：`reducer action` 与 `effect action`。

@@ -87,7 +87,7 @@ function getTokenBlockComment(restStr: string) {
 ```typescript
 while (sqlStr) {
  token =
-    getTokenWhitespace(sqlStr, token) | getTokenBlockComment(sqlStr, token);
+    getTokenWhitespace(sqlStr, token) || getTokenBlockComment(sqlStr, token);

  sqlStr = sqlStr.substring(token.value.length);

@@ -12,7 +12,7 @@

 <img src="assets/68/2.jpg" />

-产品用户体验不仅是指交互视觉，我的理解用户体验反应用户与产品从认知，使用到传播整个情感的连接和反馈。能力上包括了产品设计与功能实现，用户交互界面，以及系统承载能力。
+产品用户体验不仅是指交互视觉，我的理解用户体验反映用户与产品从认知，使用到传播整个情感的连接和反馈。能力上包括了产品设计与功能实现，用户交互界面，以及系统承载能力。

 上图是 CUBI Mobel：CUBI UX - User Experience Model。完整地说明了用户体验从内容、商业目标、交互、用户目标四个方面组合。

@@ -39,7 +39,7 @@
 我试着列了几类

 1. 产品商业阶段性目标和最终目标。营收提高，优化结构，工程效率提高，质量提高，能力覆盖。
-2. 工程研发过程及能力。投入产出比，系统成本，系统稳定性，创新性？。
+2. 工程研发过程及能力。投入产出比，系统成本，系统稳定性，创新性。
 3. 用户可用性。满意度，过程效率，过程质量。

 ## 总结
@@ -2,7 +2,7 @@

 重回 “手写 SQL 编辑器” 系列。这次介绍如何利用缓存优化编译器执行性能。

-可以利用 **Frist 集** 与 **Match 节点缓存** 这两种方式优化。
+可以利用 **First 集** 与 **Match 节点缓存** 这两种方式优化。

 本文会用到一些图做解释，下面介绍图形规则：

@@ -44,7 +44,7 @@ Match 节点缓存，指在运行时，缓存节点到其第一个终结符的

 拿 `select a, b, c, d from e` 这个语句做测试：

-| node 节点访问次数 | Frist 集优化 | First 集 + Match 节点缓存优化 |
+| node 节点访问次数 | First 集优化 | First 集 + Match 节点缓存优化 |
 | ----------------- | ------------ | ----------------------------- |
 | 784               | 669          | 652                           |

@@ -57,7 +57,7 @@ interface VDom {
  props: {
    [attrKey: string]: string;
  };
-  chindren: VDom[];
+  children: VDom[];
 }
 ```

@@ -149,9 +149,9 @@ Fiber 利用分片的思想，把一个耗时长的任务分成很多小片，
 因此，在组件更新时有可能一个更新任务还没有完成，就被另一个更高优先级的更新过程打断，优先级高的更新任务会优先处理完，而低优先级更新任务所做的工作则会完全作废，然后等待机会重头再来。所以 React Fiber 把一个更新过程分为两个阶段：

 - 第一个阶段 Reconciliation Phase，Fiber 会找出需要更新的 DOM，这个阶段是可以被打断的；
- 第二个阶段 Commit Phase，是无法别打断，完成 DOM 的更新并展示；
+- 第二个阶段 Commit Phase，是无法被打断的，完成 DOM 的更新并展示；

-在使用 Fiber 后，需要要检查与第一阶段相关的生命周期函数，避免逻辑的多次或重复调用：
+在使用 Fiber 后，需要检查与第一阶段相关的生命周期函数，避免逻辑的多次或重复调用：

 - componentWillMount
 - componentWillReceiveProps
@@ -422,7 +422,7 @@ function Article({ id }) {
    return () => {
      didCancel = true;
    };
-  }, [fetchArticle]);
+  }, [API.fetchArticle]);

  // ...
 }
@@ -0,0 +1,147 @@
+# 一、摘要
+
+相信大家以前应该接触过持续集成（Continuous integration）持续交付（continuous delivery）持续发布（continuous deployment）的概念，下面我们来说说三者的差异以及团队如何入手 CI/CD。
+
+作者：猫神。
+
+# 二、差异
+
+### 2.1 CI 持续集成
+
+开发者尽量时时刻刻合并开发分支至主干分支。避免直到发布日才开始合并，掉入集成地狱。无论何时新分支集成至项目，持续集成可以自动化测试持续验证应用是否正常。
+
+### 2.2 CD 持续交付
+
+持续交付是持续集成的扩展，可以保证稳定的发布产品新特性。这意味着基于自动化测试，你可以也可以一键自动化发布。理论上，持续交付可以决定是按天，按周，按双周发布产品。如果确实希望能够享受持续交付的好处，那么应该尽快发布到新产品中。一旦出现问题时能尽早排除。
+
+### 2.3 CD 持续部署
+
+持续部署是持续交付的下一步。通过这一步，每个新特性都自动的部署到产品中。但是如果出现未通过的测试用例将会终止自动部署。持续部署可以加速用户反馈新特性，避免发布日带来的压力。开发可以着力于开发系统，开发结束后几分钟就可以触达到用户。
+
+# 三、协作
+
+CI/CD 具体是个什么样的流程呢，如下图所示，差异仅在于是否自动部署。
+
+<img src="https://img.alicdn.com/tfs/TB1sNtaTrPpK1RjSZFFXXa5PpXa-884-426.png" />
+
+现在开发都讲究投入产出比，那么 CI/CD 具体需要做些什么呢？
+
+### Continuous Intergretion 持续集成
+
+投入：
+
+- 需要为每个新特性编写测试用例
+
+- 需要搭建持续集成服务器，监控主干仓库，并自动运行测试用例
+
+- 开发需要尽量频繁的合并分支，至少一天一次
+
+产出：
+
+- 更少的 bug，因为自动化测试可以回归测试产品
+- 编译部署产品更简化，因为集成的问题都尽早的解决了
+- 开发者可以尽量减少上下文切换，因为构建的时候就暴露问题，尽早解决了
+- 测试成本降低，因为 CI 服务器可以一秒运行几百个测试用例
+- 测试团队花更少的时间测试，可以重点关注测试上的改进。
+
+### Continuous delivery 持续交付
+
+投入：
+
+- 需要有持续集成的基础，测试用例需要覆盖足够的代码
+- 部署需要自动化，用户只需要手动触发，剩余的部署应该自动化
+- 团队需要增加新特性标志，避免未完成的新特性进入待发布的产品
+
+产出：
+  
+- 部署软件变得非常简单。团队不需要花费 n 天准备发布。
+- 可以提高发布频率，加速新特性触达用户进程。
+- 小的更改，对决策的压力要小得多，可以更快地迭代。
+
+### Continuous deployment 持续部署
+
+投入：
+
+- 测试必须要做到足够。测试的质量将决定发布的质量。
+- 文档建设需要和产品部署保持同步。
+- 新特性的发布需要协调其他部门，包括售后支持&市场&推广等。
+
+产出：
+
+- 快速的发布节奏，因为每个新特性一旦完成都会自动的发布给用户。
+- 发布风险降低，修复问题更容易，因为每次变更都是小步迭代发布。
+- 用户可以看到持续性的优化和质量提升，而不是非要等到按月，按季度，甚至按年
+
+如果开发的是一个新项目，暂时还没有任何用户，那么每次提交代码后发布将会特别简单，可以随时随地发布。一旦产品开始开发后，就需要提高测试文化，并确保在构建应用程序时增加代码覆盖率。当您准备好面向用户发布时，您将有一个非常好的连续部署过程，在该过程中，所有新的更改都将在自动发布到生产环境之前进行测试。
+
+如果正在开发的是一个老系统，就需要放慢节奏，开始打造持续集成&持续交付。首先可以完成一些简单可自动化执行的单元测试，不需要考虑复杂的端到端的测试。另外，应该尽快尝试自动化部署，搭建可以自动化部署的临时环境。因为自动化部署，可以让开发者去优化测试用例，而不是停下来联调发布。
+一旦开始按日发布产品，我们可以考虑持续部署，但一定要保证团队已经准备好这种方式，文档 & 售后支持 & 市场。这些步骤都需要加入到新产品发布节奏中，因为和用户直接打交道的是他们。
+
+# 四、如何开始持续集成
+
+## 4.1 了解测试类型
+
+为了获得 CI 的所有好处，每次代码变更后，我们需要自动运行测试用例。我们需要在每个分支运行测试用例，而不是仅仅在主干分支。这样可以最快速的找到问题，最小化问题影响面。
+在初始阶段并不需要实现所有的测试类型。一开始可以以单元测试入手，随着时间扩展覆盖面。
+
+- 单元测试：范围非常小，验证每个独立方法级别的操作。
+- 集成测试：保证模块间运行正常，包括多个模块、多个服务。
+- 验收测试：与集成测试类似，但是仅关注业务 case，而不是模块内部本身。
+- UI 测试：从用户的角度保证呈现正确运行。
+
+并不是所有的测试都是对等的，实际运行中可以做些取舍。
+
+<img src="https://img.alicdn.com/tfs/TB18278TmrqK1RjSZK9XXXyypXa-346-269.png" />
+
+单元测试实现起来既快成本又低，因为它们主要是对小代码块进行检查。另一方面，UI 测试实施起来很复杂，运行起来很慢，因为它们通常需要启动一个完整的环境以及多个服务来模拟浏览器或移动行为。因此，实际情况可能希望限制复杂的 UI 测试的数量，并依赖基础上良好的单元测试来快速构建，并尽快获得开发人员的反馈。
+
+### 4.2 自动运行测试
+
+要采用持续集成，您需要对推回到主分支的每个变更运行测试。要做到这一点，您需要有一个服务来监视您的存储库，并听取对代码库的新推送。您可以从企业预置型解决方案和云端解决方案中进行选择。您需要考虑以下因素来选择服务器：
+
+- 代码托管在哪里？CI 服务可以访问您的代码库吗？您对代码的生存位置有特殊的限制吗？
+- 应用程序需要哪些操作系统和资源？应用程序环境是否受支持？能安装正确的依赖项来构建和测试软件吗？
+- 测试需要多少资源？一些云应用程序可能对您可以使用的资源有限制。如果软件消耗大量资源，可能希望将 CI 服务器宿主在防火墙后面。
+- 团队中有多少开发人员？当团队实践 CI 时，每天都会将许多更改推回到主存储库中。对于开发人员来说，要获得快速的反馈，您需要减少构建的队列时间，并且您需要使用能够提供正确并发性的服务或服务器。
+  在过去，通常需要安装一个独立的 CI 服务器，如 Bamboo 或 Jenkins，但现在您可以在云端找到更简单的解决方案。例如，如果您的代码托管在 BitBucket 云上，那么您可以使用存储库中的 Pipelines 功能在每次推送时运行测试，而无需配置单独的服务器或构建代理，也无需限制并发性。
+- 使用代码覆盖率查找未测试的代码。一旦您采用了自动化测试，最好将它与一个测试覆盖工具结合起来，帮助了解测试套件覆盖了多少代码库。代码覆盖率定在 80%以上是很好的，但要注意不要将高覆盖率与良好的测试套件混淆。代码覆盖工具将帮助您找到未经测试的代码，但在一天结束的时候，测试的质量会产生影响。如果刚开始，不要急于获得代码库的 100%覆盖率，而是使用测试覆盖率工具来找出应用程序的关键部分，这些部分还没有测试并从那里开始。
+- 重构是一个添加测试的机会。如果您将要对应用程序进行重大更改，那么应该首先围绕可能受到影响的特性编写验收测试。这将为您提供一个安全网，以确保在重构代码或添加新功能后，原始行为不会受到影响。
+
+# 五、接受 CI 文化
+
+自动化测试是 CI 的关键，但同时也需要团队成员接受 CI 文化，并不是心血来潮晒两天鱼，并且需要保证编译畅通无阻。QA 可以帮助团队建设测试文化。他们不再需要手动测试应用程序的琐碎功能，现在他们可以投入更多的时间来提供支持开发人员的工具，并帮助他们采用正确的测试策略。一旦开始采用持续集成，QA 工程师将能够专注于使用更好的工具和数据集促进测试，并帮助开发人员提高编写更好代码的能力。
+
+- 尽早集成。如果很长时间不合并代码，代码冲突的风险就越高，代码冲突的范围就越广。如果发现某些分支会影响已经存在的分支，需要增加发布关闭标签，避免发布时两个分支冲突。
+- 保证编译时时刻刻畅通。一旦发现任何编译问题，立刻修复，否则可能会带来更多的错误。测试套件需要尽快反馈测试结果，或者优先返回短时间测试（单元测试）的结果，否则开发者可能就切换回开发了。一旦编译出错，需要通知给开发者，或者更进一步给出一个 dashboard，每个人都可以在这里查看编译结果。
+- 把测试用例纳入流程的一部分。确保每个分支都有自动化测试用例。似乎编写测试用例拖慢了项目节奏，但是它可以减少回归时间，减少每次迭代带来的 bug。而且每次测试通过后，将会非常有信息合并到主干分支，因为新增的内容不影响以前的功能。
+- 修 bug 的时候编写测试用例。把 bug 的每个场景都编写成测试用例，避免再次出现。
+
+# 六、集成测试 5 个步骤
+
+1. 从最严格的代码部分入手测试
+2. 搭建一个自动构建的服务自动运行测试用例，在每次提交代码后。
+3. 确保团队成员每天合并变更
+4. 代码出现问题及时修复
+5. 为每个新实现的操作编写测试用例。
+   可能看着很简单，但是要求团队能够真正落地。一开始你需要放慢发布的脚步，需要和 pd、用户沟通确保不上线没有测试用例的新功能。我们的建议是从小处入手，通过简单的测试来适应新的例程，然后再着手实现更复杂更难管理的测试套件。
+
+# 七、说说笔者的团队
+
+以上文章主要是说明团队实现 CI/CD 的取舍和可行性步骤。下面来说说希望 CI/CD 给笔者团队带来什么样的变化。目前笔者团队已经实现前端项目发布编译工程化，采用的是基于 webpack 的自建工具云构建模式。但现在面临的问题是 1. 交互的系统比较多，交互系统提供的接入源变更后，需要人工通知其他系统手动触发编译，而且每次手动编译都需要在本地切换到指定分支，然后手动触发云构建，2. 多人协作，分支拆分较细，需要手动合并分支，触发编译。整个流程冗长，而且中间存在人力沟通成本，容易产生沟通误差。所以首先希望解决的是 CI 自动化，当依赖变更后或者分支合并后，自动集成，自动编译。当然生产环境暂时还不敢瞎搞，但大部分重复编译的工作量主要集中在预发环境，所以手动部署生产环境的成本还是可以接受的。CI 自动化之前，需要提供系统之间交互的单元测试用例，每次 CI 后自动运行单元测试用例，最好能打通 QA 的测试用例，进行回归测试。流程对比如下：
+
+<img src="https://img.alicdn.com/tfs/TB1jIw.TgDqK1RjSZSyXXaxEVXa-1950-662.png"/>
+可以看出引入CI后，我们的成本是需要搭建CI服务器，新增单元测试、打通回归测试案例，但前者可以加快系统编译效率，后者可以进一步的提升代码质量，减少回归测试时间，这些成本都是可以接受的。市面上已有很多开源持续集成工具，例如我们熟悉的Jenkins，还有TeamCity、Travis CI、GO CD、Bamboo、Gitlab CI、CircleCI……等等等等。目前还在继续调研中，这片文章应该会有第二篇，说说后续的实践和CD。
+
+> 讨论地址是：[精读《持续集成 vs 持续交付 vs 持续部署》 · Issue #147 · dt-fe/weekly](https://github.com/dt-fe/weekly/issues/147)
+
+**如果你想参与讨论，请 [点击这里](https://github.com/dt-fe/weekly)，每周都有新的主题，周末或周一发布。前端精读 - 帮你筛选靠谱的内容。**
+
+> 关注 **前端精读微信公众号**
+
+<img width=200 src="https://img.alicdn.com/tfs/TB165W0MCzqK1RjSZFLXXcn2XXa-258-258.jpg">
+
+**special Sponsors**
+
+- [DevOps 全流程平台](https://e.coding.net/?utm_source=weekly)
+
+> 版权声明：自由转载-非商用-非衍生-保持署名（[创意共享 3.0 许可证](https://creativecommons.org/licenses/by-nc-nd/3.0/deed.zh)）
--- a/Show More
+++ b/Show More
Author	SHA1	Message	Date
ascoders	62be743112	Merge branch 'v2' of https://github.com/dt-fe/weekly into v2	2019-08-05 09:11:22 +08:00
ascoders	6d27e723cd	update 114	2019-08-05 09:11:20 +08:00
黄子毅	44dd8057e2	Merge pull request #188 from xuhongbo/patch-5 Update 039.精读《全链路体验浏览器挖矿》.md	2019-07-29 22:54:20 +08:00
leoxu	d956b15ad0	Update 039.精读《全链路体验浏览器挖矿》.md fix type	2019-07-29 20:13:54 +08:00
黄子毅	961d77b4d1	Merge pull request #186 from xuhongbo/patch-3 Update 113.精读《Nodejs V12》.md	2019-07-29 13:23:28 +08:00
黄子毅	c763fc15bd	Merge pull request #187 from xuhongbo/patch-4 Update 068.精读衡量用户体验.md	2019-07-29 13:23:16 +08:00
leoxu	f9f04d711f	Update 068.精读衡量用户体验.md 修改一些用词错误	2019-07-29 11:20:01 +08:00
leoxu	5d40208d45	Update 113.精读《Nodejs V12》.md 不是很通顺	2019-07-29 11:03:00 +08:00
ascoders	771bb9f914	Merge branch 'v2' of https://github.com/dt-fe/weekly into v2	2019-07-29 08:56:57 +08:00
ascoders	96f850e29f	113	2019-07-29 08:53:44 +08:00
黄子毅	349e7df2b6	Merge pull request #185 from LiuL0703/patch-2 fix:typo	2019-07-27 22:16:19 +08:00
Linear-Enter	b198d57cf6	fix:typo	2019-07-27 10:17:15 +08:00
黄子毅	03b8840291	Merge pull request #181 from cpprookie/cpprookie-patch-1 Update 112.精读《源码学习》.md	2019-07-23 09:45:31 +08:00
黄子毅	60899c0bf8	Merge pull request #183 from lengjing/patch-1 Update 082.精读《Htm - Hyperscript 源码》.md	2019-07-23 09:45:20 +08:00
lengjing	648e113e66	Update 082.精读《Htm - Hyperscript 源码》.md	2019-07-22 11:08:32 +08:00
chen tuo	61a5e74908	Update 112.精读《源码学习》.md 修改文字错误	2019-07-22 10:29:10 +08:00
ascoders	d2273e72f6	Merge branch 'v2' of https://github.com/dt-fe/weekly into v2	2019-07-22 09:58:20 +08:00
ascoders	386b605c32	finish 112	2019-07-22 09:19:57 +08:00
黄子毅	b60cca25d7	Merge pull request #180 from LiuL0703/patch-1 fix:typo	2019-07-21 23:43:19 +08:00
Linear-Enter	68e6c23f82	fix:typo	2019-07-21 19:12:01 +08:00
ascoders	a9d2c1d47a	111	2019-07-16 08:54:37 +08:00
ascoders	cc364c4b2f	Merge branch 'v2' of https://github.com/dt-fe/weekly into v2	2019-07-08 12:15:52 +08:00
ascoders	f65b11ea6b	110	2019-07-08 12:15:47 +08:00
黄子毅	35458365c6	Merge pull request #174 from Kerminate/v2 fix: vue 与 Mutable 相结合	2019-07-01 10:18:52 +08:00
Kerminate	dde997ac27	fix: vue 与 Mutable 相结合	2019-07-01 10:10:44 +08:00
ascoders	53ae9e077e	Merge branch 'v2' of https://github.com/dt-fe/weekly into v2	2019-07-01 08:37:28 +08:00
ascoders	30bdcf13dd	109	2019-07-01 08:37:25 +08:00
黄子毅	12b1b02539	Merge pull request #170 from vivaxy/patch-1 Update 078.精读《手写 SQL 编译器 - 性能优化之缓存》.md	2019-06-25 22:24:53 +08:00
黄子毅	2a92487a5e	Merge pull request #171 from vivaxy/patch-2 Update 064.精读《手写 SQL 编译器 - 词法分析》.md	2019-06-25 22:24:40 +08:00
ascoders	b6487f8754	fix bug	2019-06-25 22:24:19 +08:00
vivaxy	7a8e1b25dd	Update 064.精读《手写 SQL 编译器 - 词法分析》.md Fix syntax.	2019-06-25 14:53:07 +08:00
vivaxy	44683fa1dc	Update 078.精读《手写 SQL 编译器 - 性能优化之缓存》.md	2019-06-25 09:16:11 +08:00
ascoders	3a4b82bc76	Merge branch 'v2' of https://github.com/dt-fe/weekly into v2	2019-06-24 09:06:59 +08:00
ascoders	4f2ed7b3cb	update	2019-06-24 09:06:55 +08:00
黄子毅	a72795b099	Merge pull request #168 from eos3tion/patch-1 Update 107.精读《Optional chaining》.md	2019-06-18 10:01:18 +08:00
ascoders	dea2acc384	Merge branches 'v2' and 'v2' of https://github.com/dt-fe/weekly into v2	2019-06-17 10:46:28 +08:00
ascoders	74f539cc34	fix typo error	2019-06-17 10:44:18 +08:00
程方	1947b9c08c	Update 107.精读《Optional chaining》.md 修正`.?`为`?.`	2019-06-17 10:34:16 +08:00
黄子毅	e84c85cc1d	Merge pull request #167 from think2011/patch-2 Update 029.精读《JS 中的内存管理》.md	2019-06-17 09:27:00 +08:00
ascoders	170c0f4525	Merge branch 'v2' of https://github.com/dt-fe/weekly into v2	2019-06-17 09:23:37 +08:00
ascoders	c836848228	107	2019-06-17 09:23:32 +08:00
曾浩	7b87d5c3c4	Update 029.精读《JS 中的内存管理》.md	2019-06-16 20:27:28 +08:00
黄子毅	add5bdd01e	Merge pull request #166 from think2011/patch-1 Update 019.精读《最佳前端面试题》及面试官技巧.md	2019-06-14 14:27:15 +08:00
曾浩	0633764a44	Update 019.精读《最佳前端面试题》及面试官技巧.md	2019-06-14 13:47:36 +08:00
黄子毅	fcc183d523	Update 103.精读《为什么专家不再关心技术细节》.md	2019-06-11 10:46:30 +08:00
ascoders	627db8a249	update	2019-06-10 09:01:29 +08:00
ascoders	b41530b37c	Merge branch 'v2' of https://github.com/dt-fe/weekly into v2	2019-06-10 09:01:06 +08:00
ascoders	2062b652dd	106	2019-06-10 09:00:27 +08:00
黄子毅	365997863e	Merge pull request #161 from xuhongbo/patch-1 Update 105.精读《What's new in javascript》.md	2019-06-03 14:57:32 +08:00
黄子毅	ab6978da4a	Merge pull request #160 from Kerminate/v2 fix: 对大数描述的修正	2019-06-03 10:39:31 +08:00
leoxu	f37d496f1b	Update 105.精读《What's new in javascript》.md 缺少 `=`	2019-06-03 10:33:07 +08:00
Kerminate	3bf34602b4	fix: 对大数描述的修正	2019-06-03 10:20:54 +08:00
ascoders	274ffc0a9f	Merge branch 'v2' of https://github.com/dt-fe/weekly into v2	2019-06-03 09:19:56 +08:00
ascoders	72e8b69dd7	104	2019-06-03 09:19:47 +08:00
黄子毅	62ac1d76b9	Merge pull request #158 from xuhongbo/patch-1 Update 101.精读《持续集成 vs 持续交付 vs 持续部署》.md	2019-05-27 14:06:12 +08:00
leoxu	e537efe7bd	Update 101.精读《持续集成 vs 持续交付 vs 持续部署》.md 格式问题，没有换行，导致读者会有疑惑，并不能直观的看到产出	2019-05-27 11:27:10 +08:00
ascoders	f1871f59e5	fix	2019-05-27 10:13:26 +08:00
ascoders	5d08eabde3	104	2019-05-27 08:56:59 +08:00
黄子毅	7e79c60a12	Merge pull request #156 from xuhongbo/patch-1 Update 103.精读《为什么专家不再关心技术细节》.md	2019-05-20 16:46:47 +08:00
leoxu	9c051f6ab5	Update 103.精读《为什么专家不再关心技术细节》.md 原理 -> 远离	2019-05-20 14:32:57 +08:00
ascoders	065fab1546	fix	2019-05-20 14:07:20 +08:00
ascoders	88cd38685d	103	2019-05-20 09:39:06 +08:00
黄子毅	7de3c77c3b	Merge pull request #154 from dancerphil/master fix: sort by file name #152	2019-05-17 13:34:31 +08:00
Cong Zhang	09978602c0	fix: sort by file name #152	2019-05-17 10:54:09 +08:00
ascoders	fcb42f2dcf	102	2019-05-13 09:00:22 +08:00
ascoders	0ef3cf16a9	format	2019-05-12 12:32:05 +08:00
黄子毅	baf666dbf8	Merge pull request #150 from huxiaoyun/master feat: 101	2019-04-29 11:47:04 +08:00
ludy.hxy	74f1884f78	feat: 101	2019-04-29 11:19:37 +08:00
黄子毅	4f815df5ab	Merge pull request #149 from Kerminate/master fix: 引用正确的函数名	2019-04-23 09:44:09 +08:00
Kerminate	35a8ee0a9e	fix: 引用正确的函数名	2019-04-23 09:29:01 +08:00