SQE Webinar

Category: Entertainment

Presentation Description

No description available.


Presentation Transcript

The Agile Heartbeat: 

The Agile Heartbeat John Graham-Cumming Founder


December 6, 2006 Slide 2 Agenda Why Build Mangers control the heartbeat of software engineering

The MVP: 

The MVP And it’s not a developer

The MVP: 

December 6, 2006 Slide 4 The MVP Who are the engineering team MVPs? Managers? Developers? QA? Wrong The MVP is the build manager Why?

Who Else?: 

December 6, 2006 Slide 5 Who Else? The build manager actually builds the product that’s shipped Sure, developers write the features and bugs Sure, QA tests that the product works Sure, managers do something valuable But the build manager… … that guy actually built the thing your company ships … that guy probably stayed up until 3am to make it happen So why does that guy get no decent tools?

A Brief History of Build Management: 

A Brief History of Build Management

Once Upon a Time…: 

December 6, 2006 Slide 7 Once Upon a Time… The Dark Ages Developers worked in small groups They integrated their software with each other in an ad hoc manner QA was ad hoc using builds thrown over the wall by developers When the software had to be shipped someone typed ‘make’ on The Build Machine Then they copied the installer to a floppy disk There was no such thing as a build manager

The Software Grew; the Build Grew: 

December 6, 2006 Slide 8 The Software Grew; the Build Grew Homo Buildus Sapiens appears Developers start using source code management systems and plan integration points QA relies on semi-reliable builds to test against The build grows to be a full-time responsibility: the build manager is born People look down on the build manager They give him cheap tools He is expected to ‘crank out’ a build at 3am

The Enlightenment: 

December 6, 2006 Slide 9 The Enlightenment The Build Manager puts his foot down The software no longer builds during the 8 hour work-day Developers are changing things too fast The Build Manager takes control, introduces the ‘nightly build’ The Manager gives him expensive hardware to build on He still uses rough-edged tools like Make and Perl People start complaining about broken builds The Build Manager introduces the ‘smoke test’

Polling Question: 

December 6, 2006 Slide 10 Polling Question Currently, how long are your software builds? Less than ½ hour ½ to 1 hour 1-2 hours 2-4 hours 4-8 hours Other

The Enlightenment: 

December 6, 2006 Slide 11 The Enlightenment But that could only go on for so long…

The Big Bang: 

The Big Bang

The Big Bang: 

December 6, 2006 Slide 13 The Big Bang The very essence of builds suddenly breaks The build takes longer than a night to build: 10, 11, 12 hours There is no night anymore: Sunnyvale hands off to Bangalore at 6pm Developers latch on to XP and Agile techniques They build huge unit test suites Requirements, implementation, tests change daily The Build Manager is under enormous pressure to DO SOMETHING He still gets to use rough-edged tools, many he built himself

The Rise and Rise of the MVP Build Manager: 

December 6, 2006 Slide 14 The Rise and Rise of the MVP Build Manager Once upon a time… TBM didn’t exist, being TBM was a role taken on by a developer Developers hated to be the ‘build guy’ for the day The software grew; the build grew TBM role is formalized, but developers still looked down on him The Enlightenment The Manager invites TBM to join his weekly staff meeting; TBM matters now Developers, QA and Management harass him about broken builds MVP

And The Big Bang: 

December 6, 2006 Slide 15 And The Big Bang The Build Manager’s Revenge Suddenly TBM is the most important member of the team Developers need builds to run unit tests against… … and they want them NOW! QA needs builds to test against Management looks to the build as a vital sign for software development Some teams even install red/green lava lamps indicating the status of the latest build TBM has gone from constantly criticized to mission critical

The Developers Chant: 

December 6, 2006 Slide 16 The Developers Chant Agile! XP! Continuous Integration Developers want to be able to build and test the software themselves Then check-in and get instant feedback on integration problems That means really fast build and test on demand QA needs fully-tested builds for their work They need regular builds (perhaps at most once daily) that have undergone more testing

The Build Manager Responds: 

The Build Manager Responds

And The Build Manager Says: 

December 6, 2006 Slide 18 And The Build Manager Says I need fast builds That means better build structure Fast build machines, special software for parallel builds gmake -j doesn’t give the speedup up I need I’m doing 200 builds a day, I need better tools cron just won’t cut it I need real management tools I need reporting tools Everyone wants live build feedback Perl + Excel isn’t enough I need this because builds are now the heartbeat of software engineering

The Agile Heartbeat: 

December 6, 2006 Slide 19 The Agile Heartbeat Fast builds because you’re not doing 1/day any more! Scheduled builds to satisfy regular needs e.g. QA wants a fresh tested build ready at 9am e.g. Bangalore needs a fresh build at 5pm On demand builds for special needs e.g. Putting out a patch release of an old version Stimuli builds for when things change e.g. Developer commits changes, wants an espresso build: a full build and unit test while he drinks a coffee

Getting There: DIY: 

December 6, 2006 Slide 20 Getting There: DIY Fast builds Buy lots of SMP hardware and try out GNU Make parallelism or manually parallelize the build. Scheduled builds Use cron for that On demand builds Build an intranet page, integrate it yourself with the current build and source code management system Stimuli builds Build ad-hoc script attached to source code management system


December 6, 2006 Slide 21 DIY You could try that Before you do think about… How much time do you have to write all that code? How you are going to manage 200+ builds per day? How are you going to get the build down from 4 hours to 15 minutes? How are you going to manage hardware failure in your build system? Build Managers now control the heartbeat of software engineering They need something more than a creaky Perl script

