敏捷软件开发asd08持续集成

,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级、,*,单击此处编辑母版标题样式,National University of Defense Technology,Continuous Integration,持续集成改善软件质量并降低风险的方法,主要内容,简介,CI,原理,CI,实践,建立一个特征全面的,CI,系统,CI,的未来,2,1 简介,内容,The components of a CI system,Features of CI,Questions,4,1.1 The components of a CI system,5,Developer,一旦修改完代码后，会进行本地,build,通过后，将变化提交到版本控制库,这一步可以随时发生，而且并不影响,CI,过程的后续步骤,本地,build,是减轻集成负担的必要步骤,6,Version Control Repository,版本控制是项目管理的标准,版本控制库为源代码和文档提供“,single source point”,配置管理软件,Subversion,PVCS, ClearCase, MKS,7,CI Server,CI,服务器在改变提交的时候运行,build,脚本,CI,服务器也可以是硬调度的,这样的服务器不能真正成为,CI,必要时，也可以手工运行,build,脚本,8,Build Script,Build,脚本应该包括,编译、测试、审查和发布等活动,9,Feedback Mechanism,CI,技术的一个关键目的是提供集成,build,的反馈,10,Integration Build Machine,运行,CI,服务器的单独计算机，便于快速,build,以最快速度产生反馈,11,1.2 Features of CI,Four features,required,for CI,A connection to a version control repository,A build script,Some sort of feedback mechanism (such as e-mail),A process for integrating the source code changes (manual or CI server),12,Other features,13,CI,系统特征,源代码编译是,CI,系统最基本和普遍的特征,有人认为源代码编译和,CI,是同义词,这种看法有些片面，因为,CI,具有许多其他特有特征,动态语言的源代码编译特征更为明显,Python,，,Ruby,，,PHP,等,14,Database Integration,数据库集成和源代码集成是一个完整的过程，因为数据库是软件的一个重要集成成分,15,Testing,测试是,CI,有别于源代码编译的重要特征,它在,CI,系统中的重要性是毋庸置疑的,但是，必须寻求一种自动测试的方法,这种测试可以是验收测试,16,Inspection,自动化代码审查有助于增强软件质量,代码审查必须强制一些规则，比如不允许出现坏味道等,Checkstyle,是一款较好的开源软件,17,Deployment,18,Documentation and Feedback,有些人认为文档应归于源代码,但是具有精选类、变量、实例和方法名字本身就是很好的文档,有许多很好的工具可以生成文档，如,JavaDoc,一个良好,CI,系统的重要特征是速度,19,1.3 Questions,Are 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 of 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?,20,2,CI,原理,内容,What Is the Value of CI?,Adopt CI,CI Complement Other Development Practices,Seven Practices,Reducing Risks Using CI,22,Story,23,2.1,What Is the Value of CI?,Reduce risks,Reduce repetitive manual processes,Generate deployable software at any time and at any place,Enable better project visibility,Establish greater confidence in the software product from the development team,24,Reduce Risks,Defects are detected and fixed sooner,Health of software is measurable,Reduce assumptions,25,Reduce Repetitive Processes,The process runs the same way,every time.,An ordered process is followed,The processes will run every time a commit occurs in the version control repository.,26,Generate Deployable Software,CI can enable you to release deployable software at,any point in time.,27,Enable Better Project Visibility,Effective decisions,Noticing trends,28,2.2 What Prevents Teams from Using CI?,Increased overhead in maintaining the CI system,Too much change,Too many failed builds,Additional hardware/software costs,Developers should be performing these activities,29,How Do I Get to “Continuous” Integration?,These steps can be applied one by one to virtually every activity you conduct on a project.,Identify,Build,Share,Make it continuous,30,When and How Should a Project Implement CI?,It is best to implement CI early in the project.,it is more difficult to implement CI late in a project,CI 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 binaries,Then, learn the testing tool,running these tests (and inspections) with every change.,31,2.3 How Does CI Complement Other Development Practices?,Developer testing,Coding standard adherence,Refactoring,Small releases,Collective ownership,32,2.4,Seven Practices,Commit code frequently,Dont commit broken code,Fix broken builds immediately,Write automated developer tests,All tests and inspections must pass,Run private builds,Avoid getting broken code,33,2.5,Reducing Risks Using CI,Risk: Lack of Deployable Software,Risk: Late Discovery of Defects,Risk: Lack of Project Visibility,Risk: Low-Quality Software,34,It Works on My Machine,Eliminating tight coupling between your IDE and your build processes.,Use a separate machine solely for integrating the software.,35,Synching with the Database,Place 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, insert the test data.,Test (and inspect) your database,.,36,The Missing Click,automated 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.,37,Regression Testing,Write 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 (using CruiseControl or a similar CI server).,38,Test Coverage,run 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 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 phones,40,Inability to Visualize Software,we began generating diagrams of the design using the CI system.,we also chose to create a simple one- or two-page architecture document that described the software architecture, identifying the key components and interface for new developers.,41,Coding Standard Adherence,we created a onepage annotated class that contained all of the coding standards.,We enforced the coding standard by using 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.,42,Architectural Adherence,Add automated inspection tools to assess adherence to the projects architectural standards.,43,Duplicate Code,Add automated inspection tools such as PMDs CPD7 or the Simian8 static analysis tools to report duplicate source code.,Refactoring!,44,Summary of Risks and Mitigations,Risk,Mitigation,Lack of deployable software,Use a CI system to build deployable software at any time. Create a repeatable build process that uses all software assets from the version control repository.,Late discovery of defects,Run builds that include developer tests with every change, so you can discover defects earlier in the software lifecycle.,Lack of project,visibility,Know the health of your software at all times by running builds regularly. When effectively applying the practice of CI, the project status is no longer in question.,Low-quality software,Run 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, design, code coverage, and other factors.,45,3 CI,实践,内容,Automate Builds,Perform Single Command Builds,Separate Build Scripts from Your IDE,Centralize Software Assets,Create a Consistent Directory Structure,Fail Builds Fast,Build for Any Environment,47,内容,Build Types and Mechanisms,Use a Dedicated Integration Build Machine,Use a CI Server,Run Manual Integration Builds,Run Fast Builds,Stage Builds,48,3.1,Automate Builds,By 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 feedback.,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.,49,3.2 Perform Single Command 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; 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.,50,The logical processes of a build script,51,3.3 Separate Build Scripts from Your IDE,Each developer may be 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.,52,3.4 Centralize Software Assets,To build software effectively, all software assets must be centralized.,centralizing software assets into a version control system,Repository pattern,Components, as either source or library files,Third-party components, such as JAR files, libraries, DLLs, and so on, depending on the language and platform,Configuration files,Data files to initialize an application,Build scripts and build environment settings,Installation scripts for some components,53,3.5 Create a Consistent Directory Structure,To do so effectively, to be able to draw on the repository for all the myriad asset combinations you can 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.,54,An Example,55,3.6 Fail Builds Fast,The high-level steps to create fast-failing builds are,1. Integrate components (get latest changes from repository and,compile),2. Run true unit tests (i.e., quick tests that dont have a database or,any other dependency),3. Run other automated processes (rebuild database, inspect, and,deploy),56,3.7 Build for Any Environment,You 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 verbosity,Application server configuration,Database connection information,Framework configuration,57,3.8 Build Types and Mechanisms,Build types occur in a three-level hierarchy:,for the individual (,Private Build,), the team (,Integration Build,), and users (,Release Build,).,Build Mechanisms,On-demand, Scheduled, Poll for changes,Event-driven,58,3.9 Use a Dedicated Integration Build Machine,Recommended system resources,All software assets in the version control repository,Clean environment,59,3.10 Use a CI Server,Poll for changes in the version control repository on a specified time interval.,Perform certain actions on a scheduled basis, such as hourly or daily.,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 Web accessible so that everyone can review integration build information.,Support multiple version control systems for your different projects.,60,3.11 Run Manual Integration Builds,An alternative or complementary technique to using a CI server is to perform a manual integration.,Manual integration can be effective in preventing broken builds, but it doesnt scale particularly well for larger teams.,61,3.12 Run Fast Builds,1. Gather build metrics.,2. Analyze build metrics.,3. Choose and perform improvements.,4. Reevaluate; repeat if necessary.,62,Integration Build Metrics,63,Integration build duration improvements,64,Improve Test Performance,Separate 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 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 parallel.,Run different types of tests based on build type: A commit build is followed by secondary builds, a full integration build, or release build.,65,3.13 Stage Builds,66,4,建立一个特征全面的,CI,系统,内容,Continuous Database Integration,Continuous Testing,Continuous Inspection,Continuous Deployment,Continuous Feedback,68,4.1,Automate Database Integration,69,Repeatable Database Integration Activities,70,Use a Local Database Sandbox,71,Use a Version Control Repository to ShareDatabase Assets,Sharing your database integration scripts is a best practice, plain and simple.,Such assets might include the following:,DDL to drop and create tables and views, including constraints and triggers,Stored procedures and functions,Entity relationship diagrams,Test data for different environments,Specific database configurations,72,Continuous Database Integration,73,Give Developers the Capability to Modify the Database,74,The Team Focuses Together on FixingBroken Builds,75,Make the DBA Part of the Development Team,76,Database Integration and the Integrate Button,77,4.2,Continuous Testing,78,4.3 Continuous Inspection,79,4.4 Continuous Deployment,80,Release Working Software Any Time,Any Place,Regardless of platform, technology, or domain, deploying working software principally embodies six high-level steps.,1.,Label,a repositorys assets.,2. Produce a clean environment,free of assumptions,.,3. Generate and,label a build,directly from the repository and install it on the target machine.,4. Successfully run tests,at all levels,in a clone of the production environment.,5. Create build,feedback,reports.,6. If necessary, you can,roll back,the release by using labels in your version control repository.,81,CI Practices,82,4.5 Continuous Feedback,83,Continuous feedback mechanisms,84,5 CI的未来,85,6 Internet Resource,Continuous Integration Web Sites/Articles,86,CI Tools/Product Resources,87,Other CI Tools and Product Resources,88,Build Scripting Resources,89,Version Control Resources,90,Automated Inspection Resources,91,Documentation Resources,Doxygen,Javadoc,NDoc,92,