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,847 views

Published on

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,847
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
32
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • Open Source thinking is still new to many companiesFor all kinds of reasons, many companies are still not making their products available to the open source community (private or public), so how can these companies reap the benefits of crowd in the world of open source?One way is to start seeding Open Source thinking within R&amp;D
  • Internal Open Source is not a new ideaHow did we do it differently?
  • 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 />

    ×