Agenda for Backstage Community Session (December 15 & 16, 2021) about community HOT 14 CLOSED

[Adopters] We at Brex would like to do a presentation on our Adoption journey, feel free to reach out to me for any info needed prior to presenting!

from community.

[Contributors]

I will present Backstage upgrade helper, a web tool to support Backstage developers in upgrading their apps.
Feel free to check it out!
During the session I will share more information about how it works.

from community.

[Adopters]

@gloscott We call it "Pandora" at Trendyol. Everyone seems to like the name.

We are very open about it being powered by Backstage and we are trying to contribute to it when we can. We are planning to contribute with a few major plugins in 2022.

from community.

At HP Inc I never considered branding it 'Backstage' - we have an external 'Dev Portal' at hp.io, so for our internal Backstage-backed private portal overhaul I called it 'hp.dev'. We're doing a little more than the core Backstage catalog UI on our front-end though, and our communities seem fine with the name. Still, maybe I should think about branding with a little more care.

from community.

[Adopters]

I'd love to hear about other adopters' thought processes / ideas on whitelabeling Backstage within their organizations—how many adopters are using a whitelabel name vs. the name Backstage as-is vs. referring to their instance of Backstage generically as "{companyName} Developer Portal"?

(we are getting some pressure to do the generic thing 😬)

from community.

@gloscott At Voi, we call it "Warf". But as @petejespersqbe, we're very open that it's Voi's flavor of Backstage :)

Having a Voi-specific name helped the engineering community understand that it's not only Backstage and that we can make it grow/evolve as we need.

from community.

@gloscott At Brex, we have kept the Backstage naming (and styling) although we do refer to it as the "Developer Portal" from time to time mostly in the context "Backstage is our Developer Portal". We would like to do a better job theming our application, although unclear if we will ever rename at this point

We haven't really spent any time renaming or rebranding it focusing mostly on development work since our team doesn't have any product, design, or frontend team members who might be able to better own that process. We are mostly fullstack platform engineers with a focus on backend

from community.

@gloscott At Pluralsight, we call it the dev-portal. A while ago, before adopting Backstage, we did an experiment with it. Unfortunately, many in our org still associate backstage with that experiment and it now causes confusion. So, it was best for us to pivot to dev-portal for our adoption.

from community.

@gloscott At PagerDuty, we call it Backstage 😄 (we changed the colours+logo+styling though).

from community.

@gloscott At QBE we've named our instance DevHub but we're being very open in all comms that it is Backstage. We've found that it's helping us get buy in simply by pointing to the adopters list and saying "well, all these companies can't be wrong can they?"

from community.

Recordings of both the sessions are now available!
https://www.youtube.com/watch?v=0QMQYSTKAx0
https://www.youtube.com/watch?v=nYjI2j-lWEM

from community.

[adopters] Something we are starting to think about more is team/group management and 3rd party dependency management in Backstage

For context, we have had a lot of re orgs and team splits over the last year. Every time this happens managers have to create all their new resources, github team, slack channels, pager duty teams/escalation policies, etc. This has also led to constantly out of date information for ownership in Backstage. We currently rely on the github org discovery processor to populate our groups/users and github team names are owners of entities.

I'd be curious to hear how others handle this and think about team management/keeping things in sync. Especially how Spotify has handled this

we are looking at a way to allow managers create/update teams through Backstage, and potentially use the catalog processors to trigger resource provisioning when needed

from community.

[Adopters]

Question to all adopters

• What metrics are you using to monitor your Backstage adoption in the organization? (daily active users, most active plugins, Catalog trends, etc.)
• How are you tracking these metrics? Would a plugin suggestion like this backstage/backstage#8398 help?

from community.

We use segment to track our metrics, we kind of hacked the existing googleAnalytics code to use segment instead of [google tag manager] (we load segment in the index.html and then it's available in window.analytics)

(https://github.com/backstage/backstage/blob/master/packages/app/public/index.html#L52). Basically backstage FE -> segment -> data warehouse -> visualizations in business intelligence/visualization tool

Things we are tracking

• Weekly usage (sessions and unique users)
• Creation of software through the catalog (this is currently based on PR names pulled from git data)
• Weekly plugin usage based on unique users and page views for the given plugin, this is generally broken into the sidebar plugin page itself as well as the entity plugin tab. It's nice being able to look at specific page views so we can see what parts of a plugin are being used more than others or if users are using the entity page view more than the sidebar plugin

A plugin like the above could be helpful but we'd also want it to be flexible enough to dig into plugin usage (specific pages) and highly engaged users. We'd probably also want to replicate the data from the backstage DB to our data warehouse(this is already possible for us) so we could visualize in our BI tool alongside the rest of our metrics

from community.