怎么给网站做链接,网站优化工作安排,西宁网站建设多少钱,平面设计专业哪个学校最好互联网时代#xff0c;人人都在追求产品的快速响应、快速迭代和快速验证。不论是创业团队还是大中型企业#xff0c;都在探索属于自己的敏捷开发、持续交付之道。fir.im 团队也在全面实施敏捷#xff0c;并推出新持续集成服务— flow.ci #xff0c;以帮助企业将开发测试流… 互联网时代人人都在追求产品的快速响应、快速迭代和快速验证。不论是创业团队还是大中型企业都在探索属于自己的敏捷开发、持续交付之道。fir.im 团队也在全面实施敏捷并推出新持续集成服务— flow.ci 以帮助企业将开发测试流程自动化更快速地交付产品。 4月15日fir.im CTO 郭扬在“光环国际·2017敏捷春季峰会”带来了《敏捷工程实践的基石——持续集成》的技术实践从敏捷方法论的角度分享了持续集成流程的质量实践与 fir.im 团队的 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 个分支 —— masterdevelopfeature 分支对 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 的 FindBugsruby 的 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对于单元测试有失败率、测试覆盖率对于验收测试或性能测试有多少的失败率这些数据都有可能成为衡量一个程序员的标准。 转载于:https://blog.51cto.com/12902932/1924585