Polling Question: 

December 6, 2006 Slide 22 Polling Question Where is your organization in its adoption of agile techniques? Discussed, but no impending plans Actively working toward that now Planning to implement in next 6-12 months Planning to implement more than 12 months from now Standardized on a agile method

Better Tools for MVPs: 

December 6, 2006 Slide 23 Better Tools for MVPs Build speed tools Like ElectricAccelerator Build visualization and troubleshooting tools Like ElectricInsight Build management tools Like ElectricCommander Together these tools enable TBM to build, package, test, and deploy software And they enable Agile development

TBMs: Call to Action: 

December 6, 2006 Slide 24 TBMs: Call to Action Go to your VP of Engineering Make the sound of a heart beating OK, maybe not Tell him I said you were the MVP OK, he’s never heard of me Get Agile Highly recommended is Continuous Integration www.martinfowler.com/articles/continuousIntegration.html Look into available tools Open Source and Commercial Set yourself a goal…


December 6, 2006 Slide 25 Goal Put in place a Production Management System within six months Tell your VP You’re enabling Agile development About the projects you can’t work on today because you are babysitting builds How much more productive developers will be with Agile builds

Stepping Stones (1): 

December 6, 2006 Slide 26 Stepping Stones (1) Step 1: Put full builds in the hands of developers Set up an internal web page that allows a developer to fire off a build The developer should be able to select: Which branch to build… … or the location of his personal source tree Whether to run unit tests or not The build runs and the engineer gets an email with the result Start a new rule: developers run on demand builds before they commit

Stepping Stones (2): 

December 6, 2006 Slide 27 Stepping Stones (2) Step 2: Buy those lava lamps Set up the full build system to run more than once per day Set up a system the feedback to the entire team whether the full build succeeded red/green lava lamps or a flat panel screen mounted high enough for engineering to see and a web page showing live build status Scheduled builds start to be the heartbeat of engineering

Stepping Stones (3): 

December 6, 2006 Slide 28 Stepping Stones (3) Step 3: Speed up the build Look into tools that can speed up your build Set an under-60 minute goal for a full build and smoke test Announce to the team that multiple integrations can now happen per day, during the day These fast builds begin to enable agile development

Stepping Stones (4): 

December 6, 2006 Slide 29 Stepping Stones (4) Step 4: Fully automate Integrate your fast builds with your source code management system When the source code changes run a stimuli build and test it Now the lava lamps really matter Now the build is the heartbeat of engineering Start referring to yourself as the Build Automator not the Build Manager

Build or Buy?: 

December 6, 2006 Slide 30 Build or Buy? Each stepping stone can be implemented with home grown tools But there are a number of vendors providing Production Management Software What follows is a shameless product pitch…

Electric Cloud: 

Electric Cloud The Leader in Software Production Management

Software Production Management: 

December 6, 2006 Slide 32 Software Production Management Package Build Test Deploy Design, Define, Code Software Creation Software Production Critically important processes, but little commercial support until now SCM $1.1 B Testing $1.5 B Dev Tools Multi-Billion Too slow Too hard to manage Too hard to understand

Company Background: 

December 6, 2006 Slide 33 Slide 33 Company Background Founded 2002 by successful technologists, industry veterans Deep intellectual property: nine patents…more to come 50 leading customers worldwide In production at all customer sites: no shelf-ware

Problems That We Solve: 

December 6, 2006 Slide 34 Problems That We Solve Error prone, script intensive, ad-hoc, manual systems Disconnected build and test systems around the world Broken production builds due to ‘fire and forget’ check-ins Slow build and test systems Dependencies that are difficult to identify, address, and manage Difficulty answering compliance questions such as who built what & when and can we do it again Poor visibility and reporting in the entire SPM process


December 6, 2006 Slide 35

Software Production Management : 

December 6, 2006 Slide 36 Slide 36 Software Production Management Only Electric Cloud Solves the Whole Software Production Problem Accelerate Automate Analyze

Electric Cloud SPM Solutions: 

December 6, 2006 Slide 37 Electric Cloud SPM Solutions ElectricCommander Automate Production Processes Build Package Test Deploy ElectricInsight Visualize Software Builds ElectricAccelerator 10-20x Faster Builds SCM Tools Build Tools Make, Ant, Maven, etc. Package Tools Installers, etc. Test Tools Unit Test Tools, Code Coverage, etc. Deploy Tools Misc. Too slow Too hard to manage Too hard to understand ElectricAccelerator ElectricCommander ElectricInsight

Electric Cloud Solution: 

December 6, 2006 Slide 38 Electric Cloud Solution Slide 38 Slide 38 Accelerate Automate Analyze Web-based, automated system Unified solution with re-usable components Enable pre-flight development builds 10X -20X speed improvements Automated dependency management Easily extract build information & results Open, flexible, pinpoint reporting

Customer Success: 

December 6, 2006 Slide 39 Customer Success “With Electric Cloud, we compile and link Quickbooks every 30 minutes…broken builds are a thing of the past.” “In the morning, our builds are more predictable, and they’re more accurate. That’s because, the testing is done at the same time and there are fewer mistakes. Electric Cloud has made my job easier.” “Even if we assume that each engineer does only one build per week, the money saved in lost productivity pays for the system inside of six months.”


December 6, 2006 Slide 40


December 6, 2006 Slide 41


December 6, 2006 Slide 42 Q&A Submit your questions now For more information: Visit our website: www.electric-cloud.com E-mail: info@electric-cloud.com Phone: 650-962-4777

authorStream Live Help