1 / 42

The Agile Heartbeat

The Agile Heartbeat. John Graham-Cumming Founder. Agenda. Why Build Mangers control the heartbeat of software engineering. The MVP. And it’s not a developer. The MVP. Who are the engineering team MVPs? Managers? Developers? QA? Wrong The MVP is the build manager Why?. Who Else?.

rama-wheeler
Download Presentation

The Agile Heartbeat

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The Agile Heartbeat John Graham-Cumming Founder

  2. Agenda • Why Build Mangers control the heartbeat of software engineering

  3. The MVP And it’s not a developer

  4. The MVP • Who are the engineering team MVPs? • Managers? • Developers? • QA? • Wrong • The MVP is the build manager • Why?

  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?

  6. A Brief History of Build Management

  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

  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

  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’

  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

  11. The Enlightenment • But that could only go on for so long…

  12. The Big Bang

  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

  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

  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

  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

  17. The Build Manager Responds

  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

  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

  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

  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

  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

  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

  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…

  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

  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

  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

  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

  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

  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…

  31. Electric Cloud The Leader in Software Production Management

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

  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 Slide 33

  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

  35. Software Production Management Accelerate Automate Analyze Only Electric Cloud Solves the Whole Software Production Problem Slide 36

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

  37. Electric Cloud Solution • 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 Accelerate Automate Analyze Slide 38 Slide 38

  38. “With Electric Cloud, we compile and link Quickbooks every 30 minutes…broken builds are a thing of the past.” Customer Success “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.”

  39. 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

More Related