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.

Building an in house support team


Published on

  • Be the first to comment

Building an in house support team

  1. 1. Building an in-house Eclipse support team Pascal Rapicault Emilio Palmiero
  2. 2. › Centralized team that packages, distributes and supports Eclipse for users across Ericsson – 3 major releases/year (follow the release train) – 5 platforms (Windows 32/64, Linux 32/64, Solaris) – Many types of users, worldwide (10,000+) – Cater to different team needs – 3 full-time people Who we are what we do
  3. 3. › Grassroots movement to use Eclipse › Trend gave rise to: – Start-up problems – Configuration issues – Inconsistencies within the teams – Getting support › And so, our activities started (2006) – Economy of scale How we came to be
  4. 4. › Ease start-up › Ease configuration › Provide support Our raison d’être
  5. 5. › Produce in-house Eclipse distributions – Simple distro: Eclipse SDK, two support plug-ins, some tweaks – Custom distros for teams: domain specific IDEs – Single-user and Multi-user (shared) installs Ease start-up
  6. 6. › Make Eclipse distros available in shared space – AFS volumes for the *NIX platforms – Terminal Services on our IT Hubs for the Windows platforms › Pros: – Easy to run – Consistency for all users – Easy to roll out changes › Cons: – Users need to be told when to move to a new base – Issues with UNC paths in Windows Shared deployment
  7. 7. › Assembling your Eclipse distro obeys the 80/20 rule – Detail-oriented task – If you need to patch, just build what you need › Need to test! › Limitations with shared installs – Ericsson sponsored the implementation of a Migration Wizard Lessons learned
  8. 8. › Unique update site for an eclipse “stream” – User-friendly categories – Pre-validated (no external reference) – Browsable content – Regularly refreshed › One-click install of groups of plug-ins – Intended for teams – Ensures everybody has the same plug-ins › Preferences distribution – Ensures everybody has the same preferences – Done at install time Ease configuration
  9. 9. › Update site in a runnable format and available in shared space – Economy of space – Reduced install times – Share plug-ins beyond those available in the distro – Plug-ins loaded and bootstrapped from the common catalog – Ability to add your own plug-ins Catalog in shared environment
  10. 10. › Mirror the update sites in- house › Don’t mirror blindly – Validation is required – In shared environment, be careful with root files (e.g. jad.exe) › Follow the community for the most used plug-ins – Help the community where you can (e.g. create p2-friendly sites) › Don’t be shy: be ready to patch and know your p2 metadata Lessons learned
  11. 11. › Mostly for installation and configuration issues › In-house support plug-in packaged in the distro – Helpdesk from within Eclipse – Log collector (configuration details, .log, p2 profile) › MLs, disussion forums, RSS feeds › In-house Stats Collector – See the trend, help the focus – Justify our salaries – Dashboard Support
  12. 12. Blank content area
  13. 13. › Uniform environment helps support › Easy to get logs to diagnose a problem › Set the expectations right – We are not experts on all plug-ins – We won’t fix your compile error Though we could  › Wished there were fault codes in plug-ins Lessons learned
  14. 14. › Better understand our usage patterns – Smoke tests for common usage scenarios – Provide recommendations – Better invest in projects › Proactively detect problems › Workspace setup (e.g. project) Going forward
  15. 15. › Many ways to manage Eclipse › Having an Eclipse support team is must for Ericsson › Are you ready to admit the cost of a free tool? conclusion
  16. 16. Q&a
  17. 17. Twitter: @prapicault Email: