本文目录导航：
软件性能治理工具的繁难运行
运行软件的规模及复杂水平日趋大型化、复杂化，这就造成软件开发的方式也从早期的单兵作战式或手任务坊式慢慢转变为集团化、工厂流水线式的团队单干开发方式。
在这种开发形式中会遇到一些疑问，例如： ●须要将整个软件版本复原到以前某一期间的形态；●控制某一程序在同一期间内只能由一个开发人员启动修正；●限制轻易修正程序；●对每个开发人员编写的程序质量启动评价。
如何处置上述疑问，治理好名目的每一步运作，成为每一位名目主管须要处置的课题。
目前，许多性能治理工具能够与各种盛行的开发软件启动无缝的衔接，它们无机地联合在一同，能够完整地保留开发中对运行程序每一个源文件一切的修正记载，因此充沛地利用性能治理工具能够对软件开发启动有效的治理，其详细体现有以下几个方面：(1)随时将程序复原到以前某一期间点。
性能治理工具可以将某一程序复原到以前某一期间的形态，甚至将整个软件版本复原到以前某一期间的形态。
它能比拟程序的不同版本，繁难地识别出被修正，删除或拔出的详细行，可以将两个不同版本的修正兼并到一个新文件中，假设一段关键的代码被删除了，它可以迅速复原这段代码。
(2)实现代序的互序性修正。
性能治理工具能够成功某一程序在同一期间只能由一个开发人员启动修正。
其详细成功方式是：开发人员从源文件寄存处检出(Cherk out)一个程序，这时其余开发人员就无法以再检出同一个程序了，只要当第一个开发人员修正测试成功后，将更新版本的代码做检入(Check in)操作，其余开发人员才干检出同一个程序-当然，如今有些性能治理工具也可以性能成准许多入修正，即同时检出同一个程序．最后可以将不同版本的修正兼并到一个新程序中。
(3)对程序修正启动有效的治理。
在性能治理工具中可以将用户分为治理员和程序员两种角色，只要治理员可以将程序解冻(Freeze)和解冻(Unfreeze)，被解冻的程序是下准许修正的。
修正程序的流程为：①用户提交需求书，程序员提交程序设计说明书，名目主管审核经事先，性能治理员(CMO)将程序解冻；②由程序员检出程序；③程序员修正程序；④修正成功后程序员提交测试恳求给测试小组，测试小组启动测试，假设测试不经过，转向第③步；⑤测试经过以后程序员填写本次修正记载，而后检入程序；⑥性能治理员将程序解冻。
至此成功一次性程序的修正。
在软件开发前期或许软件正式投入经常使用时，这种方式对保障软件的稳固运转能起列十分关键的作用。
(4)将开发环境与测试环境、运转环境启动有效的隔离：比拟大型的软件开发名目部有专门的测试小组；驳回性能治理工具后，开发人员有自己独自的开发环境，测试人员有自己的测试环境-测试人员测试无误后才检入程序，可防止失误的程序影响其他人员经常使用和测试幢用系统；名目启动到必定阶段，可随时用性能治理工具生成一个新的版本，投入运转—生成运转版本时可以选用以前一切的修正记载。
(5)评价开发人员编写的程序质量，控制开发进度。
性能治理工具完整地保留在开发中对运行程序的每一个源文件一切的修正汜录-这些记载包括成功修正程序的开发人员、修正的期间、所启动的详细修正以及对本次修正的解释。
名目主管经过调阅这些记载，对程序修正的次数、修正要素和修正状况启动统计，就能够对每一个程序员编写的程序质量启动综合评价，这些记载还能使名目主管对整个名目的进度、程序的编写修正状况有一个全体的了解。
(6)治理文档。
性能治理工具不只为各种开发软件提供了寄存对象的接口，还能寄存恣意类型的文件．这样可以在性能治理工具中建设专门的文件夹，用来仃放软件廾发环节中牛成的各种文档，关于每个文档可以寄存它的多个版本，供随时查阅。
留意：性能治理软件的安保性普通，为确保软件开发环节中源代码与文档的安保，制订一个正当的系统备份战略是必要的。
总之，在一个名目小组开发环境中，性能治理工具的驳回是十分必要的。
它就似乎建设一部软件开发的编年史，不只仅对软件的版本启动了控制，还能够协调多个外发人员的任务，对整个软件的开发环节启动有效的治理，大大提高了软件开发的效率，收到事倍功半的成果。
性能治理(性能治理)详细资料大全
性能治理（Configuration Management，CM）是经过技术或行政手腕对软体产品及其开发环节和生命周期启动控制、规范的一系列措施。
性能治理的目的是记载软体产品的演化环节，确保软体开发者在软体生命周期中各个阶段都能失掉准确的产品性能。
基本引见
简介,性能,并行开发支持,订正版治理,版本控制,治理环节,建设治理,环节控制,代码共享,流程,制订性能治理计画,性能库治理,版本控制,变卦控制,性能审计,实施,阅历,浪费费用,无利于常识库的建设,规范治理,精髓,版本控制,变卦控制,性能控制,形态报告,性能审计,性能治理的商业模型,CICO模型,组织模型,长事务模型,变卦集模型,性能治理的套用,完结语,简介
性能治理环节是对处于不时演化、完善环节中的软体产品的治理环节。分歧性、可追溯性，使产品极大水平地与用户需求相吻合。它经过控制、记载、追踪对软体的修正和每个修正生成的软体组成部件来成功对软体产品的治感性能。 早在七十年代初期加利福利亚大学的Leon Presser传授就撰写了一篇论文，提出控制变卦和性能的概念，之后在1975年，他成立了一家名为SoftTool的公司，开发了自己的性能治理工具：CCC，这也是最早的性能治理工具之一。之后，随着软体开发规模的逐渐增大，越来越多的公司和团队看法到了软体性能治理的关键性，而相应的软体性能治理工具也如雨后春笋普通，纷繁涌现，比拟有代表性的有：Marc Rochkind的SCCS（Source Code Control System）和Walter Tichy的RCS（Revision Control System），这两种工具对日后的性能治理工具的开展做出了严重的奉献，目前绝大少数宽泛经常使用的性能治理工具基本上都是基于这两者的设计思维和体系架构。 性能治理在软体开发环节和名目治理环节中的作用 随着软体系统的日益复杂化和用户需求、软体更新的频繁化，性能治理逐渐成为软体生命周期中的关键控制环节，在软体开发环节中表演着越来越来关键的角色。一个好的性能治理环节能笼罩软体开发和保养的各个方面，同时对软体开发环节的巨观治理，即名目治理，也有关键的支持作用。良好的性能治理能使软体开发环节有更好的可预测性，使软体系统具备可重复性，经常使用户和主管部门用软体质量和开发小组有更强的信念。 软体性能治理的最终目的是治理软体产品。由于软体产品是在用户不时变动的需求驱动下不时变动，为了保障对产品有效地启动控制和追踪，性能治理环节不能仅仅对静态的、成形的产品启动治理，而必定对灵活的、生长的产品启动治理。由此可见，性能治理同软体开发环节严密关系。性能治理必定紧扣软体开发环节的各个环节：治理用户所提出的需求，监控其实施，确保用户需求最终落实到产品的各个版本中去，并在产品发行和用户支持等方面提供协助，回响用户新的需求，推进新的开发周期。经过性能治理环节的控制，用户对软体产品的需求似乎普通产品的订繁多样，遵照一个严厉的流程，经过一条受控的消费流水线，最后构成产品，出售给相套用户。从另一个角度看，在产品开发的不同阶段通常有不同的义务，由不同的角色担当，各个角色职责明白，若明若暗，但同时又前后衔接，相互协调。 好的性能治理环节有助于规范各个角色的行为，同时又为角色之间的义务传递提供无缝的接合，使整个开发团队像是一个交响乐队一样谐和而又错杂地后退。正由于性能治理环节间接连线产品开发环节、开发人员和最终产品，这些都是名目主管人员所关注的重点，因此性能治理系统在软体名目治理中也起着关键作用。性能治理环节演化出的控制、报告性能可协助名目经理更好地了解名目的进度、开发人员的负荷、任务效率和产质量量状况、交付日期等消息。同时性能治理环节所规范的任务流程和明白的分工无利于治理者接待开发人员流动的困境，使新的成员可以极速成功义务交接，尽量缩小因人员流动而形成的损失。性能
并行开发支持
因开发和保养的要素，要求能够成功开发人员同时在同一个软体模组上任务，同时对同一个代码局部作不同的修正，即使是跨地区散布的开发团队也能互不搅扰，协同任务，而又不失去控制。订正版治理
跟踪每一个变卦的发明者、期间和要素，从而放慢疑问和毛病确实定。版本控制
性能治理治理环节
建设治理
基于软体存储库的版本控制性能，成功建设（build）环节智能化。环节控制
代码共享
提供良好的存储和访问机制，开发人员可以共享各自的开发资源。流程
制订性能治理计画
性能治理员制订《性能治理计画》，关键内容包括性能治理软硬体资源、性能项计画、基线计画、交付计画、备份计画等。CCB审批该计画。性能库治理
性能治理员为名目创立性能库，并给每个名目成员调配容许权。各名目成员依据自己的容许权操作性能库。性能治理员活期保养性能库，例如肃清渣滓档案、备份性能库等。版本控制
在名目开发环节中，绝大局部的性能项都要经过屡次的修正才干最终确定上去。对性能项的任何修正都将发生新的版本。由于不能保障新版本必定比老版本“好”，所以不能放弃老版本。版本控制的目的是依照必定的规定保留性能项的一切版本，防止出现版本失落或混杂等现象，并且可以极速准确地查找到性能项的任何版本。 性能项的形态有三种：“草稿”、“正式颁布”和“正在修正”，本规程制订了性能项形态变迁与版本号的规定。变卦控制
在名目开发环节中，性能项出现变卦简直是无法防止的。变卦控制的目的就是为了防止性能项被轻易修正而造成凌乱。 修正处于“草稿”形态的性能项不算是“变卦”，无需CCB的同意，修正者依照版本控制规定口头即可。 当性能项的形态成为“正式颁布”，或许被“解冻”后，此时任何人都不能轻易修正，必定依据“放开→审批→口头变卦→再评审→完结”的规定口头。性能审计
为了保障一切人员（包括名目成员、性能治理员和CCB）都遵守性能治理规范，质量保障人员要活期审计性能治理任务。性能审计是一种“环节质量审核”优惠，是质量保障人员的任务职责之一。实施
实施性能治理系统，普通的步骤和须要思考的疑问如下： 1．布局、调整网路开发环境 一个布局良好的开发环境，是实施性能治理系统的前提。在此阶段，要对性能治理系统做出布局，关键思考以下疑问：2．设计性能治理库 依据名目开发的要求，设计开发资源的存储形式，良好的存储形式无利于减轻治理上的累赘，增强性能治理库的访问性能，同时便于控制访问容许权，包全软体资产。 3．定义性能治理系统的角色 在此阶段，须要确定与性能治理关系的一切角色，包括他一切角色相应的优惠。在开发环节中，一个开发人员或许专任多种角色，但一项义务在同一时辰只能由一个角色来口头。 普通性能治理中的角色关键包括：4．制订性能治理流程 这是性能治理实施的一个关键阶段，其关键目的是依据名目开发的须要，制订相应的性能治理流程，以更好地支持开发，关键优惠包括：普通来讲，实施性能治理系统，关系人员须要接受以下培训： 性能治理阅历
围绕性能治理，环球一些努力于软体工程钻研的公司在深化了解ISO 9000的基础上，推出了各种合乎ISO 9000性能治理规范的工具软体，如INTERSOLV公司的PVCS、Rational公司的Clear Case等。这些性能治理工具面向软体规范化、工程化、智能化的须要，协助开发团队提高迷信治理水平，从而提高工程效率，降落工程老本。现以PVCS为例，联合实践阅历，谈谈实施性能治理的优势：浪费费用
1．缩短开发周期 应用PVCS的Version Manager对程式资源启动版本治理和跟踪，建设公司的代码常识库，保留开发环节中每一环节版本，这样大大提高了代码的重用率，还便于同时保养多个版本和启动新版本的开发，防止系统解体,最大限制地共享代码。同时名目治理人员可以经过Version Manager检查名目开发日志，测试人员可以依据开发日志和不同版本对软体启动测试，工程人员可以从Version Manager上失掉不同的运转版本，并且Version Manager 可以装置在Web Server供当地施工人员存取最新版本，无需开发人员亲临现场。 应用Tracker组建开发集团之间的疑问跟踪及讯息通迅，经过其Notify模组与电子邮件联合起来大大增强了开发集团之间的沟通，Reporter模组可对发现的疑问启动整顿、以报表方式分类报出，作为开发的指点。 以上为PVCS的两个关键模组，迷信地套用可以大大提高开发效率，防止了代码笼罩、沟通不够、开发无序的凌乱局面，假设应用了公司原有的常识库，则更能提高任务效率，缩短开发周期。 2 ．缩小施工费用 应用PVCS启动软体性能治理后，建设开发治理规范，把版本治理档案挂接在公司外部的Web伺服器上，外部间接经过Netscape访问Version Manager，工程人员经过远程进入外部网，失掉所需的最新版本。开发人员无需下现场，现场工程人员经过对方系统治理员搜集反应意见，书面提交到公司外部开发组名目经理，开发组外部探讨选择能否修正，并作出书面回答。这样做，可以同时回响多个名目点，防止开发人员调配到各个名目点、扩散力气、人员不够的疑问，同时浪费少量的旅差费用。无利于常识库的建设
1．代码对象库 软体代码是软体开发人员脑力休息的结晶，也是软体公司的贵重财产，常年开发环节中构成的各种代码对象就像一个个整机坯一样，是极速生成系统的组成局部。常年的一个理想是：一旦某个开发人员退收任务岗位，其原来所作的代码便基本成为渣滓，无人过问。究其要素，就是没有专门对各人的有用对象启动治理，把其经常使用范围扩展到公司一级，启动规范化，加以说明和遍及。Version Manager为对象治理提供了一个平台和仓库，无利于建设公司级的代码对象库。 2．业务及阅历库 经过PVCS Version Manager的注释及Tracker，可构成完整的开发日志及疑问汇合，以文字方式随同开发的整个环节，不依某团体的转移而隐没，无利于公司积攒业务阅历，无论对版本整改或版本更新，都具备关键的指点作用。规范治理
1．量化任务量考核 传统的开发治理中，任务量不时是难以估计的目的，靠开发人员自己掌握，轻易性相当大，靠治理人员掌握，客观性又太强。驳回PVCS治理后，开发人员每天任务前对修正的档案 Check In，其中记叙今日修正细节形容，这些形容可以作为任务量的权衡目的。 2．规范测试 驳回PVCS以后，测试有了实真实在的任务，测试任务人员依据每天的修正细节形容对每一天的任务做详细的测试，对测试人员也具备可考核性，这样环环相扣，大大缩小了其任务的轻易性。 3． 增强协调与沟通 驳回PVCS后，经过Version Manager文档共享及其特定锁机制、Tracker与电子邮件的集成，大大增强了名目成员之间的沟通，做到有疑问及时发现、及时修正、及时通知，但又不额外参与很多的任务量。精髓
详细来讲，性能治理蕴含如下内容：从上方的形容知道，性能治理的基本单位是性能项。 从“哲学”意义上讲，它记载性能项的三个方面：性能项可以是大粒度的，也可以是小粒度的。假设跟踪一般需求，那么不用要把整个需求规格说明文档定义为一特性能项，可以把每个需求定义为性能项；假设把软体开发工具也放入性能治理系统，那么把性能项定义为档案级就不适宜了，只要要跟踪开发工具的版本，即把整特性能工具定义为一特性能项就足够了。 简而言之，性能项可以是档案级粒度的，也可以是档案版本级粒度的。当然，粒度越小治理的老本越高，但是性能的精度也就越高。 一个完整的SCM系统要具备三个外围性能：版本控制、变卦控制、性能控制以及两个支持性能：形态统计和性能审计。版本控制
版本，亦称性能标识，是指某一特定对象的详细实例的潜在存在。这里的某一特定对象是指版本保养工具治理的软体组成单元，普通是指源档案；详细实例则是指软体开发人员从软体库中复原进去的某软体组成单元的具备必定内容和属性的一个真实拷贝。例如，对源档案的每一次性修正都生成一个新版本。 版本控制就是对在软体开发环节中所创立的性能对象的不同版本启动治理，保障任何时刻都能取到正确的版本以及版本的组合。 以后，这方面典型的工具备如VSS和CVS。变卦控制
变卦控制是经过对变卦恳求（Change Request，简称CR）启动分类、追踪和治理的环节来成功的。变卦的来源有两种：性能变卦和毛病修补（Bug-Fix）。性能变卦是为了参与或许删除某些性能。毛病修补则是对已存在的毛病启动修补。 性能治理对变卦启动控制的机构称为变卦控制委员会（Change Control Board，简称CCB）。变卦控制委员会要活期召散会议，对近期所发生的变卦恳求启动剖析、整顿，并做出选择。而且要遵照必定的变卦机制。 上方是一个典型的变卦机制： 可以随着变卦环节的推进，优化性能项的形态。 这方面的工具备Bugzilla。性能控制
性能控制经常使用户能够经过对适当版本的选用来组成特定属性（性能）的软体系统，这种灵敏的“组装”战略使得性能治理系统像搭积木似的经常使用已有的积木（版本）组装成各种各样、不同性能的模型。 软体产品的每个版本都是一组性能项（原始码、文档、数据）的汇合。性能控制就是要保障每特性能的完整性和准确性。 举个例子来说，要颁布软体的32.6版本，那么就要把原始码、文档、数据中一切应该蕴含到这个版本中的正确性能项检出。 在开发环节中，在不同阶段要建设各种基线。基线的建设是性能控制性能的典型套用。所以说，基线是具备里程碑意义的一特性能。 普通的商业软体性能治理工具都具备性能控制的性能，只是灵敏性和准确性有差异。形态报告
形态报告要回答所谓4W的疑问：形态报告还要能够报告一切性能项以及变卦恳求的形态。性能审计
性能审计要审查以下项：由于如今软体行业越来越注重质量，许多名目专门成立质量保障部门专门来启动性能审计。所以如今也可以说，性能审计是一个SQA（软体质量保障）优惠。性能治理的商业模型
性能治理的实施包括两局部：工具和规范。 在软体开发环节智能化的今日，没有工具的支持而实施性能完整的性能治理是不能想像的。因此选用一个合乎公司或名目的工具至关关键。在性能治理系统中，可演绎出以下四种模型。以后商业工具普通驳回其中一种或几种模型。经过对商业模型的了解，可以协助了解某种工具能否适宜某个公司或名目。CICO模型
CICO模型关键关注的是单个档案的版本控制。图显示了一个支持CICO模型的CM系统的任务环节。用户应用库和档案系统来启动任务。档案被版本化并存储到库中，新版本的发生由库工具控制。但是， 档案在库中不是可以间接存取的，用户必定去检出（即Check out）一个档案的版本就任务空间中以便读取它的内容。更改后的档案可以被检入库中（即Check in）,发生档案的一个新版本。 此模型的代表工具是SCCS和CVS。组织模型
组织模型由CICO模型人造导出，建设于构件版本图的基础之上，同时依赖于存储库和任务空间的概念，可以经过对构件加锁启动并发控制。组织模型的重点是在CM系统撑持下增强了对创立性能、对无关的历史消息的治理和经常使用他们作为任务环境的支持。 组织模型中的性能由系统模型和版本选用规定组成。系统模型列出了组成系统的一切的构件。版本选用规定指出了组成性能的每一个构件选用版本。选用规定用于系统模型，选用构件版本，即绑定一个构件到某一版本。这个模型的操作方式是：开发人员依据模型的构件定义整个系统，并在每一步骤中给每个构件选用适宜的版本。版本操作的任务方式如图所示。 CM支持关键关心的是保养系统和其构件的版本历史，并选用合乎分歧性性能的构件版本。只要在所选构件的版本与所选其它构件版本分歧时才以为一特性能版本。 此模型的代表工具是CCC。长事务模型
长事务模型关键支持包括一系列原子变卦的全系统演化和由团队开发人员对系统变卦的协调。开发人员关键操作性能而非独自的构件。事务提交的结果是新性能版本，一系列延续的变卦结果生成一系列的性能版本，称为开发门路。 在长事务模型中，开发人员关键的任务对象是性能，开发人员首先选用系统性能版本，接上去把关注重点放在系统结构上。构件的版本由性能隐式选择。长事务由两个概念组成：任务空间和并发控制打算。任务空间来源于存储库或一个敞开任务空间中的一个固定性能。任务空间由任务性能和一系列已保留的性能组成。任务性能代表构件和系统结构能够被灵活更改的性能。提供经过任务空间启动的透明库访问、将高效的库存储技术套用于任务空间和治理派生构件的版本。 此模型的代表系统是NSE。变卦集模型
关键集中于对系统性能的逻辑变卦的支持。在这个模型中引入的变卦集示意组成逻辑变卦的对不同构件修正的汇合，它是创立变卦的优惠成功后对逻辑变卦的记载。支持这个模型的CM系统用户可以间接操作变卦集。在变卦集模型中，性能可形容为由基线和一组变卦集组成。 变卦流传给其它性能可经过蕴含各自变卦集来启动。开发人员经常使用不同的集成战略将逻辑变卦集蕴含到一个新的系统发行中。这样的优势十分显著，例如，保养10个不同版本的产品，如今要对一切的版本修正一个毛病（Bug）。假设相反的工具繁难的重复10次显然是无法接受的。而经过变卦集把这个逻辑变卦从一个版本自在的传到另外一个版本。 开发人员可跟踪逻辑变卦和确定这些变卦能否属于特定性能。这种性能治理的方法，由于其将重点放于逻辑变卦上，所以被称作面向变卦的性能治理。它不同于如今的其余3种CM模型，由于其它3种CM模型经常使用的面向版本的方法把重点放在构件和性能版本上。 在繁多构件的状况下，变卦集是两个档案版本之间区别的汇合，通常指的是增量内容。对性能来说，变卦集就是两特性能版本之间区别的汇合。这组区别就是两特性能版本间的修正构件增量汇合，即变卦构件集的增量。 面向变卦的观念不同于面向版本的观念。这有两点不同，一是逻辑变卦的显式示意准许对与单个构件和性能无关的变卦集启动跟踪。二是援用单个变卦集并有选用地将它们归入性能治理中的这种才干提供了对系统演化治理的支持，这种演化是基于将逻辑变卦流传到保养的系统性能启动的。 此模型的代表工具是UCM和SABLIME。性能治理的套用
云安保措施中最关键的要素就是性能治理。 在SaaS环境中，性能治理是齐全由云供应商担任处置的。如有或许，客户可经过鉴证业务准绳通告（SSAE）第16号、服务组织控制（SOC）报告或ISO认证以及云安保联盟的安保、信赖和保障注册证实向供应商提出一些补丁治理和性能治理通常的要求。 在PaaS环境中，平台的开发与保养都是由供应商来担任的。运行程式性能与开发的库和工具或许是由企业用户治理的，因此安保性能规范依然还是属于外部定义范围。而后，这些规范都应在PaaS环境中被套用和监控。完结语
性能治理自身无论从通常和通常都在不时丰盛和开展。例如，性能治理套用于“常识库”的治理就发生了“内容治理”这一新的畛域。性能治理提供的形态报告和数据统计也为软体度量提供了决策依据。性能治理为名目治理提供了各种监控名目停顿的视角，为名目经理确切掌握名目进程提供了保障。性能治理也为开发人员提供了一个单干的平台，在此平台上，大家能够更有效率的交换和单干。可以说，性能治理是软体开发的基石！ 性能治理近年来在中国失掉了极大的认可，可以毫不夸张的说，没有性能治理，就谈不上软体开发，就谈不上软体质量，就谈不上软体业的开展。随着软体业规模的扩展，性能治理的实施不是要不要的疑问，而是什么期间、如何实施的疑问了。性能治理的工具备哪些
性能治理工具包括：
1. 版本控制系统（如Git）
2. 智能化性能工具（如Ansible、Chef、Puppet）
3. 部署治理工具（如Jenkins、Docker）
详细解释如下：
版本控制系统：用于集中治理代码，确保代码的完整性和可追踪性。
Git是一种经常出现的版本控制系统，可以追踪每次代码的改变，便于开发者单干和版本控制。
它准许开发团队保留名目的不同版本，并且能够回溯就任何历史版本，这关于软件开发环节中的性能治理至关关键。
智能化性能工具：关键用于智能化性能治理，提高开发效率。
Ansible、Chef和Puppet是其中的代表。
这些工具能够智能化部署运行程序、性能系统参数、治理主机等义务。
它们经过定义好的脚本或模板，能够在不同的环境中极速成功分歧的性能。
部署治理工具：用于智能化部署和继续集成。
Jenkins和Docker是罕用的部署治理工具。
Jenkins是一个可扩展的智能化主机，能够口头各种智能化义务，包括构建、测试和部署。
Docker则是一个开源的运行容器引擎，用于智能化运行部署，经过容器化技术成功运行的极速散发和部署。
这些工具都能够大大提高性能治理的效率，缩君子工操作带来的失误。
