Transcript All Builds Are Good With Continuous Integration Presented by: Scott Bateman Houston TechFest – August 25th, 2007

All Builds Are Good
With Continuous Integration
Presented by: Scott Bateman
Houston TechFest – August 25th, 2007
Underlying Philosophy
“Continuous Integration doesn't get
rid of bugs, but it does make them
dramatically easier to find and
remove.”
-- Martin Fowler
There are Many Horror Stories
 Many software projects have deficiencies around
builds and deployment.
• No concrete knowledge what is in compiled
executables
• Heavy dependency on a single individual
• Inability to reproduce or change prior builds (bug fix)
• No capability to produce immediate builds
• Risk of bad check in losing many productive hours
 Code integration for projects used to take days
 BuildMaster can be a full time job
• Quorum Experience evolved based on needs
We Learn From Experience
 Software Industry Changes Rapidly
15 years ago (1992) – Windows 3.1 released
Microsoft ships Visual Basic v2.0 and introduces Access
In 1992…
Internet Information Server (IIS) and Active Server Pages (ASP) don’t exist
No image has ever been seen on Internet… just text
12 years ago (1995) – Java is announced by Sun
JavaScript announced by Netscape, SourceSafe released
Internet becomes widely used, IE 1.0 released
10 years ago (1997) –Intel Releases Pentium II (233, 266 & 300 MHz)
IE 4.0 released, PVCS released
SQL Server 6.5 launches Microsoft attack on Oracle
5 years ago (2002) –Windows XP, iPod and Xbox all hit the market
.NET 1.0 released, NUnit released
2 years ago (2005) – CruiseControl.NET, NAnt released
.NET 2.0 released, IE 6.0 was the latest version
Build Upon Past Successes
 Just 15
years
ago, this
was your
Windows
desktop
(Windows 3.0)
 Continuous Integration is bound to become as
common as using a source control repository
Reaping the Benefits
 To benefit from this rapid change, projects must
analyze available tools and methodologies
 CruiseControl.NET and NAnt have been
around since about 2005, NUnit is older
 Although it will take some time to convert
existing projects, it will be worth it
 All new projects should consider using
Continuous Integration (CI)
Why Use Continuous Integration?
 Less time spent on builds/deployment
 Lower risk of error as operations are scripted
 Early notification of errors
 Easy to revert to bug-free state
 Constant availability of latest executables
 Shorter feedback cycles
 Let’s you focus on real problems, not mechanics
 Makes your boss happy – saves time and $$$
Goal is to have CRISP Builds
 C – Complete
• All components consolidated in push-button build
 R – Repeatable
• Ability to re-generate any previous build
 I – Informative
• Communicate pertinent information to stakeholders
 S – Schedulable
• Must support mechanism to run unattended
 P – Portable
• Can be run on any machine
AUTOMATED
Layers of Continuous Integration
Source
Control
Monitor
Integrate
Test
Build
Notify
Deploy
Deploy
Notify
MANUAL
Build
Potential for Human Error
Test
Deployed
Executable
Source Control
 Repository Should Contain
•
•
•
•
•
•
All source code
Baseline configuration files
Resources and images
Database scripts and code
Report templates
Documentation
 Repository Should Not Contain
• Output binaries
“everything you need to do your build, but not results”
Source Control
 No matter what tool you choose, it is
recommended to
• Label before any builds or major events
• Only check out the files you are currently working on
• Only check files out for a few days at a time.
 If you use Microsoft SourceSafe
• Use the latest version of VSS
• Don’t use VSS and Visual Studio at the same time
• read more: http://msdn2.microsoft.com/en-us/library/ms181079(VS.80).aspx
Monitor (CruiseControl.NET)
 Commit Builds
• Occur every time a change is committed
• Catch compile time problems
• Should be kept fast
- 10 minutes is a good goal
- Should not take more than 1 hour
• Monitoring devices make it fun
• Allows everyone to develop with confidence
• Should have dedicated machine
- Can be switched easily (Portable)
Demo
Real-Time Status
Best Practice
 Use monitoring
devices, Web
Dashboard
and/or CCTray
to communicate
the real-time
status of your
build
Integrate (NAnt)
 Secondary Builds
•
•
•
•
Catch run time problems
Include more elaborate testing
Static code analysis (FxCop)
Operations that may be slower such as DB
access
• In-depth validation of application
• May not be needed
- If full build/deploy is < 1 hour
• Kicked off by Commit Build or scheduled (daily)
Email Notifications
Best Practice
 Secondary
builds
executed daily
and send
detailed email
to interested
parties
Integrate (NAnt)
 Release (“Official”) Builds
• Label repository
• Update application version
• Publish results
- Email / Text Message
- RSS (can replace Visual Studio start page)
- Web page
• Update bug tracking tool
• Create installer/DVD
• Deploy to testing environment/FTP server
Demo
Frequency of Release Builds
Best Practice
 Do not do
release builds
too often if you
rely heavily on
RDBMS
 Overhead of
tracking and
validating DB
changes
Test (NUnit)
 Catching compile-time errors promotes
developer productivity
 Catching run-time errors promotes tester/user
productivity
 The goal of software should be to solve the
users’ business problems, not to make it easier
to write more software
 To this end, automated testing should buffer the
users from integration or deployment errors
Demo
Accepting Failure
 Gracefully Handling Failures
• May require the most effort of any part of CI
• Very specific to project needs
• What do you do if your build fails?
- Commit? Secondary? Release?
• How severe was the type of failure
- Invalid notification email address
- Still deploy for testing anyway?
• CI itself is made up of code
- All code has initial bugs
- All code needs to be tested
End Game
“[Continuous Integration] helps break down the
barriers between customers and development barriers which I believe are the biggest barriers
to successful software development.”
-- Martin Fowler
What about the Database?!?
 Although it is outside of the scope of this
presentation, it is possible to refactor your
database
 2 Schools of thought
• Create blank DB from scripts (rare)
• Version DB with your code & track changes
 In general, the practice is more difficult than for
code
 Database may have more dependencies than
you and your project realize
References
Martin Fowler’s Article on Continuous Integration
http://www.martinfowler.com/articles/continuousIntegration.html
Pragmatic Project Automation
http://pragmaticprogrammer.com/sk/auto
Open Source Tools
http://nant.sourceforge.net/
http://confluence.public.thoughtworks.org/display/CCNET
http://www.nunit.org/
.NET Rocks Episodes
http://www.dotnetrocks.com/default.aspx?showNum=175 (Ted Neward)
http://www.dotnetrocks.com/default.aspx?showNum=238 (Eric Sink/Martin Woodward)
http://www.dotnetrocks.com/default.aspx?showNum=193 (Joel Semeniuk)
http://www.dotnetrocks.com/default.aspx?showNum=221 (Kate Gregory)
These Slides and All links Posted on my Blog
http://www.CodeSlammer.com