敏捷软件开发asd08持续集成_第1页
敏捷软件开发asd08持续集成_第2页
敏捷软件开发asd08持续集成_第3页
敏捷软件开发asd08持续集成_第4页
敏捷软件开发asd08持续集成_第5页
已阅读5页,还剩87页未读 继续免费阅读

下载本文档

版权说明:本文档由用户提供并上传,收益归属内容提供方,若内容存在侵权,请进行举报或认领

文档简介

1、Continuous Integration持续集成改善软件质量并降低风险的方法主要内容简介CI原理CI实践建立一个特征全面的CI系统CI的未来21 简介内容The components of a CI systemFeatures of CIQuestions41.1 The components of a CI system5Developer一旦修改完代码后,会进行本地build通过后,将变化提交到版本控制库这一步可以随时发生,而且并不影响CI过程的后续步骤本地build是减轻集成负担的必要步骤6Version Control Repository版本控制是项目管理的标准版本控制库为源代

2、码和文档提供“single source point”配置管理软件Subversion, PVCS, ClearCase, MKS,7CI ServerCI服务器在改变提交的时候运行build脚本CI服务器也可以是硬调度的这样的服务器不能真正成为CI必要时,也可以手工运行build脚本8Build ScriptBuild脚本应该包括编译、测试、审查和发布等活动9Feedback MechanismCI技术的一个关键目的是提供集成build的反馈10Integration Build Machine运行CI服务器的单独计算机,便于快速build以最快速度产生反馈111.2 Features of

3、 CIFour features required for CIA connection to a version control repositoryA build scriptSome sort of feedback mechanism (such as e-mail)A process for integrating the source code changes (manual or CI server)12Other features13CI系统特征源代码编译是CI系统最基本和普遍的特征有人认为源代码编译和CI是同义词这种看法有些片面,因为CI具有许多其他特有特征动态语言的源代码编

4、译特征更为明显Python,Ruby,PHP等14Database Integration数据库集成和源代码集成是一个完整的过程,因为数据库是软件的一个重要集成成分15Testing测试是CI有别于源代码编译的重要特征它在CI系统中的重要性是毋庸置疑的但是,必须寻求一种自动测试的方法这种测试可以是验收测试16Inspection自动化代码审查有助于增强软件质量代码审查必须强制一些规则,比如不允许出现坏味道等Checkstyle是一款较好的开源软件17Deployment18Documentation and Feedback有些人认为文档应归于源代码但是具有精选类、变量、实例和方法名字本身就是

5、很好的文档有许多很好的工具可以生成文档,如JavaDoc一个良好CI系统的重要特征是速度191.3 QuestionsAre you using a version control repository (or SCM tool)?Is your projects build process automated and repeatable? Does it occur entirely without intervention?Are you writing and running automated tests?Is the execution of your tests a part o

6、f your build process?How do you enforce coding and design standards?Which of your feedback mechanisms are automated?Are you using a separate integration machine to build software?202 CI原理内容What Is the Value of CI?Adopt CICI Complement Other Development PracticesSeven PracticesReducing Risks Using CI

7、22Story232.1 What Is the Value of CI?Reduce risksReduce repetitive manual processesGenerate deployable software at any time and at any placeEnable better project visibilityEstablish greater confidence in the software product from the development team24Reduce RisksDefects are detected and fixed soone

8、rHealth of software is measurableReduce assumptions25Reduce Repetitive ProcessesThe process runs the same way every time.An ordered process is followedThe processes will run every time a commit occurs in the version control repository.26Generate Deployable SoftwareCI can enable you to release deploy

9、able software at any point in time.27Enable Better Project VisibilityEffective decisionsNoticing trends282.2 What Prevents Teams from Using CI?Increased overhead in maintaining the CI systemToo much changeToo many failed buildsAdditional hardware/software costsDevelopers should be performing these a

10、ctivities29How Do I Get to “Continuous” Integration?These steps can be applied one by one to virtually every activity you conduct on a project.IdentifyBuildShareMake it continuous30When and How Should a Project Implement CI?It is best to implement CI early in the project.it is more difficult to impl

11、ement CI late in a projectCI is not just a technical implementation; it is also an organizational and cultural implementation.How?At first the build can just compile the source code and package the binariesThen, learn the testing toolrunning these tests (and inspections) with every change.312.3 How

