新書推薦：
《
佛教文化十八讲
》
售價：HK$
89.7
《
背弃圣约：处于考验中的美国公民宗教（社会学名著译丛）
》
售價：HK$
46.0
《
卖掉法拉利的高僧
》
售價：HK$
70.9
《
次经导论
》
售價：HK$
177.6
《
叔本华暮年之思
》
售價：HK$
69.6
《
故纸留痕：抗日战争时期澳门报刊资料选辑
》
售價：HK$
345.6
《
玩转Photoshop（零基础快速上手，全彩赠视频）
》
售價：HK$
57.6
《
故事力：TED演讲者助力，当代青年克服表达难题（两位TED专业讲者教你掌握故事五大力）
》
售價：HK$
81.6
|
| 內容簡介： |
|
DevOps是开发运维一体化的软件工程思想，DevOps尝试打破部门墙，构建一个协同的IT建设运行环境，通过工具链形成数据关联的规范化、规模化的软件持续交付流水线，从而助力企业业务的敏捷发展。本书用9章内容，结合项目实战案例和业界主流工具，从思想、实践方法、工具技术、案例等方面阐述了DevOps在传统规模化IT组织中实施落地的方法。本书适合IT主管、项目经理、开发、测试、配置管理、运维等IT从业人员阅读。
|
| 關於作者： |
|
陈能技拥有16年IT从业经验，历任测试工程师、QA、项目经理、培训讲师、咨询顾问、架构师、技术总监等职位，亲历手工作坊式软件团队到专业化交付工程团队的发展过程。现任新维数联（北京）科技有限公司DevOps售前顾问及解决方案总监、北京量子仿真科技有限公司产品经理、工信部 ITSS工作组DevOps专家组组长。专注于研究DevOps以及软件专业化交付能力，目前正在带领团队致力于打造覆盖软件全生命周期交付的DevOps产品AutoChain，以及定位于让天下没有难测的软件为产品价值导向的接口仿真验证平台。付勇拥有18年IT从业经验，先后担任过系统管理员、研发工程师、项目经理、售前顾问、产品经理、研发总监、CTO等职位。主要专注于金融、运营商等行业客户的监控运维体系设计与系统建设，近5年主要从事大规模组织DevOps的体系设计、咨询与自动化工具链的研究工作，主导过多个金融行业DevOps项目的咨询及建设工作，积累了较为丰富的DevOps体系设计与落地建设经验。目前专注于大规模组织DevOps工程实践方面的研究，在代码版本管理策略、持续集成、应用与数据库脚本发布等领域有着深刻理解和实践经验，同时研究的专业领域还包括自动化测试、服务虚拟化、自动化监控等。
|
| 目錄：
|
第一部分思想篇
第1章软件工厂2
1.1软件的生产力2
1.2软件工厂软件的标准化生产4
1.2.1标准化生产模式需要一个集成底座PaaS4
1.2.2标准化软件生产流水线6
第2章DevOps思想8
2.1DevOps思想与生产流水线8
2.1.1DevOps的起源8
2.1.2DevOps对软件工厂的启发9
2.1.3从DevOps实践原则看软件生产工艺化水平的提高10
2.1.4软件工厂模式下对生产工具发展的促进作用10
2.2从瀑布到敏捷11
2.2.1传统项目管理问题12
2.2.2向互联网企业学习的敏捷13
2.2.3敏捷的起源14
2.2.4瀑布模型15
2.2.5传统企业不可能全盘敏捷化15
2.2.6从版本上线过程管理看敏捷与瀑布16
2.2.7敏捷的前提是不敏捷17
2.3敏捷与DevOps核心思想18
2.3.1增量开发与测试18
2.3.2持续集成与持续交付19
2.3.3自动化21
2.4规模化的敏捷22
2.4.1从敏捷项目管理到敏捷项目集群管理22
2.4.2企业规模化敏捷思想24
2.4.3规模化敏捷方法SAFe25
2.4.4规模化敏捷开发的最佳实践28
2.5企业规模化敏捷与软件工厂31
2.5.1软件生产环境31
2.5.2软件工厂生产环境管理开发测试云33
2.5.3整合环境仿真37
2.5.4不可忽略的办公环境因素43
2.5.5软件工厂质量检测深度自动化测试装置45
第二部分实践方法篇
第3章DevOps体系的建立49
3.1构建DevOps流水线，打通开发测试运维持续交付通道49
3.2敏捷开发知识体系50
3.3Scrum框架51
3.3.1Scrum的3类角色52
3.3.2Scrum的3份工件52
3.3.3Scrum的5项活动53
3.3.4Scrum的5个价值观54
3.4敏捷、DevOps与协作54
3.5开发域DevOps实践55
3.5.1敏捷需求55
3.5.2传统需求分析55
3.5.3敏捷需求方法57
3.5.4面向敏捷的架构设计61
3.5.5向微服务架构迁移的基本做法63
3.5.6向微服务架构迁移的低风险演进方法64
3.5.7微服务架构设计模式74
3.5.8开发敏捷77
3.5.9分支策略77
3.5.10依赖包管理79
3.5.11技术债务80
3.5.12技术债务的形成80
3.5.13技术债务的分类83
3.5.14技术债务与质量投资84
3.5.15技术债务处理方法85
3.5.16持续集成88
3.5.17持续集成最佳实践91
3.5.18持续集成最佳实践持续编译92
3.5.19持续集成最佳实践持续代码检查92
3.5.20持续集成最佳实践持续测试93
3.5.21持续集成最佳实践持续部署94
3.5.22持续集成最佳实践持续报告94
3.5.23企业持续集成实施方法95
3.5.24持续集成实施案例介绍96
3.6测试域DevOps实践96
3.6.1敏捷测试环境管理96
3.6.2业界关于测试环境管理的实践98
3.6.3测试如何纳入持续集成体系中100
3.6.4敏捷测试方法与传统测试方法的不同之处105
3.6.5敏捷测试人员的定义106
3.6.6敏捷测试过程管理107
3.6.7敏捷测试团队管理112
3.7运维域DevOps实践113
3.7.1敏捷基础设施113
3.7.2自动化部署113
3.7.3自动化部署的要素114
3.7.4部署常见场景及问题115
3.7.5部署服务工具链116
3.7.6资源部署117
3.7.7自动化资源部署117
3.7.8应用部署119
3.7.9应用交付容器化120
3.7.10应用容器化改造121
3.7.11不中断服务的部署方法121
3.7.12敏捷运维125
第4章DevOps的有效实践129
4.1敏捷模式与传统企业研发模式的结合129
4.2敏捷模式与传统ISO、CMMI标准规范的兼容131
4.2.1需求获取131
4.2.2方案制定（或技术评估）132
4.2.3生产任务排期135
4.2.4Sprint 0迭代前准备135
4.2.5Sprint 0基础框架搭建143
4.2.6迭代实施143
4.2.7验收测试154
4.2.8投产155
4.3敏捷与DevOps基础实践155
4.3.1SRE与发布工程155
4.3.2配置管理版本管理161
4.3.3配置管理发布包制作规范165
4.3.4缺陷管理167
4.3.5缺陷预防168
4.3.6迭代周期的时间169
4.4敏捷与DevOps反模式170
4.4.1急功近利170
4.4.2跨部门协作的浪费172
4.4.3持续集成坏味道176
4.4.4手工完成所有部署178
4.4.5开发与运维各一套自动化部署系统178
4.4.6重建数据库比较困难179
第三部分工具技术篇
第5章精准测试技术182
5.1什么是精准测试技术182
5.1.1传统测试方法面临大型软件时的问题与瓶颈182
5.1.2传统白盒测试方法的问题183
5.1.3开发团队和测试团队协同工作难183
5.1.4精准测试方法解决的问题184
5.1.5精准测试的工作模式与工作原理185
5.2精准测试云平台186
5.2.1测试复杂度分析186
5.2.2测试复杂度种类187
5.2.3覆盖率分析188
5.2.4软件内部逻辑结构可视化192
5.2.5函数列表功能说明196
5.2.6覆盖率可视化197
5.2.7动态实时测试监控199
5.2.8缺陷管理系统199
5.2.9Bug与崩溃代码级捕获201
5.2.10双向追溯202
5.2.11多版本与累计覆盖率205
5.2.12智能的回归测试用例选取分析算法206
5.2.13测试用例的聚类分析算法207
5.3精准测试与度量分析208
5.3.1获取度量信息208
5.3.2项目度量指标208
5.3.3项目汇总211
5.3.4测试用例按日趋势图213
5.3.5测试用例测试用例列表215
5.3.6测试人、机218
5.3.7测试缺陷Bug信息汇总219
5.3.8测试缺陷Bug详细列表220
5.3.9覆盖率按日增长趋势图221
5.3.10函数、类、文件覆盖率统计223
5.3.11函数、类、文件复杂度和覆盖率关系图223
5.3.12覆盖率列表224
5.3.13函数、类、包复杂度统计226
5.3.14测试覆盖率漏洞的智能分析227
第6章双模发布管理平台的设计与应用229
6.1产生背景229
6.1.1传统企业数字化转型浪潮下的双模挑战229
6.1.2双模发布管理平台230
6.2双模发布管理平台设计231
6.2.1设计思路231
6.2.2架构设计233
6.3案例及功能说明234
6.3.1案例背景介绍235
6.3.2痛点诊断及建设目标236
6.3.3功能说明236
第7章整合环境仿真技术252
7.1服务虚拟化技术252
7.2Lisa解决方案特色253
7.3采用Lisa方案的预期效果254
7.4Lisa实施和服务模式举例256
第8章容器技术259
8.1容器与Docker259
8.2应用容器化261
8.3Dockerfile 命令详解266
8.4Dockerfile使用建议270
8.5应用上云容器271
8.5.1上云应用的场景271
8.5.2软件和硬件的限制272
8.5.3应用架构的限制272
8.5.4应用上云建议274
8.6容器化应用开发规范275
8.6.1应用预编译275
8.6.2热点数据缓存277
8.6.3应用无状态化277
8.6.4应用上配置的定时任务需与应用分离278
8.6.5应用使用固定的服务监听端口278
8.6.6主机名和服务端口获取278
8.6.7数据库连接池279
8.6.8应用日志279
8.6.9应用中间件选型279
8.6.10应用环境配置规范280
8.6.11硬件负载280
8.6.12不要在容器中存储数据281
8.6.13不要发布两个应用281
8.6.14清除不必要的包和文件281
8.6.15不要在容器中运行多个进程281
8.6.16不要在镜像中存储凭据、使用环境变量281
8.6.17使用非root用户运行281
8.6.18不要依赖IP地址282
8.6.19服务间接口调用使用TCP和HTTP282
8.7容器化应用迁移实施方案282
8.7.1应用迁移的流程282
8.7.2信息收集和业务分析284
8.7.3容器镜像制作289
8.7.4功能验证291
第四部分案例篇
第9章持续集成实践案例294
9.1项目背景294
9.2解决方案295
9.2.1持续集成简介295
9.2.2应用持续集成解决某局的开发项目问题296
9.2.3持续集成基础技术框架297
9.2.4方案优势302
|
| 內容試閱：
|
未来的企业都是软件企业，是面向互联网、物联网、大数据和人工智能的企业，软件作为信息系统的核心部分一直面临着专业化交付的问题，如何才能像工厂生产零部件和整机一样可以流水线作业、批量化生产和交付，是IT从业人员一直追求的目标。
从早年的ISO、CMMI，到近年来的敏捷、精益，再到最近所倡导的DevOps，其实都在尝试解决软件行业的专业化交付问题。看起来ISO、CMMI有点过于保守、笨重、僵化，而敏捷又过于灵活、难以规模化应用，直到最近我们看到DevOps所倡导的开发、测试、运维一体化协同，以及自动化流水线的构建，结合新兴的技术（如微服务、容器等），我们认为这是非常有希望解决规模化组织下的专业化交付问题的。
陈能技在软件专业化交付这个领域探索和实践了十几年，将自己的所见、所思、所想、所践、所得集结成册，共享给行业同人，实属可贵、可敬。
润和软件自成立至今始终坚持国际化专业化高端化的发展战略，公司的主营业务为向国内外客户提供基于业务解决方案的软件和信息技术服务，业务聚焦在金融信息化智能电网信息化智能终端嵌入式软件智能供应链信息化系统集成及运维服务等专业领域，拥有全球软件服务能力，能够为客户提供全面、即时、高效的软件和信息技术服务。
我们将借助DevOps（开发运维一体化）、SAFe（规模化）等新兴的软件交付方法，打造和持续完善我们的专业化交付团队，为国内外客户提供优质的IT服务。
陈 斌
润和软件总裁
前 言
DevOps代表了IT领域最新的发展趋势，传统金融IT部门在尝试DevOps转型中碰到各种问题和诸多误区，我们在DevOps领域深耕多年，结合金融企业实际问题进行各种探索与实践，提出从流水线设计、自动化、度量等多个维度进行DevOps体系建设，从而形成企业IT专业化交付能力的实践方法，构建全生命周期双模软件自动化生产发布与智能化运维的BTO蓝图。
我们将这几年在传统企业落地实施敏捷、DevOps的经验集结成书，分享给大家，希望能够帮助大家在DevOps的转型中少走一些弯路。
在本书即将出版之际，我想谈谈这几年从事DevOps领域业务的一些感悟，不管是帮助某运营商企业规划设计DevOps体系，还是在某科技公司担任架构师设计DevOps工具平台，或者是现在所专注的工作DevOps解决方案咨询和售前，我始终在思考一个问题，即如何将看似先进的DevOps思想和理念成功地导入国内的传统企业。
不管是不是敏捷、是否DevOps，始终要解决如下几个核心问题。
1. 流程改进
如何使流程更加精益，以及通过杜绝浪费提高效率。
2. 工具自动化
如何利用工具实现流程的自动化改进，使其具有可重复性及可扩展性，同时减少错误的发生。
3. 平台及环境
如何为从需求到生产上线全过程中各种应用的交付流水线，搭建更具弹性、灵活、可伸缩、可配置的平台及环境。
4. 文化
尤其是如何塑造信任、沟通、协作的文化氛围。
DevOps的实施一定要有业务目标。通常业务线对IT部门的要求包括快速交付、敏捷、创新、优质、低成本。因此，IT部门需要想办法建立以下能力：
? 价值交付时间。
? 部署速度。
? 成本节约交付时间。
? 成本节约测试时间。
? 提高测试覆盖率。
? 提高环境利用率。
? 最大限度地缩短部署所需的停机时间。
? 最大限度地减少部署所花费的时间。
? 尽可能地减少部署应用的回滚。
? 提高再现与缺陷修复能力。
? 最大限度地缩短产品问题的平均修复时间（MTTR）。
? 缩短缺陷周期。
本书分为思想篇、实践方法篇、工具技术篇、案例篇四部分，把传统企业实施DevOps会碰到的困惑，在开发、测试、运维三大领域各有哪些DevOps最佳实践，以及如何结合开源或商业工具打造交付流水线工具链，分别进行了阐述，希望对你在实施DevOps转型过程中实现上述业务目标有所帮助。
本书出版之时恰逢国内DevOps领域蓬勃发展之际，DevOps相关的峰会已经举办了两年，我们一直关注会议的各类议题，发现从前几年的大谈概念为主，到近期大家纷纷聚焦在落地实践方法、工具链的打造、各种探索实验总结、国内外不同行业的实践案例等，这表明DevOps已经开始逐步深入人心，逐步地帮企业解决IT中的各类问题，走向更高级的发展阶段。
在出版本书的过程中，得到了所在公司新维数联（北京）科技有限公司（前身为天维科技）的大力支持，书中提炼的很多实践经验及工具平台设计理念来源于该公司的项目交付团队及产品团队。第6章双模发布管理平台的设计与应用的内容主要来自公司的DevOps产品线经理付勇两年多的实战经验总结，该产品AutoChain已经获得业界领先地位，更获得了传统金融行业（银行、保险）客户的认可，知名度比较高，值得大家参考借鉴其设计理念。另外，也要特别感谢新维数联的CEO王勇先生及VP王思国先生对本书的出版给予的支持和帮助，他们在DevOps领域的业务洞察能力和方向把握能力令我钦佩，王勇把软件系统的建设（Build）、检验（Test）、运营（Operation）提炼成了BTO蓝图，并以此为公司业务发展战略落实执行，在本书的成稿过程中也提出了很多有建设性的意见。
本书中的软件工厂的先进软件工程思想来源于王杰先生，他是一个能深入思考和洞察软件行业发展趋势及传统IT行业各类问题所在的人。他一手创办了中国金融IT行业最大的软件测试服务提供商捷科智诚，提出软件工厂思想并创办了隆正互联公司，该公司的负责人吴向东老师也是我非常敬佩的人，在落地实施软件工厂的建设方面不遗余力，我也有幸在两位老师的指导下，基于DevOps的理念设计了软件工厂的生产流水线。书中不少实践经验的总结提炼都来源于我所服务的客户，如中国银行、中信银行、安邦保险、青岛银行等，在此也感谢它们给予我这么宝贵的实践机会和项目上的协助，让我在产品设计及理论方法上都能更上一个台阶。
本书关于软件标准化生产、IT CT化的思想来源于与福建某运营商高管的交流过程中的领悟，获益匪浅，在此表示感谢；本书关于技术债务的处理实践方法来源于浙江某运营商的项目经验，在此表示感谢。该运营商曾在业界率先引入敏捷、DevOps思想，并建设了相关的DevOps平台，我有幸参与该平台的建设过程并负责相关规划设计工作，获益匪浅。
本书关于持续集成的部分案例来自深圳某政府单位的研发过程管控项目的实践，在此表示感谢。从这个项目的实践中我探索了中等规模企业对DevOps的需求与实践方法，提炼出不少有用的经验。
本书关于敏捷、规模化敏捷的思考受到光环国际李建昊老师的启发，该公司是国内最大的PMP、敏捷项目培训、咨询服务公司之一。
本书关于容器技术相关的内容得到了合作伙伴数人云的帮助，他们是国内专注于微服务、容器云、DevOps领域的公司，感谢公司创始人王璞和售前总监贺洪龙在DevOps合作项目过程中给予的帮助，以及对本书内容提出的宝贵建议。
本书关于持续集成过程中整合性能测试的内容得到了合作伙伴臻云科技的帮助，公司的创始人金发华、王凡基于开源的JMeter发展了业界领先的性能测试平台XMeter。
本书关于精准测试的内容得到了合作伙伴星云测试的帮助，精准测试所倡导的通过代码覆盖率度量测试充分度，关联测试用例进行精准回归测试的做法与DevOps的协同、自动化理念非常吻合。
本书成书过程中还得到了公司同事的帮助，如付勇、彭菲、陈强、彭伟国、黄凯、李翅展等，他们在各自的领域都非常资深，包括SCRUM、配置管理、自动化测试等，他们在并肩作战的各类项目中提炼总结经验，提供书稿素材，在此表示衷心感谢。
本书将采用敏捷思想持续迭代优化，欢迎大家提出优化修改建议，我将在IT运营公社公众号与读者进行互动。
陈能技
2018年7月
|
|
購物車/收銀台(
0
) | 在線留言板
| 付款方式
| 運費計算
| 聯絡我們
| 幫助中心 |
加入書簽
HOME
新書上架
