The document discusses the rise of continuous integration (CI) and introduces Hudson, an open-source CI server designed for easy installation and use. It highlights Hudson's extensive community support, plugin system, and features that promote automation, efficiency, and transparency in the development process. The document emphasizes the benefits of Hudson in reducing turnaround time and improving communication among developers and quality assurance teams.

1. HudsonSF JUGKohsuke KawaguchiSun Microsystems, Inc.

2. Rise of Continuous IntegrationOffload from people, push to computers$computerspeopletime2

3. Spend more CPU power to help youFirst on your laptops and workstationsIDEs are at the forefrontAnd then to the serversa.k.a. “Continuous Integration”More frequent build/test executionsStatic code analysis toolsAnd more to come3

4. HudsonOpen-source CI serverEmphasis on ease of installation and use“java -jar hudson.war” executionOr your OS-specific packageConfigure everything from browsersExtensibility230+ community-developed public pluginsBy 230+ contributorsEstimated 13,000 installations4https://hudson-ci.org/

5. Adoption in all kinds of businesses5

6. Support SubscriptionsCommunity releases every weekOver 340 releases to dateRapid new features & bug fixes delivery“Sun Continuous Integration Server”For enterprise that needs stabilityBug fix only patch releases for 18 months6

7. Basic Feature SetHudson notices that there is a changeCheck out the source codeCVS, Subversion, ClearCase, Mercurial, Accurev, Perforce, Git, StarTeam, …Do buildsAnt, Maven, shell script, NAnt, …Record and publish resultsClose the feedback loopRSS feedsE-mail/IM notificationTray application to notify developersTool integrationFindbugs, cobertura, …7

8. Demo

9. Why do I care?Life before HudsonDev forgets to commit a fileRE nightly build breaks. It blocks SQEPeople waste timeLife after HudsonHudson will tell you in 5 mins if a build brokeNo one else notices that you forgot to commit a file9

10. Why do I care?Life before HudsonDev makes a change Monday AMSQE nightly finds a bug Monday nightDev fixes it TuesdayLot of wasted timeLife after HudsonDev makes a change Monday AMHudson finds a regression 30 mins laterDev can fix it before lunch10

11. Why do I care?Life before HudsonSQE test runs every night, results sent out in e-mailAfter the enthusiasm of the 1st week is gone, nobody looks at them anymoreRegressions go unnoticed until it’s too lateLife after HudsonTests run Hudson after every commitE-mail sent out only when tests start failingSo it manages to keep people’s attention11

12. Matrix projectsRun the same thing on different environmentssuch as different JDKs, different databases, and different OSesAggregate the results12

13. FindBugs integration13

14. Tracking changes14

15. … and moreBrowse workspacesBuild time trend report15

16. Inter-Project SupportYou can host many projects on 1 HudsonAnd when you do, 1+1 becomes more than 2You can…Execute tests separately and correlate them with buildsMark builds as “promoted” based on test outcomeTrack which build of libraries are used whereAnd more16

17. Test/Build SeparationTests often dominate the build timeMultiple tests are run in parallelImproves turn-around timetimeJAX-WS #10JAX-WS #11JAX-WS #12…Unit test with GFUnit test with TomcatSQE testTest w/o container3OS x 2JDK = 6 tests17

18. Test/Build Separation TechniqueCopy bits from the build to test via wget by permalinksAnt has the equivalent <get> task“Fingerprinting” to keep track of where binaries are used$ wget –O foo.zip http://server/hudson/job/foo/lastSuccessfulBuild/ artifact/foo.zip18

19. Build PromotionCI produces a lot of “successful” buildsOften overwhelming to downstream consumersRun tests as fast as you canIf a build passes tests, promote it19

20. Got the idea?AutomationReduce turn-around timeMake things transparentRemove people from the loopSave people’s timePush jobs to servers, keep workstations idle for you20

21. Doing Distributed Builds21

22. Why?There’s only so much 1 computer can doBut lots of PCs = tediousWhat does Hudson do to help you?22

23. Installing new slavesFor first 20 or so slaves, we did it manuallyInsert CD, click, type, click, type, click, …But that doesn’t scaleThen we automatedAvailable as “Hudson PXE Plugin”23

24. Automated System InstallationsHudson + PXEplugin

25. ISO images of OSSlavesPower on, hit F12PC boots from network (PXE)24

26. Automated System InstallationsHudson + PXEplugin

27. ISO images of OSYour corporate IT guy & his DHCP serverSlavesPower on, hit F12PC boots from network (PXE)Choose OS from menuInstalls non-interactively25

28. Distributed builds with HudsonMasterServes HTTP requestsStores all important infoSlaves170KB single JARAssumed to be unreliableScale to at least 100LinkSingle bi-di byte streamNo other requirements26

29. How master and slaves start talkingFor Unix slaves, via SSHOnly need SSHD and JRE on slavesWe just need a host name27

30. How master and slaves start talkingFor Windows, DCOMWe just need admin user name and passwordNo manual interventionWorks even from Unix masters28

31. How master and slaves start talkingVia Java Web StartWhen master cannot see slavesA separate socket connection is made29

32. Automating JNLP launchOnce started, can be installed as Windows service30

33. Automating JNLP launchEmulate the JNLP client headless$ java -jar slave.jar -jnlpUrl URL31

34. Automated Tool Installation - JDKJDK from http://java.sun.com/Hudson automatically chooses the right bundleAlways up to date with new releases32

35. Automated Tool Installation - ApacheAnt and Maven from Apache33

36. Heterogeneous Cluster ChallengeYour builds/tests need to run in specific environmentDependency on individual nodes hurts utilizationjobsslavesWombatWindows testWindows #1GlassFishWindows testWindows #2Hudson Windows testSolaris#1Hudson Solaris test34

37. Labels to rescueLabel is a group of slavesTie jobs to labelsjobsslavesWombatWindows testWindows #1WindowsGlassFishWindows testWindows #2Hudson Windows testSolaris#1SolarisHudson Solaris testWindows #335

38. Concurrent Builds36Hudson #10Hudson #11Hudson #12Hudson #13Hudson #14Hudson #15time

39. Making builds stickyWe want jobs to be mostly on the same slaveFaster check outConsistent resultsMinimizes disk consumptionBut does it softlyHudson uses consistent hash* to achieve thisMore schedule controls become possible:Use faster machines more frequentlySlowly ramp up newly installed slaves* http://en.wikipedia.org/wiki/Consistent_hashing37

40. Forecasting failuresHudson monitors key health metrics of slavesLow disk space, insufficient swapClock out of syncExtensibleSlaves go offline automatically38

41. Clean up mess after buildsKill run-away processesDaemons, background processes left by your buildWorks on Windows, Linux, Mac, and Solaris39

42. Load Statistics Monitoring40

43. When it’s time to add more slaves41

44. Hudson EC2 pluginAutomatically provisions slaves on EC2 on demandBased on the current loadPicks the right AMI depending on demandStarts slave agentShuts down unused instances42

45. Putting it all togethercapacity# of executorsusagequeue lengthtime43

46. Hudson “Appliance” on EC2Run the master in the cloud too, if you likeHudson on stock OpenSolaris AMIData stored persistently in Elastic Block StorageDynamically expandable thanks to ZFSOnline, tooPackaged as a wizard44

47. And a lot more I couldn’t showIDE pluginsiPhone/Android appsREST API and CLIDeployment AutomationHadoop, Selenium…45

48. ConclusionsCI is here to stayUsing lots of PCs is a keyHudson is very easy to get startedOnce started, there are a lot you can do46