作为2018年IT互联网界的首个大新闻，这次被曝出的芯片级漏洞波及范围之广、程度之深是我们始料未及的，而位于漩涡中心的Intel扮演的是一个相当重要但又有些尴尬的角色。


据悉，Meltdown和Spectre这两个漏洞可以绕过内存访问的安全隔离机制，使用恶意程序来获取操作系统和其他程序的被保护数据，造成内存敏感信息泄露。

事件的起点是Intel市售处理器被爆出因为设计的缺漏，会造成原本普通的程序却可以拥有前所未有的高权限，甚至可以直接访问核心内存当中的数据，这对于用户隐私和设备安全无疑是多年来前所未有的噩梦。

[深度解析Intel CPU漏洞为何如此恐怖]

这次的漏洞之所以备受关注，是因为这些漏洞能让恶意程序获取核心内存里存储的敏感内容，比如能导致黑客访问到个人电脑的内存数据，包括用户账号密码、应用程序文件、文件缓存等。

此次两组漏洞拥有内核级别的高权限，潜在的危害性、影响的广阔性、解决的棘手性都始料未及。

此次事件还带来了哪些严重影响？针对此次漏洞应如何及时补救？关注2月2日14:00“深度解析Intel CPU漏洞为何如此恐怖”直播活动，元鼎科技资深安全大咖王国斌为您指点迷津。


直播间入口：http://www.otpub.com/home/live/liveinfo/liveid/10117.html 查看全部

过去20多年，互联网技术的革新引领时代的发展，加速向经济社会各领域渗透融合，不断催生新产品、新业务、新模式、新业态！

互联网+开始向各行各业渗透，从“人人相联”向“万物互联”迈进。在产业周期的更迭中，驱动全球互联网创新演进的资本、技术、数据、需求四大要素持续演化。

经济发展在新一代互联网产业中扮演什么角色？

传统企业如何实现信息化、数据化、在线化？

互联网企业如何引进来、走出去？

一线互联网技术人才视野在哪里？

二线互联网人才该如何进阶封神？

敬请关注12月10日9 : 00“中国【郑州】开发者大会”解码未来开发者直播活动，拥抱一线互联网技术趋势，关注技术在商业中的应用，积极实现一二线开发技术、思维、环境等的互联！

活动流程


09:00-09:05 主持人开场

09:05-09:15 主办方致辞：大象融媒负责人

09:15-09:25 主办方致辞：大象互联网圈发起人王向阳

09:25-09:45 技术创业下赛道的选择与实践：UU跑腿创始人&CEO乔松涛

09:45-10:05 工业大数据解决方案分享：阿里云架构师涂铭

10:05-10:25 移动端内容分发技术架构解析：迅雷AI以及推荐系统业务主管张升涛

10:25-10:45 详解车辆自动驾驶系统：宇通自动驾驶实验室第二负责人惠作奎

10:45-11:05 唯品会大数据架构及应用实践：唯品会资深数据架构师李创

11:05-11:50 趋势·应用·互联论坛

11:05-12:00 大象互联网圈&大象融媒战略签约仪式


13:30-14:00 面向未来的运维开发一体化——DevOps体系及实践：DevOps时代发起人、高效运维社区发起人萧田国

14:00-14:30 汽车之家数据库平台化实践：汽车之家架构师蔺瑞超

14:30-15:00 职场思考的快与慢：汽车之家开发经理李占斌

15:00-15:30 B站数据平台建设实践：Bilibili数据平台技术经理薛赵明

15:30-16:00 大数据营销：平安好房用户策略团队负责人胡辰

16:00-16:30 OpenPitrix平台中的微服务：开源文化布道、青云基础设施产品经理李建盛

16:30-17:00 基于人脸识别的人证合验采集平台的建设：中软高科产品经理张广举

17:00-17:50 拥抱·转型·发展论坛

17:50-18:00 项目展示时间

