敏捷軟件開發(fā)asd08持續(xù)集成

1、Continuous Integration持續(xù)集成改善軟件質(zhì)量并降低風(fēng)險的方法主要內(nèi)容簡介CI原理CI實(shí)踐建立一個特征全面的CI系統(tǒng)CI的未來21 簡介內(nèi)容The components of a CI systemFeatures of CIQuestions41.1 The components of a CI system5Developer一旦修改完代碼后，會進(jìn)行本地build通過后，將變化提交到版本控制庫這一步可以隨時發(fā)生，而且并不影響CI過程的后續(xù)步驟本地build是減輕集成負(fù)擔(dān)的必要步驟6Version Control Repository版本控制是項目管理的標(biāo)準(zhǔn)版本控制庫為源代

2、碼和文檔提供“single source point”配置管理軟件Subversion, PVCS, ClearCase, MKS,7CI ServerCI服務(wù)器在改變提交的時候運(yùn)行build腳本CI服務(wù)器也可以是硬調(diào)度的這樣的服務(wù)器不能真正成為CI必要時，也可以手工運(yùn)行build腳本8Build ScriptBuild腳本應(yīng)該包括編譯、測試、審查和發(fā)布等活動9Feedback MechanismCI技術(shù)的一個關(guān)鍵目的是提供集成build的反饋10Integration Build Machine運(yùn)行CI服務(wù)器的單獨(dú)計算機(jī)，便于快速build以最快速度產(chǎn)生反饋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系統(tǒng)特征源代碼編譯是CI系統(tǒng)最基本和普遍的特征有人認(rèn)為源代碼編譯和CI是同義詞這種看法有些片面，因為CI具有許多其他特有特征動態(tài)語言的源代碼編

4、譯特征更為明顯Python，Ruby，PHP等14Database Integration數(shù)據(jù)庫集成和源代碼集成是一個完整的過程，因為數(shù)據(jù)庫是軟件的一個重要集成成分15Testing測試是CI有別于源代碼編譯的重要特征它在CI系統(tǒng)中的重要性是毋庸置疑的但是，必須尋求一種自動測試的方法這種測試可以是驗收測試16Inspection自動化代碼審查有助于增強(qiáng)軟件質(zhì)量代碼審查必須強(qiáng)制一些規(guī)則，比如不允許出現(xiàn)壞味道等Checkstyle是一款較好的開源軟件17Deployment18Documentation and Feedback有些人認(rèn)為文檔應(yīng)歸于源代碼但是具有精選類、變量、實(shí)例和方法名字本身就是

5、很好的文檔有許多很好的工具可以生成文檔，如JavaDoc一個良好CI系統(tǒng)的重要特征是速度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原理內(nèi)容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實(shí)踐內(nèi)容Automate Builds Perform Single Command BuildsSeparate Build Scripts from Your IDECentralize Software Assets Create a Consistent Directory StructureFail Builds FastBuild for Any Environment 47內(nèi)容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系統(tǒng)內(nèi)容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