Download to read offline
Uploaded byPascal Rapicault
Building an in house support team
The document describes Ericsson's in-house Eclipse support team, which packages, distributes, and supports Eclipse for over 10,000 users across the company. The team releases 3 major Eclipse versions per year across 5 platforms. They provide centralized support to help with startup issues, configuration problems, inconsistencies, and getting help. The team produces customized Eclipse distributions, makes them available on shared network drives, and provides an internal update site and support plug-in to help with installation, configuration, and getting support within Eclipse.
Building an in house support team
- 1. Building an in-houseEclipse support team Pascal Rapicault Emilio Palmiero
- 3. › Centralized teamthat 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
- 4. › Grassroots movementto 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
- 5. › Ease start-up ›Ease configuration › Provide support Our raison d’être
- 6. › Produce in-houseEclipse 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
- 7. › Make Eclipsedistros 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
- 8. › Assembling yourEclipse 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
- 9. › Unique updatesite 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
- 10. › Update sitein 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
- 11. › Mirror theupdate 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
- 12. › Mostly forinstallation 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
- 13.
- 14. › Uniform environmenthelps 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
- 15. › Better understandour usage patterns – Smoke tests for common usage scenarios – Provide recommendations – Better invest in projects › Proactively detect problems › Workspace setup (e.g. project) Going forward
- 16. › Many waysto manage Eclipse › Having an Eclipse support team is must for Ericsson › Are you ready to admit the cost of a free tool? conclusion
- 17.
- 18.
Editor's Notes
- #2 Introduce ourselves, describe our roles. Describe what Ericsson does. We don’t make phones! Ericsson builds mobile and fixed networks, multimedia solutions and provides telecom services. Introduce the talk and mention that we have a more technical talk tomorrow around tools and automation. For now 5 years, Ericsson has been providing its development teams with an in-house Eclipse support group whose mandate is to smoothen the distribution of Eclipse and help our 10,000 users with their day-to-day operations.In this talk we reflect on both the why’s and the how’s of our team. For the why’s, we explain the genesis of the team, its evolution, and the services offered today. For the how’s, we give an overview of the challenges we met:- Distributing Eclipse in shared environments (AFS and Windows TS)- Managing preferences for a team- Gathering information for diagnostic purpose- Monitoring Eclipse usage- Dealing with upstream problems
- #3 Ericsson loves OSS – OSS dev stack: Git, Gerrit, Maven, Tycho, Tuleap, GDB, etc. Ericsson loves Eclipse: - Contribute to projects, lead / co-lead projects (e.g. CDT, Mylyn reviews, Linux tracing) - Pay companies to do contributions to p2 Ericsson is not a tool vendor. We need tools to satisfy our needs, develop our products. It is faster to do it in-house, than to wait for vendors to figure out our need and to be willing to implement something they see as a one-off.
- #4 Frequent minor releases and updates. Different level of familiarity with Eclipse. Many different use cases.
- #5 Start-up problems: - which version of Eclipse should I download and use? Configuration issues: - Plug-in dependency hell (this was pre-p2) - Appropriate settings: VM, preferences Getting support: - We can’t unleash 10,000 users to the community, that would be unfair!
- #6 Explain that this is the outline of the presentation. For each of these items, describe what we do to address the issue and what we learned in doing so.
- #7 Domain specific IDEs: TOSIDE for C/C++, AIDE for AXE (Ericsson proprietary)
- #8 AFS (Andrew File System) is a distributed file system available in the Ericsson network. - AFS makes file sharing easy, while not compromising the security of the shared files. - A mount point (directory) is created on the local disk of each AFS client machine, so AFS acts as an extension of your machine's local UNIX file system. Terminal Services are now called Remote Desktop Services. HUBs are centralized servers for hosting applications and data over the Ericsson network (e.g. Jenkins, Sonar, Git/Gerrit). - There are 8 HUBs at Ericsson. There is a also pool of virtual boxes (e.g. Linux, Windows, etc.) - Centralized in order to reduce cost and improve performance. Each release is made available in a separate folder. This way we don’t change the base and users do not need to upgrade to a newer release if they don’t need to or aren’t ready to do so. Cons: - Users need to be told when to move to a new base. - UNC (Uniform Naming Convention) specifies a common syntax to describe the location of a network resource, such as a shared file (also called network path). - Example of UNC issue: ANT
- #9 80/20 rule: - The first 80 percent of building the distro is easy compared to that last 20 percent. - You get through 80% of the work fairly fast, but the pesky 20% of work remaining seems to take 4 times as long as the previous 80%. Detail-oriented task: product files, p2.inf, root files. Build what you need: do not maintain your own fork. Need to test: Don’t wait to test builds for key dependencies Test all the way Limitation with shared installs: When base changes, user loses all his plug-ins without knowing about it!
- #10 Update site configured by default. Multiple versions of the same plug-in are available. We don’t remove content from the site. EPP packs offered as features in a separate category.
- #13 We are not experts on all plug-ins. EECS Support plug-in: allows to connect to the Ericsson central ticketing system. Users can attach the zip file of logs collected. Stats collector: our own fork of UDC. Used to know how many times Eclipse is started and which perspectives, views and commands are used.
- #16 The most popular plug-ins (to know where to invest) Stickiness of plug-ins Smoke tests for most common scenarios (e.g. clone a git repo, import projects into the workspace, build, run)
- #17 Many ways to manage Eclipse, but the right solution depends on the corporate needs, setup and mindset. Having an eclipse team is an economy of scale. Figure out what’s the right number for you? What is the problem you are trying to solve? Chances are that there is already somebody doing it, but are they legit? You decide how to deal with the TCO. For Ericsson, it’s more beneficial to have a support team in place than to have many developers wasting their time debugging Eclipse issues, rather than doing actual code for their product.