听企业家、互联网大牛们聊聊一二线互联网“趋势 · 应用 · 互联”那些事儿！

直播间入口：http://www.otpub.com/home/live/liveinfo/liveid/10082 查看全部

互联网时代，人人都在追求产品的快速响应、快速迭代和快速验证。不论是创业团队还是大中型企业，都在探索属于自己的敏捷开发、持续交付之道。fir.im 团队也在全面实施敏捷，并推出新持续集成服务 — flow.ci ，以帮助企业将开发测试流程自动化，更快速地交付产品。 这篇文章将以实际开发为例，从敏捷方法论的角度来讲解 CI 技术实践与演变过程，大概分为三个部分，希望带给你一些参考。

持续集成做什么
持续集成的概念出现在 2001 年，它其实是一个 XP 极限编程的工程实践。那么持续的是什么，集成是什么呢，非常简单就是“一直不停地集成代码”。

持续集成是把代码频繁的合并到主干，通过自动构建的方式验证软件的质量，让团队快速的响应质量，快速的修复问题，快速的给客户解决问题，快速地交付更好的软件质量。

我们为什么要做持续集成
开发人员对下面的软件开发场景很熟悉，比如：
场景一：开发了新功能，老功能产生新的 bug；场景二：修好一个 bug，又产生其他 bug，甚至出现连环 bug；场景三：出现的 bug 比较多，修改代码要很谨慎，不熟悉的模块一般不敢动，怕引起问题；

持续集成是如何缓解这个问题，Martin Fowler 大师曾经说过：

“Continuous Integration doesn’t get rid of bugs, but it does make them dramatically easier to find and remove.” — Martin Fowler

如上面所说，持续集成不能消除 bug ,但能更容易地发现 bug,更快速地修复，提升产品质量。那么，持续集成能给我们带来哪些价值？




从这张图上可以看到，持续集成形成一个完美的闭环。通过持续的集成进行不断地检查、调整，同时，项目的透明性也得到了最大的体现。

fir.im 如何进行持续集成实践
这是一个常见的持续集成流水线：




在日常的开发过程中，程序员在本地提交代码，持续集成流水线要求先做一次本地集成，在本地进行验证后提交到源代码管理仓库中，之后源代码工具会发出 webhook 触发到持续集成系统中。当构建/测试完成后，会及时通过钉钉或邮件通知团队（测试/研发/boss/产品经理）集成状态，产品经理或项目经理收到通知后会在测试环境做验收测试，这是一个比较完美的反馈环。

假如测试通过验收完毕后，持续集成系统会自动触发部署到类生产环节或测试环境，或由专人手动部署到生产环境。

为什么要做本地集成
首先，代码在远程进行管理，每个人都会提交代码，远程的代码仓库会产生变化，所以在本地集成的时候要求进行代码合并，以免出现分支冲突和代码冲突。其次，不要依赖于持续集成系统给你结果，可能需要 30 分钟的时间，不要让开发人员等待，一定要先做本地集成。

如何做版本提交
再说一个提交的问题，我们尽量保证每一次提交都是一个完整的提交，也就是原子提交。

当代码变动你想创建提交时，这个提交应该尽可能的小量，并且包含一个不可分割的特性（feature）、修复（fix）或优化（improved）。

拿每个产品开发都会遇到的 login 功能开发举例，当填完的用户名和密码传到数据库，做完验证后给用户返回一个结果。那什么是一个原子提交？比如，提交验证一个用户名，这是一个完整的 feature ；验证密码是否符合格式（6位/8位），这也是一个完整的 feature ；当我验证完用户名和密码后再传到数据库之后，查询正确与否，这也是一个完整的 feature ；保证每次提交是一个完整的 feature 或修复了一个 bug，不要代码写成半截。