12、Does CI Complement Other Development Practices?Developer testingCoding standard adherenceRefactoringSmall releasesCollective ownership322.4 Seven PracticesCommit code frequentlyDont commit broken codeFix broken builds immediatelyWrite automated developer testsAll tests and inspections must passRun p

13、rivate buildsAvoid getting broken code332.5 Reducing Risks Using CIRisk: Lack of Deployable SoftwareRisk: Late Discovery of DefectsRisk: Lack of Project VisibilityRisk: Low-Quality Software34It Works on My MachineEliminating tight coupling between your IDE and your build processes.Use a separate mac

14、hine solely for integrating the software.35Synching with the DatabasePlace all database artifacts in your version control repository.Rebuild the database and data from your build script, by dropping and recreating your database and tables. Next, apply the stored procedures and triggers, and finally,

15、 insert the test data.Test (and inspect) your database.36The Missing Clickautomated the deployment process by adding it to the Ant build scripts that use the application server command-line options.reduced the bottleneck of waiting for someone else to deploy the software and eliminated mistakes.37Re

16、gression TestingWrite test code for all of your source code (an xUnit framework is a good place to start).Run tests from your build script (Ant or NAnt are the most common).Run tests continuously as a part of your CI system so that they are executed at every checkin to the version control repository

17、 (using CruiseControl or a similar CI server).38Test Coveragerun a code coverage tool to assess the amount of source code that is actually executed by the tests.Using CI can ensure this test coverage is always up to date.39“Did You Get the Memo?”we installed and configured a CruiseControl CI server

18、on our projects with the automated mechanism that sends e-mails to affected parties when a build fails.we added SMS notifications so that we received text messages on our mobile phones40Inability to Visualize Softwarewe began generating diagrams of the design using the CI system.we also chose to cre

19、ate a simple one- or twoarchitecture document that described the software architecture, identifying the key components and interface for new developers.41Coding Standard Adherencewe created a onepage annotated class that contained all of the coding standards.We enforced the coding standard by using

20、automated inspection tools as a part of the build scripts initiated by CruiseControl.used Checkstyle and PMD to report any lines of code that were not meeting the established standards.42Architectural AdherenceAdd automated inspection tools to assess adherence to the projects architectural standards

21、.43Duplicate CodeAdd automated inspection tools such as PMDs CPD7 or the Simian8 static analysis tools to report duplicate source code.Refactoring!44Summary of Risks and MitigationsRiskMitigationLack of deployable softwareUse a CI system to build deployable software at any time. Create a repeatable

22、build process that uses all software assets from the version control repository.Late discovery of defectsRun builds that include developer tests with every change, so you can discover defects earlier in the software lifecycle.Lack of projectvisibilityKnow the health of your software at all times by

23、running builds regularly. When effectively applying the practice of CI, the project status is no longer in question.Low-quality softwareRun tests and inspections at every change so you can discover potential defects that may be introduced into the code base by learning the complexity, duplication, d

24、esign, code coverage, and other factors.453 CI实践内容Automate Builds Perform Single Command BuildsSeparate Build Scripts from Your IDECentralize Software Assets Create a Consistent Directory StructureFail Builds FastBuild for Any Environment 47内容Build Types and MechanismsUse a Dedicated Integration Bui

25、ld Machine Use a CI ServerRun Manual Integration BuildsRun Fast BuildsStage Builds483.1 Automate BuildsBy writing automated build scripts, you reduce the number of manual, repetitive, and error-prone processes performed on a software project.the more processes added to a build, the slower the feedba

26、ck.if you are just trying out a couple of changes and do not intend to commit anything, you may choose to run a lighter-weight build that may only perform a compile and then execute a few unit tests.Some of the most popular build tools include Ant for Java and NAnt for .NET.493.2 Perform Single Comm

27、and Builds“Get everything you need into source control and get it so that you can build the whole system with a single command.”The high-level steps for building your software go something like:1. Create your build using a build scripting tool like NAnt, Rake, Ant, or Maven. Keep it simple at first;

28、 you can add more processes as you go.2. Add each process (clean, compile, etc.) of the Integrate button within the build script.3. Run the script from an IDE or the command line to build software.50The logical processes of a build script513.3 Separate Build Scripts from Your IDEEach developer may b

29、e using a different IDE, and it can be difficult to account for configuration differences in each IDE.A CI server must execute an automated build without human intervention. Therefore, the same automated build script used by developers can and should be used by the CI server.523.4 Centralize Softwar

