Trigger a Build whenever a change occurs. it can help us reduce assumptions on a projecvt by rebuilding software whenever a change occurs in a version control system.
The value of CI:
- Reduce risks
- Defects are detected and fixed sooner
- Health of software is measurable
- Reduce assumptions
- Reduce repetitive manual processes
- CI can be run repeatly
- Generate deployable software at any time and at any place
- Enable better project visibility
- Effective decisions
- Noticing trends
- Establish greater confidence in the software product from the development team
Steps of implement CI
- Identify, find the processes that need to be automated
- Build, create some scripts to run the process
- Share, make everything managed by version control
- Continuous, let script run when a change occurs
Best Practices using CI
- Commit code frequently
- Make small changes
- Commit after each task
- At least once a day
- Do not commit broken code
- Do not commit code that does not compile with other code or fails a test
- Fix broken builds immediately
- make it as high priority
- Write automated developer tests
- Make sure tests will be run during build
- Run private builds
- This is to prevent integration failure
- Avoid getting broken code
Software Risks
- Lack of Deployable Software
- Little or no confidence in whether we could even build the software
- Lengthy integration phases before delivering the software internally or externally, during which time nothing else got done
- Inability to produce and reproduce testable builds
- Late Discovery of Defects
- Lack of Project Visibility
- Low-quality Software
Build Software at Every Change
- Perform build automatically
- Perfomr build through single command
- Separate build script from IDE
- Centralize Software Assets
- Create a Consistent Directory Structure
- Fail Builds Fast
- Build for Any Environment
- Use a Dedicated Integration Build Machine
- Use a CI Server
- Run Manual Integration Builds
- Run Fast Builds
- Stage Builds
Build Type
- Private Build
- Integration Build
- Release Build
Build Mechanisms
- On-demand
- Scheduled
- Poll for changes
- Event-driven
Responsibilities of 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
Continuous Database Integration
- Automate Database Integration
- Use a Local Database Sandbox
- Use a Version Control Repository to Share Database Assets
- DDL to drop and create tables and views, including constraints and triggers
- Stored procedures and functions
- Entity relationship diagrams
- Test data for differrent environments
- Specific database configurations
- Give Developers Capability to Modify the Database
- Make DBA Part of Development Team
Repeatable Database Integration Activities
- Drop database
- Create database
- Insert system data
- Insert test data
- Migrate database and data
- Set up database instances in multiple environments
- Modify column attributes and constraints
- Modify test data
- Modify stored procedures/functions/triggers
- Obtain access to different environments
- Back up/restore large data sets
The reliablity of a linear system is the product of the reliablity of each of the system's components, i.e. a system with three components, each component is 90% reliable, the the whold product is 73%(90%90%90%) reliable.
Unit tests verify the behavior of samll element in a software system, which are most often a single class.
Component or subsystem tests verify portions of a system and may require a fully installed system or some external dependencies, such as database, file system or network endpoint.
System tests exercise a complete software system and therefore require a fully installed system, such as a servlet container and associated databas.
Functional tests or acceptance tests are used to test the functionality of an application from the viewpoint of a client, which means the tests themselves mimic clients.
We need to categorize the tests during creating the test cases, as different kinds of tests need different duration to run.
Time requirement for test: Unit Test > Component Test > System Test
We should create test against defect. a test case can make sure: 1) you fix the defect; 2) prevent the defect from recurring.
Continuous Testing
- Automate Unit Tests
- Automate Component Tests
- Automate System Tests
- Automate Functional Tests
- Categorize Developer Tests
- Run Faster Tests First
- Write Tests for Defects
- Make Component Tests Repeatable
- Limit Test Cases to One Asset
Pair programming is treated as best practice of Agile. but many companies can not afford it.
Peer-based code reviews are generally considered benegicial to the overall quality of a code base because they present opportunities for an objective analysis by a second pair of eyes.
There are many tools can help do this, like Java's PMD and .NET's FxCop.
We prefer to use tools to run inspection automatically, Once you run a automatic build, you should run automatic inspection.
We can use NDepend or some similiar tols to check the dependencies of different classes. it will generate a human readable html report.
We need to consider how to add inspection to continous integration process, it will improve software quality.
A typical deployment includes:
- Label a repository's assets
- Produce a clean environment, free of assumptions
- Generate and label a build directly from the repository and install it on the target machine
- Successfully run tests at all levels in a clone of the production environment
- Create build feedback reports
- If necessary, you can roll back the release by using labels in your version control repository
When preparing a clean environment, it may include:
- Operating System
- Operating system configuration, i.e. network connectivity/firewall
- Server components for the software, i.e. database server/messaging server
- Server configuration
- Thrid-party tools, i.e. Web Frameworks
- Custom software
Feedback is a key output for a CI system, we should send the right information to the right people at the right time and in the right way.
Everyone needs to reveive some type of feedback on the project, but not necessarily every item every time. Sending feedback to all project members too often will ensure that everyone begins to ignore the messages. it is important that your team does not learn to ignore messages from CI build process.
The following people should receive feedback:
- Project Manager
- Architect/Technical Lead
- Developers
- Testers
At the heart of continous feedback is reducing the time between when a defect is introduces, discovered and fixed.
We can use the following ways to deliver feedback:
- SMS
- Ambient Orb and X10 Devices
- Windows Taskbar
- Sounds
- Wide-Screen Monitors
CI Tools
- Anthillpro
- Apache Continuum(Maven)
- Banboo
- BuildForge
- Continous Integration Server Matrix
- CruiseControl
- CruiseControl.NET
- Draco.NET
- Gauntlet(not found)
- LuntBuild
- ParaBuild
- PMEase QuickBuild
- Sin
Build Script Tools
- Ant
- Groovy
- Maven
- NAnt
- Rake
Version Control Tools
- ClearCase
- CVS
- MKS
- SubVersion
- SnapshotCM
- RTC
- GitHub
- Visual SourceSafe
DataBase Resources
- Hypersonic DB
- Mckoi
- MySQL
- Oracle
- PostgreSQL
Test Tools
- Agitator
- DbUnit
- Fit
- FitNesse
- Floyd(not found)
- HtmlUnit
- JUnit
- JWebUnit
- NDbUnit
- NUnit
- Selenium
- SQLUnit
- TestNG
- utPLSQL
- Watir
- xUnit Test Patterns
Inspection Tools
- Checkstyle
- Clover
- Cobertura
- EMMA
- FindBugs
- FxCop
- JavaNCSS
- JDepend
- NCover
- NDepend
- PMD
- Simian
- SourceMonitor
Deployment Resources
- Capistrano
Documentation Resources
- Doxygen
- JavaDoc
- NDoc