持续集成系统
这里讲的是狭义的持续集成系统，通常的 CI 系统收到提交之后会触发构建，构建会有信息返回比如 commit id 、commit 信息、代码变更等，收到代码提交后会触发自动构建，接着安装依赖进行编译，并触发质量保证流程，也就是说自动化测试集。




自动化测试集包括代码静态检查－单元测试－集成测试－验收测试－性能测试，也会有压力测试、回归测试、monkey test等等一系列的测试。




接下来，我们具体讲一下 fir.im 团队如何进行持续集成实践的。

fir.im 的敏捷环境
fir.im 是一个内测分发平台，我们也做了一个持续集成 CI 产品－flow.ci。先来看一下我们正在使用的敏捷环境：




Trello 看板;三个环境（类生产环境，测试环境，生产环境）;CI 工具（Jenkins/flow.ci）

说一下 Git 分支管理
我们在应用 3 个分支 —— master／develop／feature 分支，对 feature 命名会有一些要求，持续集成系统一定会反馈到 trello 的 kanban 里，所以对于 feature 分支我们也有这样的命名 feature/fci-{card number} 以方便区分。




多分支如何做频繁地持续集成？
master 分支，即线上分支。线上通常会有一些 hotfix, 任何产品都不可能避免线上的 bug ,这些 bug 需要在 master 分支进行修复，修复完成后持续集成系统会告知已上线，收到团队反馈，这些代码会要求更新在 develop 分支上，之后所有团队也会收到相关通知，那么 feature 分支会有变化吗？答案是肯定的，因为频繁的集成可以防止代码偏离。这就是我们多分支构建的策略。




还有一个策略——不同的分支不同的构建，持续集成系统跑完整个流程会很长，所以在 feature 分支频繁度会比在本地构建要高一些，但是也没有那么高。为了保证持续集成系统能快速地收到反馈，需要在 feature 分支上做一些定制的 workflow ,所以我们做了代码静态分析和单元测试。

当 feature 分支的 card 做完之后（scrum 中 done 的含义是指测试验收完毕），集成到 develop 分支，develop 分支会自动部署到测试环境，会跑一个整个自动化测试集，为什么是这样的构建策略呢？

我们会做代码 review ，当 feature 分支提 pr 到 develop 分支上，这样 develop 分支的构建条件是：当收到 pr 之后，开始跑持续集成。假如部署完成整个测试跑过了产品经理验收之后，没毛病了，终于可以发布了到 master 分支。

整个团队的构建频率可以看下这张图:




本地集成的频率非常高，远程构建对应的是 feature 分支，会相对低一下。QA 环境对应的是 develop 分支的构建粒度。这样的构建每天都会产生，所以做完之后不要积压，一定要保持上线节奏。




kanban + scrum 结合的方式构成我们每日构建，这是一个整体的构建策略和上线频率。

fir.im 的持续集成系统演变过程
罗马不是一天建成的，持续集成不是一开始就是完美的，每个开发者心中都有一个比较理想的自动化工作流——持续部署，大概会经历这几个演变阶段：
最初阶段：提交代码－自动部署；一般进阶：提交代码－代码静态分析－自动部署，最简单先再加入代码静态分析；高级进阶：提交代码－代码静态分析－自动化测试集－自动部署；




这是我们在用的自动化测试集，下面分别说下静态检查分析、单元测试、验收测试、性能测试的具体用途。

Step 1. 静态代码分析
每个公司都会有自己的代码规范，代码静态分析工具能够保证代码质量，现成的工具有 java 的 FindBugs，ruby 的 rubocop 等。利用代码检查工具可以帮助团队发现可重构的地方，输出产出 – HTML 报告，也会发现潜在 bug；有的代码检查工具还会检查出一些安全漏洞。

这三点是代码静态分析最重要的作用。这里也分享一个 GitHub 地址，列出一些主流语言的代码分析工具，可以参考一下。

