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

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

Embed Size (px)

Citation preview

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

All Builds Are GoodAll Builds Are GoodWith Continuous IntegrationWith Continuous Integration

Presented by: Scott BatemanPresented by: Scott Bateman

Houston TechFest – August 25Houston TechFest – August 25thth, 2007, 2007

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

Underlying PhilosophyUnderlying Philosophy

““Continuous Integration doesn't get Continuous Integration doesn't get rid of bugs, but it does make them rid of bugs, but it does make them dramatically easier to find and dramatically easier to find and remove.”remove.”

-- Martin Fowler-- Martin Fowler

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

There are Many Horror There are Many Horror StoriesStories

Many software projects have deficiencies Many software projects have deficiencies around builds and deployment.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 daysCode integration for projects used to take days BuildMaster can be a full time jobBuildMaster can be a full time job

• Quorum Experience evolved based on needs

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

We Learn From ExperienceWe Learn From Experience

Software Industry Changes RapidlySoftware Industry Changes Rapidly15 years ago (1992) – Windows 3.1 releasedMicrosoft ships Visual Basic v2.0 and introduces AccessIn 1992…Internet Information Server (IIS) and Active Server Pages (ASP) don’t existNo image has ever been seen on Internet… just text12 years ago (1995) – Java is announced by SunJavaScript announced by Netscape, SourceSafe releasedInternet becomes widely used, IE 1.0 released10 years ago (1997) –Intel Releases Pentium II (233, 266 & 300 MHz)IE 4.0 released, PVCS releasedSQL Server 6.5 launches Microsoft attack on Oracle5 years ago (2002) –Windows XP, iPod and Xbox all hit the market.NET 1.0 released, NUnit released2 years ago (2005) – CruiseControl.NET, NAnt released.NET 2.0 released, IE 6.0 was the latest version

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

Build Upon Past SuccessesBuild Upon Past Successes

Just 15 Just 15 years years ago, this ago, this was your was your Windows Windows desktopdesktop

(Windows 3.0)(Windows 3.0)

Continuous Integration is bound to become as Continuous Integration is bound to become as common as using a source control repositorycommon as using a source control repository

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

Reaping the BenefitsReaping the Benefits

To benefit from this rapid change, projects must To benefit from this rapid change, projects must analyze analyze available toolsavailable tools and methodologies and methodologies

CruiseControl.NETCruiseControl.NET and and NAntNAnt have been have been around since about 2005, around since about 2005, NUnitNUnit is older is older

Although it will take some time to convert Although it will take some time to convert existing projectsexisting projects, it will be worth it, it will be worth it

All All new projectsnew projects should consider using should consider using Continuous Integration (CI)Continuous Integration (CI)

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

Why Use Continuous Why Use Continuous Integration?Integration?

Less time spent on builds/deploymentLess time spent on builds/deployment Lower risk of error as operations are scriptedLower risk of error as operations are scripted Early notification of errorsEarly notification of errors Easy to revert to bug-free stateEasy to revert to bug-free state Constant availability of latest executablesConstant availability of latest executables Shorter feedback cyclesShorter feedback cycles Let’s you focus on real problems, not mechanicsLet’s you focus on real problems, not mechanics Makes your boss happy – saves time and $$$Makes your boss happy – saves time and $$$

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

Goal is to have CRISP BuildsGoal is to have CRISP Builds

C – CompleteC – Complete• All components consolidated in push-button build

R – RepeatableR – Repeatable• Ability to re-generate any previous build

I – InformativeI – Informative• Communicate pertinent information to stakeholders

S – SchedulableS – Schedulable• Must support mechanism to run unattended

P – PortableP – Portable• Can be run on any machine

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

Test

Test

Deploy

Layers of Continuous Layers of Continuous IntegrationIntegration

Monitor

Build

Integrate

Notify

Build

SourceControl

DeployedExecutable

NotifyDeploy

A U

T O

M A

T E

DM

A N

U A

L

Potential for Human Error

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

Source ControlSource Control

Repository Should ContainRepository Should Contain• All source code• Baseline configuration files• Resources and images• Database scripts and code• Report templates• Documentation

Repository Should Not ContainRepository Should Not Contain• Output binaries

““everything you need to do your build, but not results”everything you need to do your build, but not results”

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

Source ControlSource Control

No matter what tool you choose, it is No matter what tool you choose, it is recommended torecommended 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 SourceSafeIf 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

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

Commit BuildsCommit 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)

Monitor (CruiseControl.NET)Monitor (CruiseControl.NET)

DemoDemo

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

Real-Time StatusReal-Time Status

Use monitoring Use monitoring devices, Web devices, Web Dashboard Dashboard and/or CCTray and/or CCTray to communicate to communicate the real-time the real-time status of your status of your buildbuild

Best PracticeBest Practice

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

Integrate (NAnt)Integrate (NAnt)

Secondary BuildsSecondary 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)

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

Email NotificationsEmail Notifications

Secondary Secondary builds builds executed executed dailydaily and send and send detailed email detailed email to interested to interested partiesparties

Best PracticeBest Practice

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

Integrate (NAnt)Integrate (NAnt)

Release (“Official”) BuildsRelease (“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 DemoDemo

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

Frequency of Release BuildsFrequency of Release Builds

Do not do Do not do release builds release builds too often if you too often if you rely heavily on rely heavily on RDBMSRDBMS

Overhead of Overhead of tracking and tracking and validating DB validating DB changeschanges

Best PracticeBest Practice

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

Test (NUnit)Test (NUnit)

Catching Catching compile-timecompile-time errors promotes errors promotes developer productivitydeveloper productivity

Catching Catching run-timerun-time errors promotes errors promotes tester/user tester/user productivityproductivity

The goal of software should be to solve the The goal of software should be to solve the users’ business problems, not to make it easier users’ business problems, not to make it easier to write more softwareto write more software

To this end, automated testing should buffer the To this end, automated testing should buffer the users from integration or deployment errorsusers from integration or deployment errors

DemoDemo

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

Accepting FailureAccepting Failure

Gracefully Handling Failures 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

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

End GameEnd Game

““[Continuous Integration] helps break down the [Continuous Integration] helps break down the barriers between customers and development - barriers between customers and development - barriers which I believe are the biggest barriers barriers which I believe are the biggest barriers to successful software development.”to successful software development.”

-- Martin Fowler-- Martin Fowler

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

What about the Database?!?What about the Database?!?

Although it is outside of the scope of this Although it is outside of the scope of this presentation, it is possible to refactor your presentation, it is possible to refactor your databasedatabase

2 Schools of thought2 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 In general, the practice is more difficult than for codecode

Database may have more dependencies than Database may have more dependencies than you and your project realizeyou and your project realize

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

ReferencesReferences

Martin Fowler’s Article on Continuous Integrationhttp://www.martinfowler.com/articles/continuousIntegration.html

Pragmatic Project Automationhttp://pragmaticprogrammer.com/sk/auto

Open Source Toolshttp://nant.sourceforge.net/http://confluence.public.thoughtworks.org/display/CCNEThttp://www.nunit.org/

.NET Rocks Episodeshttp://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