Continuous Integration

1
Continuous Integration

• Improving Quality and Reducing Cost Through
• Constructive Laziness

2
Our Locations
3
Where we start

• Releases built by developers
• Process is manual

4
Where this hurts

• Time consuming
• Inconsistent
• Error Prone
• Inconvenient

5
What do we want?

• Simple
• Minimal manual effort
• Reliable and Consistent

6
What we want is Continuous Integration

• Continuous Integration is a software development
  practice where members of a team integrate their
  work frequently, usually each person integrates
  at least daily - leading to multiple integrations
  per day. Each integration is verified by an
  automated build (including test) to detect
  integration errors as quickly as possible.
  Martin Fowler
• http//www.martinfowler.com/articles/continuousInt
  egration.html

7
Pre-requisites

• Source control
• A system to act as the build server
• A build process that can be automated

8
Example Building a Solution with TeamCity
9
What have we got?

• Every check in is tested to verify that the
  system builds
• This is a good start but hardly earth shattering

10
What next?

• Packaging
• Testing
• Code analysis

11
How do we achieve this?

• Working with solution files is easy but limited
• A build tool provides significantly more power
• Many options
• MSBuild
• NAnt
• Rake
• Ant
• Maven
• Custom scripts

12
Example Revisited Custom Build File
13
Whats been added?

• Automated testing
• Automatic versioning
• Labelling in source control
• Automatically assigned file version number
• Encoding of source information in assembly
  metadata
• Production of package containing usable system

14
Tools added

• MSBuild
• Test runner provided Gallio (http//www.gallio.org
  )
• Automatic versioning and zip capability through
  the MSBuild Community Tasks (http//msbuildtasks.t
  igris.org/)
• Other tools such as WiX (http//wix.sourceforge.ne
  t/) can also be integrated

15
Assistance with code quality

• Variety of code analysis tools exist
• FxCop
• NDepend
• Integrating analysis allows us to detect and
  resolve issues as they are introduced

16
Example Integrating FxCop
17
Best Practices

• Include all tools and dependencies in source
  control
• Monitor the build state and correct issues
  quickly
• Build process should be complete
• Produce outputs suitable for the relevant
  environments

18
Potential Pitfalls

• Configuring the CI server to work from the base
  of your source control
• Long paths are problematic
• Branches that are not self-contained
• Existing projects may contain elements that are
  difficult to automate

19
Summary of Benefits

• Faster Feedback
• Automated Analysis
• Simplified Releases
• Repeatability and Consistency
• Lower Risk
• Laziness

20
Options

• JetBrains TeamCity (http//www.jetbrains.com/teamc
  ity)
• Team Foundation Build Server
• CruiseControl.NET (http//confluence.public.though
  tworks.org/display/CCNET/)
• Others

21
About the example project

• Abstract2ion is a small library for wrapping
  common BCL types to assist with breaking
  dependencies
• http//abstract2ion.googlecode.com/
• Apache 2.0 License
• Contains the build files used in this
  presentation
• Contributions welcome

22
Questions?

• ?