网站建设的好公司强大的wordpress插件

当前位置： 首页 > news >正文

网站建设的好公司,强大的wordpress插件,wordpress wptitle,php 做资讯网站一篇文章显得略长#xff0c;本文对应第3-4章。前言、第1-2章请参考Part 1#xff1b;第5-6章、附录、认证考试、参考资源等内容#xff0c;请参考Part 3。 流动的技术实践 持续交付#xff1a;降低在生产环境中部署和发布变更的风险。包括#xff1a;打好自动化部署流水…一篇文章显得略长本文对应第3-4章。前言、第1-2章请参考Part 1第5-6章、附录、认证考试、参考资源等内容请参考Part 3。 流动的技术实践 持续交付降低在生产环境中部署和发布变更的风险。包括打好自动化部署流水线的基础、确保团队能够使用自动化测试持续验证代码是否处于可部署状态、保证开发人员每天都将代码提交到主干、构建有利于实现低风险发布的环境和代码。 下面这些DevOps实践能有效缩短创建类生产环境的前置时间。持续测试可以为每个团队成员快速提供反馈让小型团队能够安全、独立地开发、测试和向生产环境部署代码从而使向生产环境的部署和发布成为日常工作的一部分。 为部署流水线奠定基础 为了使工作快速可靠地从开发流向运维应当保证价值流的每个阶段都使用类生产环境。 部署流水线的目标就是能够基于VCS中的信息重复搭建整套生产环境。 在过程中保证质量而不是事后检查质量。 这些问题可以归咎于不一致的环境和没有将变更纳入VCS。 按需搭建开发环境、测试环境和生产环境 应用统一的代码仓库 必须把下列资源也纳入版本控制系统 应用的所有代码和依赖项库、静态内容等任何用于创建数据库模式的脚本、应用的参考数据等所有用于搭建环境的工具和工件VMware或AMI虚拟机模板、Puppet或Chef配置模块等任何构建容器所使用的文件Docker、Rocket、Compose文件等所有支持自动化测试和手动测试的脚本任何支持代码打包、部署、数据库迁移和环境置备的脚本所有项目工件需求文档、部署过程、发布说明等所有云平台配置文件AWS Cloud Formation模板、Microsoft Azure Stack DSC文件OpenStack HEAT模板文件创建支持多种基础设施服务企业服务总线、数据库管理系统、DNS区域文件、防火墙配置规则和其他网络设备所需的任何其他脚本或配置信息。 使基础设施的重建更容易 运行在类生产环境里才算完成 一般来说部署的间隔时间越长软件质量越差。 完成指不仅实现功能正确的代码且在每个迭代周期结束时已经在类生产环境中集成和测试可工作和可交付的代码。 实现快速可靠的自动化测试 对代码和环境做持续构建、测试和集成 部署流水线工具Jenkins、ThoughtWorks GoCD、Concourse、Bamboo、Microsoft Team Foundation Server、TeamCity和GitLab CI以及基于云的解决方案例如Travis CI和Snap。 构建快速可靠的自动化测试套件 自动化测试从快到慢分为 单元测试通常独立测试每个方法、类或函数。目的是确保代码按照开发人员的设计运行。由于诸多原因如需要进行快速和无状态的测试通常会使用打桩stub out的方式隔离数据库和其他外部依赖如把函数修改为返回静态的预定义值而不是调用数据库。验收测试通常整体测试应用确保各个功能模块按照设计正常工作例如符合用户故事的业务验收标准API能正确调用而且没有引入回归错误即没有破坏以前正常的功能。JezHumble和David Farley认为单元测试和验收测试的区别在于单元测试的目的是证明应用的某一部分符合程序员的预期……验收测试的目的则是证明应用能满足客户的愿望而不仅仅是符合程序员的预期。”在构建的版本通过单元测试后部署流水线就对其执行验收测试。任何通过验收测试的构建版本通常都可用于手动测试例如探索性测试、用户界面测试等和集成测试。集成测试保证应用能与生产环境中的其他应用和服务正确地交互而不再调用打桩的接口。Jez Humble和David Farley写道“大部分系统集成测试工作都是在部署应用的新版本并使它们能正常协作。在这种情况下冒烟测试通常是指针对整个应用进行的一组成熟的验收测试。”只有通过单元测试、验收测试的版本才能执行集成测试。集成测试通常是脆弱的应该尽量减少其次数并且要在单元测试和验收测试期间尽可能多地找出缺陷。一个至关重要的架构需求是在执行验收测试时能够调用虚拟或模拟的远程服务。 尽早发现错误最快速的测试应该尽可能多地发现错误。如果大多数错误都是在验收测试和集成测试阶段发现的那么开发人员收到反馈的速度要比单元测试发现错误时慢上好几个数量级——集成测试需要用到稀缺且复杂的集成测试环境每次只能供一个团队使用因此反馈更慢。 在部署流水线失败时拉下安灯绳 并行测试 TDDTest Driven Development测试驱动开发。极限编程。的 3个步骤 确保测试失败为想要增加的功能编写测试用例检入测试用例确保测试通过编写实现功能的代码直到测试通过检入代码重构新旧代码优化结构确保测试都能通过再次检入代码。 ATDD基于TDD验收测试驱动开发Acceptance Test Driven Development 瀑布式Scrum反模式water-Scrum-fall anti-pattern表面上采用敏捷开发实践但实际上所有测试和缺陷修复仍然在项目快结束时才进行。 应用和实践持续集成 VCS中分支的作用 让开发人员可并行地工作在系统的各个组成部分避免开发人员提交的代码对主干trunkmaster或mainline的稳定性造成影响或引入错误 当开发人员的数量和VCS中的分支个数增加时自动化测试会变得更加重要。开发人员在自己的分支上独自工作的时间越长就越难将变更并入主干。当分支个数和每个分支上的变更数都在增加时合并难度会骤增。 Gary Gruver如果没有自动化测试持续集成只能产生一大堆没有经过编译而且不能正确运行的垃圾。 分支策略可分为以下两类 提高个人生产力所有人都在自己的分支上工作。每个人都独立地工作不能干扰其他人然而代码合并将是一场噩梦。协作将变得相当困难每个人都不得不谨小慎微地合并代码即便是完成系统里最小的部分。提高团队生产力所有人都在同一个区域里工作。并没有分支只有一条很长、不可被中断的主干也没有规则因此代码的提交过程很简单。但任何一次提交都有可能破坏整个项目同时导致项目中断。 大批量合并的副作用合并难度越大开发人员就越不可能也越不愿意改进和重构代码重构很可能导致其他所有人返工。人们就更不愿意去修改那些在整个代码库中都有依赖项的代码。 解决大批量合并问题的对策是应用持续集成和基于主干的开发实践让每个开发人员每天都至少向主干提交一次代码。 门控提交对部署流水线进行配置拒绝接受任何使系统偏离可部署状态的提交如代码变更或环境变更。即部署流水线要确认所提交的变更能成功合并和正常构建并且在合并到主干之前就已经通过所有的自动化测试。如果测试失败则开发人员将收到通知这样就可以在不影响价值流中的其他人的情况下自己解决问题。 自动化和低风险发布 持续部署要求代码的部署操作是自动化、可重复和可预测的。 自动化部署流程尽可能地简化和自动化手动步骤。不但要缩短前置时间而且还要尽可能减少交接次数从而降低出现错误和流失知识的可能性。 部署流水线的需求 用相同的方式处理所有环境的部署通过对所有环境采用相同的部署机制可提高生产环境部署成功率对部署执行冒烟测试在部署过程中应该测试依赖的所有系统是否能正常访问并通过单次测试看看系统是否能正常工作。如果以上任何一个测试失败部署就是失败的维持环境的一致性创建一步搭建环境的流程必须持续保证这些环境的搭建方式是一致的。 理想的流程 构建部署流水线必须基于VCS构建可部署到任何环境的软件包测试任何人都应该能够在工作站或测试系统中运行任何一个自动化测试套件部署任何人都应该能够将这些软件包部署到具有访问权限的任何环境通过执行已提交到VCS中的脚本来完成部署。 自动化部署必须具备如下能力 保证在持续集成阶段构建的软件包可以部署到生产环境中使生产环境的就绪情况一目了然为能在生产环境中部署的任何代码建立一键式和自助式的发布机制自动记录审计和合规管理所需的相关内容包括在哪台机器上运行命令运行什么命令是谁授权的以及结果如何通过冒烟测试验证系统正常工作数据库连接字符串等配置正确为开发人员快速提供反馈能够尽快了解部署结果。 只有进行更频繁的部署才能实现流畅和快速的工作流。为了实现这一点需要将生产环境部署和特性发布解耦。 部署和发布是不同的动作且有着截然不同的目标 部署在特定的环境中安装指定版本的软件。部署可能与某个特性的发布相关也可能无关发布把一个或一组特性提供给所有客户或部分客户。代码和环境架构要能够满足这种要求特性发布不需要变更应用的代码。 如果部署周期过长会限制向市场频繁地发布新特性的能力。假如能够做到按需部署那何时向客户发布新特性就变成业务和市场的决策而不再是技术决策。通常使用的发布模式有以下两种 基于环境的发布模式在两个或更多的环境中部署系统但实际上只有一个环境处理客户流量。将新的代码部署到非生产环境中再把生产流量切换到这个环境。一般只需要对应用做很少的改变或几乎不用改变包括蓝绿部署、金丝雀发布和集群免疫系统。基于应用的发布模式对应用进行修改从而通过细微的配置变更选择性地发布或开放应用特性。例如可以通过特性开关逐渐地开放新特性——先开放给开发团队再开放给所有内部员工然后开放给1%的客户或者在确认特性完全符合设计后直接发布给全体客户。所谓的黑启动技术——在生产环境里将所有特性都部署完毕并在发布前用生产环境的流量做测试。例如在发布前的几周里用生产环境的流量来测试新特性以便在正式发布之前发现和解决所有问题。 蓝绿部署最简单支持回滚。 金丝雀发布监控软件在每个环境中的运行情况。一旦出现问题就回滚否则就在下一个环境中进行部署。 集群免疫系统扩展金丝雀发布将生产环境的监控系统和发布流程联系起来并在面向用户的生产系统的性能超出预定范围时如新用户的转化率低于15%20%自动回滚代码。 基于应用的发布模式更安全通过代码来更灵活、更安全地向客户逐一发布新特性。 基于应用的发布模式主要是通过特性开关来实现的。特性开关机制使我们能在不进行生产环境代码部署的情况下选择性地启用和禁用特性。通过特性开关可以将应用的特性向某些特定用户例如内部员工和某些客户群开放。 特性开关的优势 轻松地回滚只需更改特性开关的设置就可以在生产环境中快速安全地禁用出问题或造成服务中断的特性。在非频繁部署的情况下它的价值更大——关掉某一个特性通常要比回滚整个版本容易得多。缓解性能压力当服务遭遇极高的负载时通常需要扩容系统更糟糕的是可能导致生产环境中的服务中断。不过可以使用特性开关来缓解系统的性能压力。换句话说可以通过减少可用的特性来支持更多的用户例如减少使用某特性的客户数量禁用推荐等CPU密集型特性等等。采用面向服务架构提高恢复能力即便某个特性依赖于还没有上线的服务仍然可以将这个特性部署到生产环境中然后用特性开关把它先隐藏起来。当所依赖的服务上线后就可以启用这个特性。当所依赖的服务中断时也可以关闭该特性这样做不但可以和下游的故障服务隔离同时还可以保持应用的其余部分正常运行。 黑启动 《持续交付发布可靠软件的系统方法》值得一读。 持续交付所有开发人员都在主干上进行小批量工作或者在短时间存在的特性分支上工作并且定期向主干合并同时始终让主干保持可发布状态并能做到在正常的工作时段里按需进行一键式发布。开发人员在引入任何回归错误时都能快速得到反馈。一旦发现这类问题就立即解决从而保持主干始终处于可部署状态。 持续部署在持续交付的基础上由开发或运维人员自助式地定期向生产环境部署优质的构建版本这意味着每天每人至少做一次生产环境部署甚至每当开发人员提交代码变更时就触发一次自动化部署。 持续交付是持续部署的前提条件就像持续集成是持续交付的前提条件一样。持续部署更适用于交付线上的Web服务而持续交付适用于几乎任何对质量、交付速度和结果的可预测性有要求的低风险部署和发布场景包括嵌入式系统、商用现货产品和移动应用。 降低发布风险的架构 能提高生产力、可测试性和安全性的架构 架构原型单体架构与微服务 单体架构的本质并不坏。事实上在产品生命周期的早期阶段单体架构通常是最佳的选择。 关于架构转型亚马逊的几个经验教训 严格遵从面向服务理念的架构设计能完美地实现隔离从而达到前所未有的掌控水平。禁止客户端直接访问数据库使在不涉及客户端的情况下提高服务状态的可扩展性和可靠性成为可能。在切换到面向服务的架构后开发和运维流程将受益匪浅。服务模式进一步强化了以客户为中心的团队理念。每个服务都有一个与之对应的团队该团队对服务全面负责从功能规划到架构设计、构建和运维。 安全地演进企业架构 TODO 反馈的技术实践 建立能发现并解决问题的遥测系统 建设集中式监控架构 建立生产环境的应用程序日志遥测 日志级别 调试级别此级别的信息是相关应用程序中发生的所有事件最常用于调试的时候。通常调试日志在生产中是禁用的但在故障诊断期间要暂时启用。信息级别此级别的信息包括用户触发的或系统特定的操作例如“开始信用卡交易”。警告级别此级别的信息告诉我们可能的出错情况例如调用数据库花费的时间超过某个特定时长。可能会因此而触发报警和故障诊断过程而其他日志消息会有助于更好地理解事件的原因。错误级别此级别的信息侧重于错误状况例如API调用失败内部出错。致命级别此级别的信息告诉我们何时发生了中断情况例如网络守护进程无法绑定网络套接字。 使用遥测指导问题的解决 平均清白证明时间即花多长时间说服其他人不是我们造成中断。一种指标 将建立生产遥测融入日常工作 建立自助访问的遥测和信息辐射器 Information Radiator信息辐射器。定义团队放置在一个非常显眼位置上的手写、绘制、印刷或电子信息展示让所有团队成员以及路过的人都可以快速浏览最新信息自动化测试次数、速率、事故报告、持续集成状态等。这个想法起源于丰田生产系统。 发现和填补遥测的盲区 以下层级的度量指标 业务级别示例包括交易订单的数量、产生的营业额、用户注册数、流失率、A/B测试的结果等。应用程序级别示例包括事务处理时间、用户响应时间、应用程序故障等。基础架构级别如数据库、操作系统、网络、存储示例包括Web服务器吞吐量、CPU负载、磁盘使用率等。客户端软件级别如客户端浏览器上的JavaScript、移动应用程序示例包括应用程序的出错和崩溃、用户端的事务处理时间等。部署流水线级别示例包括构建流水线状态例如各种自动化测试套件的红色或绿色状态、变更部署前置时间、部署频率、测试环境上线状态和环境状态。 分析遥测数据以更好地预测故障和实现目标 异常检测首先在计算集群节点总数一定的情况下计算出当前正常值然后识别出与之不符的节点并将它们从生产环境中移除。 用均值和标准差识别潜在问题 通过提高信噪比、关注差异值或异常值建立更好的告警。 钟形曲线中间的垂直线是均值由其他垂直线表示的第一、第二和第三标准差分别包含68%、95%和99.7%的数据。 标准差的常见用途是定期检查数据集的某个度量如果与均值有显著差异就告警。如当每天未经授权的登录次数比均值大三个标准差时就告警。只要这个数据集呈高斯分布就预计只有0.3%的数据点会触发告警。 异常状态的处理和告警 生产环境事故的潜在征兆指标 应用级别网页加载时间正在增加等操作系统级别服务器闲置内存不足、磁盘空间不足等数据库级别数据库事务处理时间超出正常值等网络级别负载均衡器背后运行的服务器数量下降等。 非高斯分布遥测数据的问题 TODO 应用异常检测技术 TODO 应用反馈实现安全部署 代码部署恐惧。 通过提供更快和更频繁的反馈减少部署工作的批量大小可以让工程师获得代码部署的安全感进而重拾信心。 仅仅实现部署流程的自动化是不够的必须要将生产遥测的监控融入到部署工作中同时还要建立文化规范那就是每个人都对整个价值流的健康承担着相同的责任。 通过遥测使部署更安全 部署过程中积极地监控软件功能相关的度量指标。 部署出错的解决方法 使用特性开关关闭出错的功能前向修复为了修复缺陷再次修改、提交、部署代码到生产环境回退回滚到上一个版本 开发和运维共同承担值班工作 让价值流中的所有人共同承担处理运维事故的下游责任。让开发人员、开发经理和架构师轮流和运维团队共同值班。 产品功能完成的定义所有功能都在生产环境中按照设计正常地运行没有引起重大的故障也没有引发计划外的运维或开发工作。 不管团队的组织结构怎样基本原则是不变的当开发人员获得应用程序在生产环境中运行的反馈时包括故障的修复状况他们与客户之间的距离拉近这会使价值流中的所有人都受益。 让开发人员跟踪工作对下游的影响 交互和用户体验设计中最强大的技术之一是情境访谈。 让开发去使用他们开发出的产品。 通过进行用户体验观察能够在源头保证质量并对价值流中的其他团队成员产生同理心。理想情况下用户体验观察有助于我们创建应用的非功能需求并将其放入共享的待办工作中去最终我们可以主动地将它们落实到构建的所有服务中。 让开发人员自行管理生产服务 谷歌的实践让开发团队在生产环境中管理他们开发的服务然后才交由集中的运维团队管理。通过让开发人员自己负责部署工作并在生产环境中提供支持他们所开发的产品更有可能顺利地过渡给运维团队去管理。 服务发布指南 缺陷计数和严重性应用程序是按设计运行的吗告警的类型/频率在生产环境中应用程序所产生的告警数量是否太多无法得到支持监控覆盖率监控覆盖的范围是否够大能够为恢复故障服务提供足够的信息系统架构服务松耦合的程度是否足以支持生产环境中高频率的变更和部署部署过程在生产环境中代码部署的过程是不是可预测的、确定性的和足够自动化的生产环境的整洁是否有迹象表明生产习惯已经足够好可以让其他任何人提供生产支持 这项服务是否要遵从任何监管目标 服务是否产生大量的收益服务的用户流量或停机/损害成本是否很高服务是否存储付款卡持有者信息如信用卡号或个人身份信息如社会安全号码或病人护理记录是否存在可能产生监管、合同义务、隐私或声誉风险的其他安全问题服务是否有任何其他监管或合同要求如美国出口监管、PCI-DSS、HIPAA等 服务回传机制当生产环境中的一个服务变得非常脆弱时运维部门能把支持这个服务的责任交回给开发部门。 谷歌SRESite Reliability Engineer。 LRRLaunch Readiness Review上线就绪审核。 HRRHand-off Readiness Review交接就绪审核。 谷歌在将任何新服务公开给客户并且接收生产流量之前必须进行LRR而且要签字验收而当将服务转换到运维管理状态后通常是在LRR几个月之后执行HRR。LRR和HRR审核清单其实是相似的但是HRR更加严格并且验收标准更高而LRR是由产品团队自行执行并上报的。
假设驱动的开发和A/B测试 在软件项目中开发人员往往花几个月或几年的时间开发功能期间经历多次发布却从未确认过业务需求是否得到满足某个功能是否达到所期望的效果甚至是否被用过。 开展最廉价、最快速的实验通过用户研究来验证设想的功能能否产生预想的业务成果。我们可以使用假设驱动的开发、客户获取渠道和A/B测试等技术。 越快地实验、迭代并将反馈集成到产品或服务中我们就可以越快地学习和超越竞争对手。集成反馈的速度取决于部署和发布软件的能力。 A/B测试简史 A/B测试技术是在直效营销中率先使用的它是两大类营销策略之一。另一类称为大众营销或品牌营销通常通过向公众投放尽可能多的广告来影响人们的购买决策。 有良好文档记录的A/B测试案例包括竞选筹款、互联网营销和精益创业方法论。 在功能测试中集成A/B测试 A/B测试也称为在线控制实验和拆分测试。在实验的过程中还支持多个变量从而观察变量之间的相互作用即多变量测试。 很多时候开发团队只知道实现产品经理或项目经理分发的功能。但是这些功能对公司的价值很可能为零甚至为负因为它们增加代码的复杂度随着时间的推移应用维护的成本将增加软件也变得更加难以修改。构建这些功能往往是以牺牲真正有价值的功能机会成本为代价的。 在发布中集成A/B测试 通过在生产环境中快速轻松地按需部署利用特性开关将软件的多个版本同时交付给多个用户群可以进行快速、迭代的A/B测试。 具备A/B测试功能的一些框架 FeatureEtsy开源支持A/B测试在线调整能对实验组进行限流OptimizelyGoogle Analytics 在功能规划中集成A/B测试 一旦拥有支持A/B功能发布和测试的基础设施还必须确保产品经理将每个功能都视为一个假设并基于在生产环境中实际的用户实验结果来证明或反驳这些假设。 建立评审和协作流程以提升当前工作的质量 PRPull Request。 GitHub Flow的5个步骤 工程师为实现一项新功能需求基于主干检出一个命名良好的分支工程师提交代码到本地分支并定期将工作成果推送到远端服务器的同名分支上当需要反馈或帮助或准备将分支代码合并到主干时得发起一个PR在他们获得期望的评审并通过必要的审核后即可将代码合并到主干一旦将代码变更合并进主干就可将其部署到生产环境。 变更审批流程的危险 Knight Capital15分钟的部署事故造成4.4亿美元的交易损失生产服务无法停止。推荐阅读Project Failure Case Study Knight Capital。 在低信任度的指挥与控制型文化环境中这些变更控制和测试实践反而会增加问题复发的几率甚至造成更严重的后果。 过度控制变更的潜在危险 传统的变更控制可能会导致意想不到的后果例如延长交付时间降低部署过程中反馈的强度和即时性。 TPS最了解问题的人通常是离问题最近的人。让距离工作较远的运维领导层来做相关审批的步骤这实际上会降低工作成功的概率。 变更的协调和排程 当多个团队在共享依赖关系的系统上工作时就可能需要协调变更以确保不会相互干扰。组织架构越松耦合组件团队之间需要沟通和协调的事情就越少。 在松耦合的架构里当多个团队每天进行数百次独立部署时变更彼此干扰的风险可能依然存在。缓解风险的方式 聊天室碰头会技术性的保障措施如冗余备份系统、故障切换、综合测试和变更模拟理想情况下。 变更的同行评审 代码评审和变更评审在本书是一个意思都是同行之间进行的评审Peer Review。 保持小批量尺寸的原则也适用于代码评审。 代码评审的指导原则 将代码提交到主干以前必须要有同行来评审变更每个人都应该持续关注其他成员的提交活动以便识别和审查出潜在的冲突定义哪些变更属于高风险变更从而决定是否需要请领域专家来进行审查如果同行看不懂PR说明提交的变更尺寸太大那变更就需要分解成多个较小的变更来多次提交。 代码评审的几种形式 结对编程程序员结对地在一起工作。肩并肩在一名程序员编写一段代码后评审程序员接着就逐行阅读他的代码。电子邮件送审在代码被签入到代码管理系统中后系统就立刻自动向评审者们邮寄一份代码。工具辅助评审如Gerrit、GitHub PR等或源码仓库如Mercurial、Subversion、Atlassian Stash和Atlassian Crucible等提供的类似功能。 人工测试和变更冻结的潜在危害 引入自动化测试。 利用结对编程改进代码变更 结对编程两名软件开发工程师同时在同一台工作站上工作的开发方法。由极限编程和敏捷开发广泛推广的实践。 结对模式 扮演驾驶者角色的工程师负责编写代码另一名作为导航员、观察者或督导者负责检查驾驶者正在进行的工作。测试驱动开发一名工程师编写自动化测试另外一名工程师编写代码。 结对编程还能有益于知识在组织内的传播以及信息在团队内部的流动。 一个好的表明评审过程有效的PR的基本要素必须足够详细地说明变更的原因、如何做的变更以及任何已识别的风险和应对措施。 消除官僚流程 许多公司仍然存在着由来已久的、动辄需要数月的审批流程。此时必须重新设计流程才便更快、更安全地实现目标。