Step 2. “单元测试”
这里的 “单元测试”也加上了集成测试，毕竟创业公司要求资源最大化。程序员一定要写单元测试，要克服开发的惯性思维，不要甩锅。下面有一些注意的点和大家分享：
测试异常——不仅仅测试正确情况，也要主动测试异常；减少耦合——保证独立的可测试性；功能分离——单元测试流太长，超过 20 分钟的话要详细想一下如何将功能单独拆开，效率更高；测试＝需求——从测试代码看到每个 class 是干什么的，同时出现 bug 时，第一时间是看测试，想想如何从测试中复现；

Step 3. 验收测试
验收测试是端对端的测试，从收到用户名密码到返回结果，是不是我们所期望的一个值，这是验收 Acceptance Test，其实是验收了整个功能。代码静态检查和单元测试，保证了我们如何怎么去写代码，验收测试保证了写正确代码，符合开发需求。

flow.ci 做验收测试比较多，用的是比较流行的框架 Cucumber + Selenium WebDriver，目前支持 3 种数据库，5 种 git 仓库，7 种 开发语言跑在 docker 容器云上，支持 iOS 构建跑在 mac 机器上，要保证这些排列组合正常运行，这是 flow.ci 做验收测试最核心的价值。




其实，持续集成是一个工作流，当 push 代码的时候才会 run 起来，但是 flow.ci 本身系统也有外部依赖的特殊性，会依赖一些第三方的 sevice（比如 GitHub/GitLab 等），验收测试应该一直保持不断地运行，也可以叫持续测试吧。因为我们永远不能保证第三方的 api 会不会改变:)

Step 4. 性能测试
我们的性能测试做的比较简单，主要测试 api.因为 fir.im 做 app 的内测分发，我们需要性能测试保证 app 上传下载的正常稳定。性能测试是单用户的，压力测试是多用户的，这是两者之间的区别。

性能测试会有一些不确定性，有很多系统会产生缓存。flow.ci 的性能测试跑在 docker 上，是一个干净独立的环境，需要让系统预热运行一下。Locust/JMeter/LoadRunner是目前比较流行的性能测试工具。 flow.ci 目前用的是 locust,可以参考一下。

持续集成的可视化、数据分析




说到数据统计分析，整个 ci 流程跑下来产生的很多数据也非常有挖掘的价值。比如，对于代码静态分析有多少 Offence、Risk、Bug，对于单元测试有失败率、测试覆盖率；对于验收测试或性能测试有多少的失败率，这些数据都有可能成为衡量一个程序员的标准。





结语
CI 就像盖楼房的脚手架一样，没有脚手架就没办法盖出一个足够高的楼，没有 CI 就无法交付质量足够好的软件！

分享阅读：http://blog.fir.im/firim_ci_practice/  查看全部

「持续集成（Continuous Integration）」、「持续交付（Continuous Delivery）」和「持续部署（Continuous Deployment）」这三个概念有很详细的解释。这里借用文中的插图，说一下我对这三个概念的理解。
 
持续集成




持续集成强调开发人员提交了新代码之后，立刻进行构建、（单元）测试。根据测试结果，我们可以确定新代码和原有代码能否正确地集成在一起。
 
持续交付




持续交付在持续集成的基础上，将集成后的代码部署到更贴近真实运行环境的「类生产环境」（production-like environments）中。比如，我们完成单元测试后，可以把代码部署到连接数据库的 Staging 环境中更多的测试。如果代码没有问题，可以继续手动部署到生产环境中。
 
持续部署




持续部署则是在持续交付的基础上，把部署到生产环境的过程自动化。我个人觉得持续集成、持续交付、持续部署非常值得推广。开发过程中最怕集成时遇到问题导致返工，而持续集成、持续交付、持续部署恰恰可以早发现早解决，从而可以避免这个问题。
 
参考：https://www.mindtheproduct.com/2016/02/what-the-hell-are-ci-cd-and-devops-a-cheatsheet-for-the-rest-of-us/  查看全部