30、e AssetsTo build software effectively, all software assets must be centralized.centralizing software assets into a version control systemRepository patternComponents, as either source or library filesThird-party components, such as JAR files, libraries, DLLs, and so on, depending on the language and

31、 platformConfiguration filesData files to initialize an applicationBuild scripts and build environment settingsInstallation scripts for some components533.5 Create a Consistent Directory StructureTo do so effectively, to be able to draw on the repository for all the myriad asset combinations you can

32、 use throughout the project, you must create a consistent, logical directory structure.it is important that each task in your build is retrieving from a directory that contains only the source code and related scripts for that task, not the entire project.54An Example553.6 Fail Builds FastThe high-l

33、evel steps to create fast-failing builds are1. Integrate components (get latest changes from repository andcompile)2. Run true unit tests (i.e., quick tests that dont have a database orany other dependency)3. Run other automated processes (rebuild database, inspect, anddeploy)563.7 Build for Any Env

34、ironmentYou may find it useful to maintain different configuration files in your repository to execute against different environment configurations (development, integration, test, QA, and production) by using .properties, .xml, or .ini files.Logging verbosityApplication server configurationDatabase

35、 connection informationFramework configuration573.8 Build Types and MechanismsBuild types occur in a three-level hierarchy: for the individual (Private Build), the team (Integration Build), and users (Release Build).Build MechanismsOn-demand, Scheduled, Poll for changes, Event-driven583.9 Use a Dedi

36、cated Integration Build MachineRecommended system resourcesAll software assets in the version control repositoryClean environment593.10 Use a CI ServerPoll for changes in the version control repository on a specified time interval.Perform certain actions on a scheduled basis, such as hourly or daily

37、.Identify a “quiet period” during which no integration builds are performed for the project.Support for different build scripting tools including command-line tools such as Rake, make, Ant, or NAnt.Send e-mails to the concerned parties.Display a history of previous builds.Display a dashboard that is

38、 Web accessible so that everyone can review integration build information.Support multiple version control systems for your different projects.603.11 Run Manual Integration BuildsAn alternative or complementary technique to using a CI server is to perform a manual integration.Manual integration can

39、be effective in preventing broken builds, but it doesnt scale particularly well for larger teams.613.12 Run Fast Builds1. Gather build metrics.2. Analyze build metrics.3. Choose and perform improvements.4. Reevaluate; repeat if necessary.62Integration Build Metrics63Integration build duration improv

40、ements64Improve Test PerformanceSeparate automated tests by categoryunit, component, and systemand run these tests at different times (e.g., unit tests at every commit, component/system tests in a secondary build). Refactor your tests based on the results of the inspection tools.Use mocks/stubs for

41、components that may otherwise be too difficult or complex to use in the unit-testing environment. For example, a common implementation of a mock object is mocking the interface for data access.Separate long-running integration tests into separate specialized test suites.Execute your tests in paralle

42、l.Run different types of tests based on build type: A commit build is followed by secondary builds, a full integration build, or release build.653.13 Stage Builds664 建立一个特征全面的CI系统内容Continuous Database IntegrationContinuous TestingContinuous InspectionContinuous DeploymentContinuous Feedback684.1 Automate Database Integration69Repeatable Database Integration Activities70Use a Local Database Sandbox71Use a Version Control Repository to ShareDatabase AssetsSharing your database integration scripts is a best practice, plain and simple.Such assets

温馨提示

  • 1. 本站所有资源如无特殊说明,都需要本地电脑安装OFFICE2007和PDF阅读器。图纸软件为CAD,CAXA,PROE,UG,SolidWorks等.压缩文件请下载最新的WinRAR软件解压。
  • 2. 本站的文档不包含任何第三方提供的附件图纸等,如果需要附件,请联系上传者。文件的所有权益归上传用户所有。
  • 3. 本站RAR压缩包中若带图纸,网页内容里面会有图纸预览,若没有图纸预览就没有图纸。
  • 4. 未经权益所有人同意不得将文件中的内容挪作商业或盈利用途。
  • 5. 人人文库网仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对用户上传分享的文档内容本身不做任何修改或编辑,并不能对任何下载内容负责。
  • 6. 下载文件中如有侵权或不适当内容,请与我们联系,我们立即纠正。
  • 7. 本站不保证下载资源的准确性、安全性和完整性, 同时也不承担用户因使用这些下载资源对自己和他人造成任何形式的伤害或损失。

评论

0/150

提交评论