Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Scaling Software Development throughInternal Open Source Cloud Infrastructure<br />Chee-Chan Keng<br />Senior Manager, R&D...
F-Secure KL R&D and I<br />© F-Secure 2011<br />June 28, 2011<br />2<br />Keng Chee Chan<br />Senior Manager2007–current <...
What did we learn from Open Source Community?<br />How do most people learn about Python or Android development?<br />How ...
F-Secure R&D’s Journey towards Internal Open Source<br />© F-Secure 2011<br />June 28, 2011<br />4<br /><ul><li> Global pr...
 Blowing it big with Continuous Integration & test automation
Internal open source with Code Guardians
Everyone has equal rights to make changes
Agile Transformation
Feature Teams
 More flexibility in sharing the code
1 team per component
 Code guarded by component teams
 Too many requests from different products
 Too much planning and handover
Upcoming SlideShare
Loading in …5
×

Scaling Software Development through Internal Open Source Cloud Infrastructure

1,905 views

Published on

Published in: Technology
  • Be the first to comment

Scaling Software Development through Internal Open Source Cloud Infrastructure

  1. 1. Scaling Software Development throughInternal Open Source Cloud Infrastructure<br />Chee-Chan Keng<br />Senior Manager, R&D<br />
  2. 2. F-Secure KL R&D and I<br />© F-Secure 2011<br />June 28, 2011<br />2<br />Keng Chee Chan<br />Senior Manager2007–current <br />Quality Engineering Competence<br />Security Research Program<br />Project Manager &Sr. Software Engineer2001–2007<br />Network Management Systems<br />iDEN<br />CDMA<br />GSM<br />
  3. 3. What did we learn from Open Source Community?<br />How do most people learn about Python or Android development?<br />How does someone get on board through the documentation?<br />Is knowledge transfer needed when Open Source project members leave the project?<br />Is staff attrition a potentially critical issue for Open Source Projects?<br />Do we need mega planning and meetings to plan and design the solution?<br />How many managers are needed to run open source projects?<br />© F-Secure 2011<br />June 28, 2011<br />3<br />How can companies reap the benefits of crowd in the world of open source?<br />Could it advantageous to companies that have similar practice within the company?<br />
  4. 4. F-Secure R&D’s Journey towards Internal Open Source<br />© F-Secure 2011<br />June 28, 2011<br />4<br /><ul><li> Global private cloud
  5. 5. Blowing it big with Continuous Integration & test automation
  6. 6. Internal open source with Code Guardians
  7. 7. Everyone has equal rights to make changes
  8. 8. Agile Transformation
  9. 9. Feature Teams
  10. 10. More flexibility in sharing the code
  11. 11. 1 team per component
  12. 12. Code guarded by component teams
  13. 13. Too many requests from different products
  14. 14. Too much planning and handover
  15. 15. Heavyweight design work</li></ul> Teams overloaded and became bottlenecks <br /><ul><li> Product development spread across multiple countries
  16. 16. Major architecture changes to enable common-platform development
  17. 17. Proactive engineers and strong management support
  18. 18. Simple product lines
  19. 19. Less teams</li></ul>From triggers… to outcome<br />2005<br />2010<br />
  20. 20. From Component Teams to Feature Teams<br />© F-Secure 2011<br />June 28, 2011<br />5<br />Feature Team 1<br />Feature Team 3<br />Feature Team 2<br />Head Team<br />Eyes Team<br />Ears Team<br />Hand 1 Team<br />Hand 2 Team<br />Common Practice,Common PlatformContinuous Integration<br />Leg 2 Team<br />Leg 1 Team<br />Feature Team 6<br />Feature Team 4<br />Team specific practice,Different Platforms,<br />Integration hell<br />Feature Team 5<br />
  21. 21. F-Secure’s Internal Open Source Platform<br />A private cloud platform to enable open source use and development within R&D<br />Foundation of our product development with many people developing it 24/5<br />Over 100,000 automated tests executed automatically in the cloud, either triggered automatically with code changes, or triggered daily<br />Anybody can make improvements to the system, the person can be a programmer, tester, architect, Scrum Master, Product Owner, or a manager<br />Examples of Open Source software used: <br />Linux distributions<br />Jenkins<br />Eclipse<br />Python + nosetests<br />© F-Secure 2011<br />June 28, 2011<br />6<br />What’s new?<br />
  22. 22. F-Secure Global Private Cloud in 2010<br />© F-Secure Confidential<br />June 28, 2011<br />7<br />Hundreds of Virtual Machinesthat relies on Python Test Automations<br />
  23. 23. Damage Control…<br />Anybody can make code improvements to the system…<br />But when someone checks in codes that fail the system, how do we detect and fix it?<br />© F-Secure 2011<br />June 28, 2011<br />8<br />
  24. 24. Stop-the-Line Radiator (Project Wide)<br />© F-Secure 2011<br />June 28, 2011<br />9<br /><ul><li>Information radiators indicate development have to stop for the failed components
  25. 25. Tests are automatically triggered whenever code changes happen
  26. 26. Test Automations driven by Jenkins, written mainly in Python Language
  27. 27. Tests should pass at all times, lots of effort and commitment required
  28. 28. Radiators are shown in all corridors and team rooms.</li></li></ul><li>Stop-the-Line Radiator (Team Level)<br />© F-Secure 2011<br />June 28, 2011<br />10<br /><ul><li> Similar trick, but stops the failure at team level before the impact widens to other teams
  29. 29. Lots of effort in keeping the radiators blue</li></li></ul><li>F-Secure Internal Open Source Rules<br />No single leader that dictates<br />Everybody is allowed to improve the system directly<br />Radiators display the build and test status all the time<br />Stop-the-Line and revert commits as soon as possible<br />No new features can be added without test automation<br />When code breaks, it is everyone’s responsibility to get it fixed<br />© F-Secure 2011<br />June 28, 2011<br />11<br />With great power, comes great responsibility<br />
  30. 30. How to Scale this in the Lean & Agile Way?<br />F-Secure’sWays of Working:<br />Continuous Integration for fast feedback<br />Programmers and testers shares the same Test Automation system<br />Formation of effective feature teams<br />Strong management support and involvement in change management<br />Avoid dedicated central control - “It is everyone’s responsibility”<br />2-week sprints demo to manage expectations<br />Every team owns end-to-end software development responsibility<br />© F-Secure 2011<br />June 28, 2011<br />12<br />
  31. 31. Internal Open Source in Action!<br />© F-Secure 2011<br />June 28, 2011<br />13<br />Contributors<br />F-Secure’s Internal Open Source:Scale Confidently through Sufficient Test Automation<br />

×