all builds are good n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
All Builds Are Good PowerPoint Presentation
Download Presentation
All Builds Are Good

Loading in 2 Seconds...

play fullscreen
1 / 22

All Builds Are Good - PowerPoint PPT Presentation


  • 82 Views
  • Uploaded on

All Builds Are Good. With Continuous Integration. Presented by: Scott Bateman Houston TechFest – August 25 th , 2007. Underlying Philosophy. “Continuous Integration doesn't get rid of bugs, but it does make them dramatically easier to find and remove.” -- Martin Fowler.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'All Builds Are Good' - leia


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
all builds are good

All Builds Are Good

With Continuous Integration

Presented by: Scott Bateman

Houston TechFest – August 25th, 2007

underlying philosophy
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
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
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
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
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
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
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
layers of continuous integration
Layers of Continuous Integration

Source

Control

Monitor

Build

Integrate

Notify

Test

Deploy

Deployed

Executable

A U T O M A T E D

Build

Deploy

Notify

Test

M A N U A L

Potential for Human Error

source control
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 control1
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

Demo

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)
real time status
Real-Time Status
  • Use monitoring devices, Web Dashboard and/or CCTray to communicate the real-time status of your build

Best Practice

integrate nant
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
Email Notifications
  • Secondary builds executed daily and send detailed email to interested parties

Best Practice

integrate nant1

Demo

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
frequency of release builds
Frequency of Release Builds
  • Do not do release builds too often if you rely heavily on RDBMS
  • Overhead of tracking and validating DB changes

Best Practice

test nunit

Demo

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
accepting failure
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
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
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
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