《Continuous Integration》读书笔记

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:

eMail
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