Building an in-house Eclipse support team

Pascal Rapicault

Emilio Palmiero

› 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

› 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

› Ease start-up

› Ease configuration

› Provide support

Our raison d’être

› 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

› 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

› 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

› 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

› 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

› 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

› 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

Blank content area

› 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

› 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

› 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

Q&a

Twitter: @prapicaultEmail: pascal.rapicault@ericsson.com