Building an in house support team
Upcoming SlideShare
Loading in...5

Building an in house support team






Total Views
Views on SlideShare
Embed Views



0 Embeds 0

No embeds



Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
Post Comment
Edit your comment
  • Introduce ourselves, describe our roles. <br /> Describe what Ericsson does. We don’t make phones! Ericsson builds mobile and fixed networks, multimedia solutions and provides telecom services. <br /> Introduce the talk and mention that we have a more technical talk tomorrow around tools and automation. <br /> 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. <br /> For the why’s, we explain the genesis of the team, its evolution, and the services offered today. <br /> 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 <br />
  • Ericsson loves OSS – OSS dev stack: Git, Gerrit, Maven, Tycho, Tuleap, GDB, etc. <br /> Ericsson loves Eclipse: <br /> - Contribute to projects, lead / co-lead projects (e.g. CDT, Mylyn reviews, Linux tracing) <br /> - Pay companies to do contributions to p2 <br /> 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. <br />
  • Frequent minor releases and updates. <br /> Different level of familiarity with Eclipse. <br /> Many different use cases. <br />
  • Start-up problems: <br /> - which version of Eclipse should I download and use? <br /> Configuration issues: <br /> - Plug-in dependency hell (this was pre-p2) <br /> - Appropriate settings: VM, preferences <br /> Getting support: <br /> - We can’t unleash 10,000 users to the community, that would be unfair! <br />
  • Explain that this is the outline of the presentation. <br /> For each of these items, describe what we do to address the issue and what we learned in doing so. <br />
  • Domain specific IDEs: TOSIDE for C/C++, AIDE for AXE (Ericsson proprietary) <br />
  • AFS (Andrew File System) is a distributed file system available in the Ericsson network. <br /> - AFS makes file sharing easy, while not compromising the security of the shared files. <br /> - A mount point (directory) is created on the local disk of each AFS client machine, so AFS acts as an extension of your machine&apos;s local UNIX file system. <br /> Terminal Services are now called Remote Desktop Services. <br /> HUBs are centralized servers for hosting applications and data over the Ericsson network (e.g. Jenkins, Sonar, Git/Gerrit). <br /> - There are 8 HUBs at Ericsson. There is a also pool of virtual boxes (e.g. Linux, Windows, etc.) <br /> - Centralized in order to reduce cost and improve performance. <br /> Each release is made available in a separate folder. <br /> 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. <br /> Cons: <br /> - Users need to be told when to move to a new base. <br /> - 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). <br /> - Example of UNC issue: ANT <br />
  • 80/20 rule: <br /> - The first 80 percent of building the distro is easy compared to that last 20 percent. <br /> - 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%. <br /> Detail-oriented task: <br /> product files, p2.inf, root files. <br /> Build what you need: <br /> do not maintain your own fork. <br /> Need to test: <br /> Don’t wait to test builds for key dependencies <br /> Test all the way <br /> Limitation with shared installs: <br /> When base changes, user loses all his plug-ins without knowing about it! <br />
  • Update site configured by default. <br /> Multiple versions of the same plug-in are available. We don’t remove content from the site. <br /> EPP packs offered as features in a separate category. <br />
  • We are not experts on all plug-ins. <br /> EECS Support plug-in: allows to connect to the Ericsson central ticketing system. Users can attach the zip file of logs collected. <br /> Stats collector: our own fork of UDC. Used to know how many times Eclipse is started and which perspectives, views and commands are used. <br />
  • The most popular plug-ins (to know where to invest) <br /> Stickiness of plug-ins <br /> Smoke tests for most common scenarios (e.g. clone a git repo, import projects into the workspace, build, run) <br />
  • Many ways to manage Eclipse, but the right solution depends on the corporate needs, setup and mindset. <br /> Having an eclipse team is an economy of scale. <br /> Figure out what’s the right number for you? What is the problem you are trying to solve? <br /> Chances are that there is already somebody doing it, but are they legit? <br /> You decide how to deal with the TCO. <br /> 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. <br />

Building an in house support team Building an in house support team Presentation Transcript

  • 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: @prapicault Email: