microsite: move files from old microsite
Signed-off-by: Johan Haals <johan.haals@gmail.com>
This commit is contained in:
Johan Haals
@@ -1,44 +0,0 @@
|
||||
---
|
||||
title: Announcing Backstage
|
||||
author: Stefan Ålund, Spotify
|
||||
authorURL: http://twitter.com/stalund
|
||||
authorImageURL: https://pbs.twimg.com/profile_images/121166861/6919c047c0d0edaace78c3009b28e917-user-full-200-130.generated_400x400.jpg
|
||||
---
|
||||
|
||||
## What is Backstage?
|
||||
|
||||
Backstage is Spotify's open source platform for building developer portals.
|
||||
|
||||
It’s the first open source infrastructure platform by Spotify that allows you to focus on building your application instead of reinventing the button. With an elegant and unified, yet opinionated UI/UX for all your tooling and infrastructure, Backstage enables engineers to get up and running faster, which ultimately makes their lives easier and more productive.
|
||||
|
||||
|
||||
|
||||
<!--truncate-->
|
||||
|
||||
## As simple as writing a plugin.
|
||||
|
||||
Backstage makes it easy to unify all of your infrastructure tooling, services, and documentation under a single, easy-to-use interface. So your engineers will always know where to find the right tool for the job. And engineers will already know how to use each tool — because everything uses the same, familiar UI.
|
||||
|
||||
The number of open source infrastructure projects and tools [landscape](https://landscape.cncf.io/) is exploding. As the sheer volume of projects increases, companies and their engineers find it increasingly difficult to keep track and adopt all of the tooling fast enough to keep pace. Most of the tools were built by a different individual, team, or company, which means that there is no single UI/UX, and simply getting the tool installed and started can be a painful challenge- let alone wrangling each tool to work with one another within your existing ecosystem. Due to varying qualities and the varying UI/UX of each open source project, we'd like to introduce Backstage as a best-of-breed platform for developers to use... all in service of ensuring a flawless, consistent user experience.
|
||||
|
||||
|
||||
|
||||
## The Spotify story
|
||||
|
||||
A best-in-class developer portal — from a music company? Since the very beginning, Spotify has been known for its agile, autonomous engineering culture. More than music, we’re a tech company that has always put engineers first, empowering our developers with the ability to innovate quickly and at scale. Backstage is the natural result of that focus.
|
||||
|
||||
Since adopting Backstage internally at Spotify, we’ve seen a 55% decrease in onboarding time for our engineers (as measured by time until 10th pull request). Over 280 engineering teams inside Spotify are using Backstage to manage 2,000+ backend services, 300+ websites, 4,000+ data pipelines, and 200+ mobile features.
|
||||
|
||||
## Project roadmap
|
||||
|
||||
We created Backstage about 4 years ago, and today, we’ve decided to share the goodness with the greater engineering community. While our version of Backstage has had the benefit of time to mature and evolve, the first iteration of our open source version is still nascent. I wanted to take a moment to share with you what our vision for Backstage OSS is so that 1. users and our community gain a better understanding of where we’re envisioning the product to go and more importantly, 2. you can provide input and feedback so that together, we can create a better infrastructure experience for developers everywhere.
|
||||
|
||||
We are envisioning three phases of the project and we have already begun work on various aspects of these phases:
|
||||
|
||||
- **Phase 1:** Extensible frontend platform (now) - You will be able to easily create a single consistent UI layer for your internal infrastructure and tools. A set of reusable UX patterns and components help ensure a consistent experience between tools.
|
||||
|
||||
- **Phase 2:** Manage your stuff (next 2-3 months) - Manage anything from microservices to software components to infrastructure and your service catalog. Regardless of whether you want to create a new library, view service deployment status in Kubernetes, or check the test coverage for a website -- Backstage will provide all of those tools - and many more - in a single developer portal.
|
||||
|
||||
- **Phase 3:** Ecosystem (later) - Everyone's infrastructure stack is different. By fostering a vibrant community of contributors we hope to provide an ecosystem of Open Source plugins/integrations that allows you to pick the tools that match your stack.
|
||||
|
||||
Our vision for Backstage is for it to become the trusted standard toolbox (read: UI layer) for the open source infrastructure landscape. Think of it like Kubernetes for developer experience. We realize this is an ambitious goal. We can’t do it alone. If this sounds interesting or you'd like to help us shape our product vision, we'd love to talk. You can email us directly: [backstage-interest@spotify.com](mailto:backstage-interest@spotify.com).
|
||||
@@ -1,88 +0,0 @@
|
||||
---
|
||||
title: What the heck is Backstage anyway?
|
||||
author: Stefan Ålund, Spotify
|
||||
authorURL: http://twitter.com/stalund
|
||||
authorImageURL: https://pbs.twimg.com/profile_images/121166861/6919c047c0d0edaace78c3009b28e917-user-full-200-130.generated_400x400.jpg
|
||||
---
|
||||
|
||||
|
||||
|
||||
Two days ago, we released the open source version of [Backstage](https://backstage.io/), our homegrown developer portal. And we learned a thing or two via the feedback we received. So, I wanted to take this opportunity to further explain what we’re trying to do with Backstage — and more importantly, what we want to give to the greater engineering community beyond Spotify.
|
||||
|
||||
<!--truncate-->
|
||||
|
||||
## What’s the big infrastructure problem?
|
||||
|
||||
As companies grow, their infrastructure systems get messier. Consider a team that wants to deploy something to the cloud. While Spotify has many awesome engineers, not every engineer is well-versed in our chosen cloud-provider tooling. Yet everyone is required to know and understand Terraform, GCP/AWS/Azure CLIs, GitLab CI, Prometheus, Kubernetes, Docker, various monitoring and alerting tools, and much, much more. Once other resources come into play (databases, queueing, etc.), each engineer requires even more tools and domain-specific knowledge (or “disciplines”), from backend to machine learning, to mobile and data.
|
||||
|
||||
## What’s the fix?
|
||||
|
||||
Backstage unifies all your infrastructure tooling, services, and documentation with a single, consistent UI. All of it! Imagine if all your tools — GCP, Bigtable, CI pipelines, TensorFlow Extended, and whatever else is hiding in your stack — all had the same, easy-to-use interface. That’s Backstage. One front end for all your infrastructure.
|
||||
|
||||
|
||||
|
||||
Backstage gives developers a uniform overview of all their resources, regardless of how and where they are running, as well as an easy way to onboard and start using those tools. It also allows the creation of new resources, such as backend services running in Kubernetes, with a few clicks of a button — all without having to leave the same, familiar interface of Backstage.
|
||||
|
||||
## Why did we build it?
|
||||
|
||||
To some observers, it may seem odd that a music company is launching a best-in-class developer portal. But if you [dig deeper](https://backstage.io/background), you’ll find that since the very beginning, Spotify has been known for its agile, autonomous engineering culture. More than music, we’re a tech company that has always put engineers first, empowering our developers with the ability to innovate quickly and at scale. Backstage is the natural result of that focus.
|
||||
|
||||
## What are examples of how Backstage is used at Spotify?
|
||||
|
||||
Our internal installation of Backstage has over 100 different integrations — we call them “plugins”. Since the open-source version currently does not have any end-to-end use cases, it can be challenging to understand what problems Backstage can solve for you. To make things more tangible, let’s have a look at four of the common use-cases:
|
||||
|
||||
1. Creating a new microservice
|
||||
2. Following a pull request from review to production
|
||||
3. Centralised technical documentation
|
||||
4. Review performance of your team’s mobile features
|
||||
|
||||
These are just a few examples. Expect us to continue providing examples of how Backstage is used inside Spotify while we build out more end-2-end use-cases in the open.
|
||||
|
||||
### 1. Creating a new microservice
|
||||
|
||||
Creating any new software component at Spotify, such as a new microservice, is done with a few clicks in Backstage. Developers choose between a number of standard templates — all with best-practices built in.
|
||||
|
||||
|
||||
|
||||
After inputting some metadata about your service, a new repository is created with a “hello world” service that automatically builds and deploys in production on Kubernetes ([GKE](https://cloud.google.com/kubernetes-engine)). Ownership information is automatically captured in our service/software catalog and users can see a list of all the services they own.
|
||||
|
||||
|
||||
|
||||
### 2. Following a pull request from review to production
|
||||
|
||||
As soon as you submit a pull request to Spotify’s GitHub Enterprise, our CI system automatically posts a link to the CI/CD view in Backstage. The view provides you with all the information you need: build progress, test coverage changes, a re-trigger button, etc., so that you don’t have to look for this information across different systems.
|
||||
|
||||
|
||||
|
||||
Our homegrown CI system uses Jenkins under the hood, but Spotify engineers don’t need to know that. They interact directly with GitHub Enterprise and Backstage.
|
||||
|
||||
### 3. Centralised technical documentation
|
||||
|
||||
Spotify uses a [docs-like-code](https://www.youtube.com/watch?v=uFGCaZmA6d4) approach. Engineers write technical documentation in Markdown files that live together with the code. During CI, a beautiful-looking documentation site is created using [MkDocs](https://www.mkdocs.org/), and all sites are rendered centrally in a Backstage plugin.
|
||||
|
||||
|
||||
|
||||
On top of the static documentation we also incorporate additional metadata about the documentation site — such as owner, open issue and related Stack Overflow tags.
|
||||
|
||||
### 4. Review performance of your team’s mobile features
|
||||
|
||||
Our mobile apps are developed by many different teams. The codebase is divided up into different features, each owned and maintained by a separate team. If an app developer on one team wants to understand how their feature is affecting overall app performance, there’s a plugin for that:
|
||||
|
||||
|
||||
_Figures above for illustrative purposes only._
|
||||
|
||||
Developers can also look at crashes, releases, test coverage over time and many more tools in the same location.
|
||||
|
||||
## Why did we make Backstage open source?
|
||||
|
||||
When discussing infrastructure challenges with peer companies, it’s clear that we are not alone in struggling with fragmentation across our developer ecosystem. As companies adopt more open-source tooling, and build more infrastructure internally, the complexity grows. It gets harder for individual engineers to find and use all these distinct tools.
|
||||
|
||||
Similar to how Backstage ties together all of Spotify’s infrastructure, our ambition is to make the open-source version of Backstage the standard UX layer across the broader infrastructure landscape. We decided to release Backstage early so we could collaborate more closely with companies that have a similar problem — and that want to provide a better developer experience to their teams.
|
||||
|
||||
## What’s next?
|
||||
|
||||
We are envisioning [three phases](https://github.com/backstage/backstage/milestones) of the project (so far), and we have already begun work on various aspects of these phases. The best way to track the work and see where you can jump in and help out is:
|
||||
|
||||
https://github.com/backstage/backstage/milestones
|
||||
|
||||
Want to discuss the project or need support? Join us on [Discord](https://discord.gg/backstage-687207715902193673) or reach out on [backstage-interest@spotify.com](mailto:backstage-interest@spotify.com).
|
||||
@@ -1,40 +0,0 @@
|
||||
---
|
||||
title: Introducing Lighthouse for Backstage
|
||||
author: Paul Marbach, Spotify
|
||||
authorURL: http://twitter.com/fastfrwrd
|
||||
authorImageURL: https://pbs.twimg.com/profile_images/1224058798958088192/JPxS8uzR_400x400.jpg
|
||||
---
|
||||
|
||||
|
||||
|
||||
We’re proud to announce that our first internal plugin at Spotify has been open-sourced as part of Backstage. This plugin works with the newly open-sourced [lighthouse-audit-service](https://github.com/spotify/lighthouse-audit-service) to run and track Lighthouse audits for your websites.
|
||||
|
||||
<!--truncate-->
|
||||
|
||||
## What is Lighthouse?
|
||||
|
||||
Google's [Lighthouse](https://developers.google.com/web/tools/lighthouse) auditing tool for websites is a great open-source resource for benchmarking and improving the accessibility, performance, SEO, and best practices of your site.
|
||||
|
||||
At Spotify, we keep track of Lighthouse audit scores over time to look at trends and areas for investment. We particularly look to Lighthouse to give us [accessibility recommendations](https://developers.google.com/web/tools/lighthouse/v3/scoring#a11y); in the next few months, we plan to roll out Lighthouse accessibility category scores as a benchmark metric for all websites at Spotify.
|
||||
|
||||
## Lighthouse, tracked over time
|
||||
|
||||
What makes the plugin unique is that we can track a website's audit performance over time using the main metrics that Lighthouse outputs, rather than simply running reports. The sparklines show, at a glance, how all of your websites are holding up over recent builds.
|
||||
|
||||
|
||||
|
||||
Lighthouse reports can be viewed directly in Backstage, with the ability to travel back and forth through your audit history, so you can quickly diagnose which release caused a performance or SEO regression.
|
||||
|
||||
|
||||
|
||||
Trigger an audit directly from Backstage, or trigger audits programmatically with your new lighthouse-audit-service instance. Schedule them after builds as a sort of smoke test, or trigger them on a schedule (as we do at Spotify) to get a daily snapshot of your website.
|
||||
|
||||
|
||||
|
||||
## Using Lighthouse in Backstage
|
||||
|
||||
To learn how you can enable Lighthouse auditing within Backstage, head over to the [README](https://github.com/backstage/backstage/tree/master/plugins/lighthouse) for the plugin to get started.
|
||||
|
||||
## A personal note
|
||||
|
||||
I want to thank the folks on the Backstage team for approaching me to open-source this plugin. I have found working on Backstage to be a really rewarding and fun time, and I'm so glad that the core team members have put in the effort to make Backstage something that anyone in the industry can use. I can't wait to play with all the plugins the community is going to create. I am hopeful that this plugin can help illustrate just a sliver of what we use Backstage for at Spotify.
|
||||
@@ -1,128 +0,0 @@
|
||||
---
|
||||
title: How to quickly set up Backstage
|
||||
author: Marcus Eide, Spotify
|
||||
authorURL: https://github.com/marcuseide
|
||||
authorImageURL: https://secure.gravatar.com/avatar/20223f1e03673c7c1e6282fbebaf6942
|
||||
---
|
||||
|
||||
We wanted to make getting started with Backstage as easy as possible. Even though Backstage is still in the early phases of its development, we believe it is important for our users to get a feel for what Backstage really is.
|
||||
|
||||
We want users to be able to create their own version of Backstage quickly and easily, so that they can take advantage of all the infrastructure that we’ve built into it — and start exploring.
|
||||
|
||||
In this blog post we’ll look at what a Backstage app is and how to create one using our [CLI](https://www.npmjs.com/package/@backstage/cli).
|
||||
|
||||
<!--truncate-->
|
||||
|
||||
## What is a Backstage app?
|
||||
|
||||
|
||||
|
||||
A Backstage app is a modern monorepo web project that is built using Backstage packages. It includes all the configuration and architecture you need to run Backstage so that you don’t have to worry about setting everything up by yourself.
|
||||
|
||||
More specifically, a Backstage app includes the core packages and APIs that provide base functionality to the app. The actual UX is provided by plugins. As an example, when you first load the `/` page of the app, the content is provided by the `welcome` plugin.
|
||||
|
||||
Plugins are the essential building blocks of Backstage and extend the platform by providing additional features and functionality. Read more about [Backstage plugins](/docs/getting-started) on GitHub.
|
||||
|
||||
## A personalized platform
|
||||
|
||||
When you create a Backstage _app_, you are creating your own installation of Backstage, an application that is built on top of the Backstage _platform_.
|
||||
|
||||
You get to take full advantage of a platform that we at Spotify have been using internally for years. But you also get to make it your own — starting with its name. You can rename the Backstage app anything you want, so that you can call it something that best fits your organization. Be creative!
|
||||
|
||||
## How do I create an app?
|
||||
|
||||
Just run the backstage-cli:
|
||||
|
||||
```bash
|
||||
npx @backstage/create-app
|
||||
```
|
||||
|
||||
Name your app, and we will create everything you need:
|
||||
|
||||
|
||||
|
||||
The only thing you need to do is to start the app:
|
||||
|
||||
```bash
|
||||
cd my-app
|
||||
yarn dev
|
||||
```
|
||||
|
||||
And you are good to go! 👍
|
||||
|
||||
Read the full documentation on how to [create an app](/docs/getting-started/create-an-app) on GitHub.
|
||||
|
||||
## What do I get? (Let's get technical...)
|
||||
|
||||
We’ve been using Backstage internally for years, and we’ve spent a lot of time adding to and tweaking the infrastructure so that it fits our needs. After all that testing and trial and error, we think it will fit your needs, too!
|
||||
|
||||
### 1. Lerna setup to manage multi-packages
|
||||
|
||||
The monorepo and its packages are managed by [Lerna](https://lerna.js.org/). It lets you work with individual packages in a controlled way.
|
||||
|
||||
### 2. Fast builds
|
||||
|
||||
Behind the scenes we use [Rollup](https://rollupjs.org/) to build the modules.
|
||||
|
||||
Each package is built individually. With the `--watch` flag you will be able to detect changes per package and therefore speed up the local development process.
|
||||
|
||||
To further speed things up, we have also included our own caching system to avoid rebuilding unchanged packages.
|
||||
|
||||
Our hope is that there will be thousands of Backstage plugins in the future, so we need a fast and stable build process.
|
||||
|
||||
### 3. Full TypeScript support
|
||||
|
||||
Most of the codebase is written in [TypeScript](https://www.typescriptlang.org/), and we aim for all of the core packages to be in TypeScript in the future.
|
||||
|
||||
All the knobs and handles needed for a stable and functioning TypeScript project are included.
|
||||
|
||||
Take a look at `@backstage/cli/config/tsconfig.json` for more details.
|
||||
|
||||
### 4. Tests and coverage out of the box
|
||||
|
||||
We include testing, linting, and end-to-end tests for your convenience.
|
||||
|
||||
```bash
|
||||
yarn lint:all
|
||||
yarn test:all
|
||||
yarn test:e2e
|
||||
```
|
||||
|
||||
## Extend the app with plugins
|
||||
|
||||
At Spotify, the main factor behind Backstage’s success has been our large and diverse collection of plugins — the result of contributions from various teams over the years. Internally, we have more than a hundred different plugins.
|
||||
|
||||
There are two ways to add plugins to your Backstage app: use a publicly available plugin or create your own.
|
||||
|
||||
### Using a public plugin
|
||||
|
||||
We provide a collection of public Backstage plugins (look for packages with the `plugin-` prefix under the `@backstage` namespace on [npm](https://www.npmjs.com/) that you can start using immediately.
|
||||
|
||||
Install in your app’s package folder (`<root>/packages/app`) with:
|
||||
|
||||
```bash
|
||||
# From your Backstage root directory
|
||||
yarn add --cwd packages/app @backstage/plugin-<plugin-name>
|
||||
```
|
||||
|
||||
After that, you inject the plugin into the application where you want it to be exposed. Please read the documentation for the specific plugin you are installing for more information.
|
||||
|
||||
### Creating an internal plugin
|
||||
|
||||
We also know that each organization has different needs and will create their own plugins for internal purposes. To create an internal plugin, you can use our CLI again.
|
||||
|
||||
In the root of your app directory (`<root>`) run:
|
||||
|
||||
```bash
|
||||
yarn create-plugin
|
||||
```
|
||||
|
||||
This command will create a new plugin in `<root>/plugins/` and register it to your app automatically.
|
||||
|
||||
### Sharing is caring 🤗
|
||||
|
||||
If you are developing a plugin that might be useful for others, consider releasing it publicly. A large, diverse ecosystem of Backstage plugins benefits the whole community
|
||||
|
||||
## Ready to get started?
|
||||
|
||||
Head over to GitHub and check out the [project](https://github.com/backstage/backstage) or download our [CLI](https://www.npmjs.com/package/@backstage/cli). If you have more questions, join us on [Discord](https://discord.gg/backstage-687207715902193673) or [create an issue](https://github.com/backstage/backstage/issues/new/choose).
|
||||
@@ -1,44 +0,0 @@
|
||||
---
|
||||
title: Introducing Tech Radar for Backstage
|
||||
author: Bilawal Hameed, Spotify
|
||||
authorURL: http://twitter.com/bilawalhameed
|
||||
authorImageURL: https://avatars0.githubusercontent.com/bih
|
||||
---
|
||||
|
||||
|
||||
|
||||
Just a few weeks ago, we released our internal plugin for [Lighthouse website audits] as our first open source plugin, so the whole community could use it. Today, we’re excited to add a new plugin to that list — say hello to the [Tech Radar plugin]!
|
||||
|
||||
<!--truncate-->
|
||||
|
||||
## What is Tech Radar?
|
||||
|
||||
The Technology Radar is a concept created by [ThoughtWorks] which allows you to visualize the official guidelines of software languages, processes, infrastructure, and platforms at that particular company. The particular visualization above was created by [Zalando].
|
||||
|
||||
At Spotify, our central committee of technical architects own the Tech Radar with the input of engineers across the company. Anyone can and is encouraged to give recommendations. We segment entries in our Tech Radar by languages, frameworks, processes, and infrastructure, although you should pick whatever works best for your organization. Each entry in the Tech Radar can have one of the following lifecycle values: Use, Trial, Assess, and Hold.
|
||||
|
||||
We also assign clear definitions for each lifecycle:
|
||||
|
||||
- **Use:** This technology is recommended for use by the majority of teams with a specific use case.
|
||||
- **Trial:** This technology has been evaluated for specific use cases and has showed clear benefits. Some teams adopt it in production, although it should be limited to low-impact projects as it might incur a higher risk.
|
||||
- **Assess:** This technology has the potential to be beneficial for the company. Some teams are evaluating it and using it in experimental projects. Using it in production comes with a high cost and risk due to lack of in-house knowledge, maintenance, and support.
|
||||
- **Hold:** We don’t want to further invest in this technology or we evaluated it and we don’t see it as beneficial for the company. Teams should not use it in new projects and should plan on migrating to a supported alternative if they use it for historical reasons. For broadly adopted technologies, the Radar should refer to a migration path to a supported alternative.
|
||||
|
||||
Since rolling out the Tech Radar, it has become the source of truth when creating, maintaining, or evolving our software ecosystem. Spotify has dozens of entries in our Radar and it can scale quite well whilst being easy for our engineers and engineering managers to consume.
|
||||
|
||||
## Using the Tech Radar in Backstage
|
||||
|
||||
To learn about how you can bring the Tech Radar to your Backstage installation, check out [the plugin README on GitHub][tech radar plugin].
|
||||
|
||||
## A personal note
|
||||
|
||||
I want to thank both the Backstage team and Spotify. Firstly, I’ve been working with our internal version of Backstage for over a year, and the developer experience since open sourcing has been even more of a joy to work with. Secondly, the 10% hack time that Spotify generously provides to all engineers enabled me to open source the Tech Radar plugin.
|
||||
|
||||
Since open sourcing it, the community has shown great interest in yet another powerful use case of Backstage. There was also an enthusiastic open source contributor who volunteered to migrate the plugin to TypeScript and React Hooks [in just 29 minutes](https://github.com/backstage/backstage/issues/661) of opening the issue!
|
||||
|
||||
I can’t wait to see how others benefit from the Tech Radar in their organizations!
|
||||
|
||||
[lighthouse website audits]: https://backstage.io/blog/2020/04/06/lighthouse-plugin
|
||||
[tech radar plugin]: https://github.com/backstage/backstage/tree/master/plugins/tech-radar
|
||||
[thoughtworks]: https://www.thoughtworks.com/radar
|
||||
[zalando]: https://opensource.zalando.com/tech-radar/
|
||||
@@ -1,33 +0,0 @@
|
||||
---
|
||||
title: Weaveworks’ COVID-19 app uses Backstage UI
|
||||
author: Jeff Feng, Spotify
|
||||
authorURL: https://github.com/fengypants
|
||||
authorImageURL: https://avatars2.githubusercontent.com/u/46946747
|
||||
---
|
||||
|
||||
|
||||
|
||||
One of the great things about the open source community is once you put your work out there, you really never know where it might end up. That’s certainly the case here.
|
||||
|
||||
<!--truncate-->
|
||||
|
||||
When Weaveworks decided to build an X-ray diagnostics app to help fight COVID-19, they pulled together a lot of different open source resources — from projects big and small, built by both familiar tech partners and some brand new ones, too.
|
||||
|
||||
At the heart of their app — called [fk-covid][] — there’s a TensorFlow-based deep neural network that was developed by researchers on the DarwinAI team and others in the COVID R&D community. To package that network up for doctors and software developers to use, the app combines open source tools from Google, AWS, Azure, MinIO, the CNCF, and Weaveworks’ own Firekube bundle for Kubernetes.
|
||||
|
||||
And the user interface for all of this? Weaveworks built a custom plugin using the Backstage framework.
|
||||
|
||||
“We chose Backstage as a modern UI toolkit that we knew would work with Kubernetes apps,” said Alexis Richardson, CEO of Weaveworks. “We were also experimenting with Backstage for microservices and ML, so it was natural to try it here.”
|
||||
|
||||
Chanwit Kaewkasi, Weaveworks’ DX Engineer and a tech lead on the project, said, “Backstage offers very advanced plugin architecture which allows us to only focus on the plugin we're developing. Other things are taken care of by the framework.”
|
||||
|
||||
In other words, here’s Backstage doing what Backstage does best: unifying a bunch of technologies with a cohesive frontend, so that the whole thing is easier to build and easier to use.
|
||||
|
||||
Joining the fight against a global pandemic was not something the Backstage team at Spotify ever envisioned when we released our homegrown developer portal to the world back in March. But it’s a testament to the ingenuity (and serendipity) of the open source community that Backstage could be enlisted for such an unexpected use case.
|
||||
|
||||
We’re proud to see Backstage adopted as the UX layer for this meaningful cause. And we can’t wait to see what the open source community will build next.
|
||||
|
||||
To learn more about what fk-covid does, and how it works, jump on over to [the Weaveworks blog][] to hear it straight from the team that built it. It’s a great example of the possibilities that come from being a part of the open source community.
|
||||
|
||||
[fk-covid]: https://github.com/weaveworks/fk-covid
|
||||
[the weaveworks blog]: https://www.weave.works/blog/firekube-covid-ml
|
||||
@@ -1,55 +0,0 @@
|
||||
---
|
||||
# prettier-ignore
|
||||
title: "Starting Phase 2: The Service Catalog"
|
||||
author: Stefan Ålund, Spotify
|
||||
authorURL: http://twitter.com/stalund
|
||||
authorImageURL: https://pbs.twimg.com/profile_images/121166861/6919c047c0d0edaace78c3009b28e917-user-full-200-130.generated_400x400.jpg
|
||||
---
|
||||
|
||||
**TL;DR** Thanks to the help from the Backstage community, we’ve made excellent progress and are now moving into Phase 2 of Backstage — building out a Service Catalog and the surrounding systems that will help unify the tools you use to manage your software.
|
||||
|
||||
We released the open source version of Backstage a little less than two months ago, and have been thrilled to see so many people jumping in and contributing to the project in its early stages. We’re excited to see what the community can build together as we progress through [each phase of Backstage](https://github.com/backstage/backstage#project-roadmap).
|
||||
|
||||
|
||||
|
||||
<!--truncate-->
|
||||
|
||||
## Progress so far
|
||||
|
||||
Phase 1 was all about building an extensible frontend platform, enabling teams to start creating a single, consistent UI layer for your internal infrastructure and tools in the form of [plugins](https://github.com/backstage/backstage/labels/plugin). In fact, thanks to our amazing (30+) [contributors](https://github.com/backstage/backstage/graphs/contributors), we were able to complete most of Phase 1 earlier than expected. 🎉
|
||||
|
||||
Today, we are happy to announce that we are shifting our focus to Phase 2!
|
||||
|
||||
## So what is Phase 2?
|
||||
|
||||
> _The core of building Platforms rests in versatile entity management. Entities represent the nouns or the "truths" of our world._
|
||||
|
||||
Quote from [Platform Nuts & Bolts: Extendable Data Models](https://www.kislayverma.com/post/platform-nuts-bolts-extendable-data-models)
|
||||
|
||||
Entities, or what we refer to as “components” in Backstage, represent all software, including services, websites, libraries, data pipelines, and so forth. The focus of Phase 2 will be on adding an entity model in Backstage that makes it easy for engineers to create and manage the software components they own.
|
||||
|
||||
With the ability to create a plethora of components in Backstage, how does one keep track of all the software in the ecosystem? Therein lies the highlight feature of Phase 2: the [Service Catalog](https://github.com/backstage/backstage/milestone/4). The service catalog — or software catalog — is a centralized system that keeps track of ownership and metadata about all software in your ecosystem. The catalog is built around the concept of [metadata yaml files](/docs/architecture-decisions/adrs-adr002) stored together with the code, which are then harvested and visualized in Backstage.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
With a single catalog, Backstage makes it easy for a team to manage ten services — and makes it possible for your company to manage thousands of them. Because the system is practically self-organizing, it requires hardly any oversight from a governing or centralized team. Developers can get a uniform overview of all their software and related resources (such as server utilisation, data pipelines, pull request status), regardless of how and where they are running, as well as an easy way to onboard and manage those resources.
|
||||
|
||||
On top of that, we have found that the service catalog is a great way to organise the infrastructure tools you use to manage the software as well. This is how Backstage creates one developer portal for all your tools. Rather than asking teams to jump between different infrastructure UI’s (and incurring additional cognitive overhead each time they make a context switch), most of these tools can be organised around the entities in the catalog:
|
||||
|
||||
|
||||
|
||||
More concretely, having this structure in place will allow plugins such as [CircleCI](https://github.com/backstage/backstage/tree/master/plugins/circleci) to show only the builds for the specific service you are viewing, or a [Spinnaker](https://github.com/backstage/backstage/issues/631) plugin to show running deployments, or an Open API plugin to [show documentation](https://github.com/backstage/backstage/issues/627) for endpoints exposed by the service, or the [Lighthouse](https://github.com/backstage/backstage/tree/master/plugins/lighthouse) plugin to show audit reports for your website. You get the point.
|
||||
|
||||
## Timeline
|
||||
|
||||
Our estimated timeline has us delivering these pieces in increments leading up to June 22. But with the support of the community we wouldn’t be surprised if things land earlier than that. 🙏
|
||||
|
||||
If you are interested in joining us, check out our [Milestones](https://github.com/backstage/backstage/milestones) and connected Issues.
|
||||
|
||||
## Long-term vision
|
||||
|
||||
Our vision for Backstage is for it to become the trusted, standard toolbox (read: UX layer) for the open source infrastructure landscape. Imagine a future where regardless of what infrastructure you use inside your company, there is an open source plugin available that you can pick up and add to your deployment of Backstage.
|
||||
|
||||
Spotify will continue to release more of our [internal](https://backstage.io/blog/2020/04/06/lighthouse-plugin) [plugins](https://backstage.io/blog/2020/05/14/tech-radar-plugin), but participation from developers and companies can help us build a healthy community. We are excited to see how Backstage has helped many of you, and look forward to seeing all the new plugins you and your teams will build!
|
||||
@@ -1,54 +0,0 @@
|
||||
---
|
||||
title: Backstage Service Catalog released in alpha
|
||||
author: Stefan Ålund, Spotify
|
||||
authorURL: http://twitter.com/stalund
|
||||
image: https://backstage.io/blog/assets/6/header.png
|
||||
---
|
||||
|
||||
**TL;DR** Today we are announcing the availability of the Backstage Service Catalog in alpha. This has been the community’s most requested feature. Even if the catalog is not ready for production yet, we think this release already demonstrates how Backstage can provide value for your company right out of the box. With your early input and feedback, we hope to create a stronger generally available product.
|
||||
|
||||
|
||||
|
||||
<!--truncate-->
|
||||
|
||||
## You asked, we listened
|
||||
|
||||
When we [released](https://backstage.io/blog/2020/03/16/announcing-backstage) Backstage as an open source project back in March, it didn’t have all of the features that our internal version of Backstage has today. One of the main reasons we pushed to release it, despite it being in such a nascent stage, was so that we could start building the next phase of Backstage around the community’s needs. We’ve had hours of conversations with so many of you — thank you to everyone who has jumped on a video call, attended one of our working sessions, or watched our [demo videos](https://backstage.io/demos) and provided feedback via [Discord](https://discord.com/invite/MUpMjP2).
|
||||
|
||||
Today, we wanted to share what we’ve learned from talking with many of you at companies that have shown interest in adopting Backstage. Here it is in short:
|
||||
|
||||
- The problem of scaling autonomous engineering organisations without creating too much complexity is not a unique problem to Spotify.
|
||||
- The "extensible frontend platform" that we focused on in the first phase of the project is not the only thing you are looking for.
|
||||
|
||||
With these insights we decided to re-focus our efforts towards the most requested feature: the Backstage Service Catalog.
|
||||
|
||||
## What is the service catalog?
|
||||
|
||||
The Backstage Service Catalog — actually, a software catalog, since it includes more than just services — is a centralized system that keeps track of ownership and metadata for all the software in your ecosystem (services, websites, libraries, data pipelines, etc). The catalog is built around the concept of [metadata yaml files](/docs/architecture-decisions/adrs-adr002) stored together with the code, which are then harvested and visualized in Backstage.
|
||||
|
||||
This was our pitch for the virtues of a service catalog when we first [announced](https://backstage.io/blog/2020/05/22/phase-2-service-catalog) it as part of Phase 2:
|
||||
|
||||
> With a single catalog, Backstage makes it easy for a team to manage ten services — and makes it possible for your company to manage thousands of them. Because the system is practically self-organizing, it requires hardly any oversight from a governing or centralized team. Developers can get a uniform overview of all their software and related resources (such as server utilisation, data pipelines, pull request status), regardless of how and where they are running, as well as an easy way to onboard and manage those resources.
|
||||
|
||||
> On top of that, we have found that the service catalog is a great way to organise the infrastructure tools you use to manage the software as well. This is how Backstage creates one developer portal for all your tools. Rather than asking teams to jump between different infrastructure UI’s (and incurring additional cognitive overhead each time they make a context switch), most of these tools can be organised around the entities in the catalog:
|
||||
|
||||
|
||||
|
||||
You’ll be able to see many of these virtues in action with this alpha release — though, with some caveats, of course, since it is, after all, an alpha.
|
||||
|
||||
## What does alpha mean?
|
||||
|
||||
Alpha is our shorthand for "we don’t yet think Backstage is ready for production, but we’d love for you to test it and provide us with feedback". However, you should be able to try out the functionality of the service catalog:
|
||||
|
||||
1. Register software components ([examples](https://github.com/backstage/backstage/tree/master/packages/catalog-model/examples))
|
||||
2. See all components represented in the catalog
|
||||
3. Search across all components
|
||||
4. Get an overview of the metadata of the components
|
||||
5. Click through and get more information about a specific component (service, website, etc)
|
||||
6. See example tooling (plugins) that helps you manage the component
|
||||
|
||||
As with most alpha releases, you should expect things to change quite a lot until we reach the beta stage (we’re targeting the end of summer). There are obviously many things missing as well, but we wanted to start collecting feedback early and make it easier to see the end-to-end flow.
|
||||
|
||||
If you have feedback or questions, please open a [GitHub issue](https://github.com/backstage/backstage/issues), ping us on [Discord chat](https://discord.gg/backstage-687207715902193673) or send us an email at [backstage-interest@spotify.com](mailto:backstage-interest@spotify.com) 🙏
|
||||
|
||||
To get regular product updates and news about the Backstage community, sign up for the [Backstage newsletter](https://info.backstage.spotify.com/newsletter_subscribe).
|
||||
@@ -1,46 +0,0 @@
|
||||
---
|
||||
title: How to enable authentication in Backstage using Passport
|
||||
author: Lee Mills, Spotify
|
||||
authorURL: https://github.com/leemills83
|
||||
authorImageURL: https://avatars1.githubusercontent.com/u/1236238?s=460&v=4
|
||||
---
|
||||
|
||||
|
||||
|
||||
Getting authentication right is important. It helps keep your platform safe, it’s one of the first things users will interact with, and there are many different authentication providers to support. To this end, we chose to use [Passport](http://www.passportjs.org/) to provide an easy-to-use, out-of-the-box experience that can be extended to your own, pre-existing authentication providers (known as strategies). The Auth APIs in Backstage serve two purposes: identify the user and provide a way for plugins to request access to third-party services on behalf of the user. We’ve already implemented Google and GitHub authentication to provide examples and to get you started.
|
||||
|
||||
<!--truncate-->
|
||||
|
||||
## What is Passport?
|
||||
|
||||
[Passport](http://www.passportjs.org/) is Express-compatible authentication middleware for Node.js that provides access to over 500 authentication providers, covering everything from Google, Facebook, and Twitter to generic OAuth, SAML, and local. Check out all of the currently available [strategies listed on the Passport site](http://www.passportjs.org/).
|
||||
|
||||
Passport has allowed us to leverage an existing open-source authentication framework that will, in turn, give users the freedom to add and extend alternative authentication strategies to their instance of Backstage.
|
||||
|
||||
## Using authentication in Backstage
|
||||
|
||||
|
||||
|
||||
First, check out the provided Google and GitHub implementations! [Spin up a local copy of Backstage](https://backstage.io/blog/2020/04/30/how-to-quickly-set-up-backstage) along with our example-backend. You can find more documentation on setting up the example backend [here](https://github.com/backstage/backstage/tree/master/packages/backend), but be sure to include the relevant client IDs and secrets when running `yarn start`:
|
||||
|
||||
```
|
||||
AUTH_GOOGLE_CLIENT_ID=x AUTH_GOOGLE_CLIENT_SECRET=x AUTH_GITHUB_CLIENT_ID=x AUTH_GITHUB_CLIENT_SECRET=x SENTRY_TOKEN=x LOG_LEVEL=debug yarn start
|
||||
```
|
||||
|
||||
You can find the implementation for these strategies along with a lightweight proof-of-concept implementation for SAML authentication at `<root>/plugins/auth-backend/src/providers`.
|
||||
|
||||
## Ready to get started by adding your chosen provider and implementation?
|
||||
|
||||
Getting started is really straightforward, and can be broadly broken down into five steps:
|
||||
|
||||
1. Install the [Passport-based provider package that best suits your needs](http://www.passportjs.org/).
|
||||
2. Add a new provider to `plugins/auth-backend/src/providers/`
|
||||
3. Implement the provider, extending the suitable framework, if needed.
|
||||
4. Add the provider to the backend.
|
||||
5. Add a frontend Auth Utility API.
|
||||
|
||||
For full details, take a look at our [“Adding authentication providers” documentation](/docs/auth/add-auth-provider) and at the [excellent documentation](http://www.passportjs.org/docs/) provided by Passport.
|
||||
|
||||
## Interested in contributing to the next steps for authentication?
|
||||
|
||||
We’ve already seen both GitLab and Okta contributions from the community — and we’re thinking about a few more providers we’d like to add to Backstage, too. You can find those, and other authentication-related issues, in our repository by filtering with the [auth label](https://github.com/backstage/backstage/issues?q=is%3Aissue+is%3Aopen+label%3Aauth).
|
||||
@@ -1,78 +0,0 @@
|
||||
---
|
||||
title: Announcing Backstage Software Templates
|
||||
author: Stefan Ålund, Spotify
|
||||
authorURL: https://twitter.com/stalund
|
||||
---
|
||||
|
||||
**TL;DR** Today we are announcing a new Backstage feature: Software Templates. Simplify setup, standardize tooling, and deploy with the click of a button. Using automated templates, your engineers can spin up a new microservice, website, or other software component with your organization’s best practices built-in, right from the start.
|
||||
|
||||
<video width="100%" height="100%" controls>
|
||||
<source src="/blog/assets/2020-08-05/feature.mp4" type="video/mp4" />
|
||||
</video>
|
||||
|
||||
<!--truncate-->
|
||||
|
||||
## Balancing autonomy and standardization
|
||||
|
||||
At Spotify, we’ve always believed in the speed and ingenuity that comes from having autonomous development teams. But as we learned firsthand, the faster you grow, the more fragmented and complex your software ecosystem becomes. And then everything slows down again.
|
||||
|
||||
By centralizing services and standardizing your tooling, Backstage streamlines your development environment from end to end. Instead of restricting autonomy, standardization frees your engineers from infrastructure complexity. So you can return to building and scaling, quickly and safely.
|
||||
|
||||
Today we are releasing one of the key features that helps balance autonomy and standardization: templates for creating software.
|
||||
|
||||
## Backstage Software Templates: Push-button deployment
|
||||
|
||||
Backstage Software Templates automate and standardize the process of creating software components. To show you how they work, we created four sample templates to get you started — just configure them to fit your tooling and off you go:
|
||||
|
||||
- **Create React App Template** — create a new CRA website project
|
||||
- **Golang Microservice** — create a Golang repo with this template built by members of the Go community
|
||||
- **React SSR Template** — create a website powered with Next.js
|
||||
- **Spring Boot GRPC** — create a simple microservice using gRPC and Spring Boot Java
|
||||
|
||||
### The getting started guide gets automated
|
||||
|
||||
Since the templates can be customized to integrate with your existing infrastructure, it’s easy to start a new project without ever having to leave Backstage. Let’s say you’re building a microservice. With three clicks in Backstage, you’ll have a new Spring Boot project with your repo automatically configured on GitHub and your CI already running the first build.
|
||||
|
||||
### Golden Paths pave the way
|
||||
|
||||
You can customize Backstage Software Templates to fit your organization’s standards. Using Go instead of Java? CircleCI instead of Jenkins? Serverless instead of Kubernetes? GCP instead of AWS? [Make your own recipes for any software component](https://backstage.io/docs/features/software-templates/adding-templates) and your best practices will be baked right in.
|
||||
|
||||
## Getting started
|
||||
|
||||
The sample Software Templates are available under `/create`. If you're setting up Backstage for the first time, follow [Getting Started with Backstage](https://backstage.io/docs/getting-started/) and go to `http://localhost:3000/create`.
|
||||
|
||||
|
||||
|
||||
### Step 1: Choose a template
|
||||
|
||||
When you select a template that you want to create, you can ask for different input variables. These are then passed to the templater internally.
|
||||
|
||||
|
||||
|
||||
After filling in these variables, additional fields will appear so Backstage can be used. You’ll specify the owner, which is a `user` in the Backstage system, and the `Location`, which must be a GitHub organization and a non-existing GitHub repository name, formatted as `organization/reponame`.
|
||||
|
||||
### Step 2: Run!
|
||||
|
||||
Once you've entered values and confirmed, you'll then get a modal with live progress of what is currently happening with the creation of your template.
|
||||
|
||||
|
||||
|
||||
It shouldn't take too long before you see a success screen. At this point, a piece of “Hello World” software has been created in your repo, and the CI automatically picks it up and starts building the code.
|
||||
|
||||
Your engineers don’t have to bother with setting up underlying infrastructure, it’s all built into the template. They can start focusing on delivering business value.
|
||||
|
||||
### View new components in the Service Catalog
|
||||
|
||||
New components, of course, get added automatically to the Backstage Service Catalog. After creation, you'll see the `View in Catalog` button, which will take you to the registered component in the catalog:
|
||||
|
||||
|
||||
|
||||
## Define your standards
|
||||
|
||||
Backstage ships with four example templates, but since these are likely not the (only) ones you want to promote inside your company, the next step is to add [your own templates](https://backstage.io/docs/features/software-templates/). Using Backstage’s Software Templates feature, it’s easy to help your engineers get started building software with your organization’s best practices built-in.
|
||||
|
||||
We have learned that one of the keys to getting these standards adopted is to keep an open process. Templates are code. By making it clear to your engineers that you are open to pull requests, and that teams with different needs can add their own templates, you are on the path of striking a good balance between autonomy and standardization.
|
||||
|
||||
If you have feedback or questions, please open a [GitHub issue](https://github.com/backstage/backstage/issues), ping us on [Discord chat](https://discord.gg/backstage-687207715902193673) or send us an email at [backstage-interest@spotify.com](mailto:backstage-interest@spotify.com) 🙏
|
||||
|
||||
To get regular product updates and news about the Backstage community, sign up for the [Backstage newsletter](https://info.backstage.spotify.com/newsletter_subscribe).
|
||||
@@ -1,121 +0,0 @@
|
||||
---
|
||||
# prettier-ignore
|
||||
title: "Announcing TechDocs: Spotify’s docs-like-code plugin for Backstage"
|
||||
author: Gary Niemen, Spotify
|
||||
authorURL: https://github.com/garyniemen
|
||||
---
|
||||
|
||||
Since we [open sourced Backstage](https://backstage.io/blog/2020/03/16/announcing-backstage), one of the most requested features has been for a technical documentation plugin. Well, good news. The first open source version of TechDocs is here. Now let’s start collaborating and making it better, together.
|
||||
|
||||
<iframe width="780" height="440" src="https://www.youtube.com/embed/mOLCgdPw1iA" frameBorder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowFullScreen>
|
||||
</iframe>
|
||||
|
||||
<!--truncate-->
|
||||
|
||||
Internally, we call it TechDocs. It’s the most used plugin at Spotify by far — accounting for about 20% of our Backstage traffic (even though it is just one of 130+ plugins). Its popularity is evidence of something simple: We made documentation so easy to create, find, and use — people actually use it.
|
||||
|
||||
We are quite sure the main reason for the success of TechDocs is our docs-like-code approach — engineers write their technical documentation in Markdown files that live together with the code. During CI, a documentation site is created using MkDocs, and all sites are rendered centrally in a Backstage plugin. On top of the static documentation, we incorporate additional metadata about the documentation site — such as owner, open GitHub Issues, Slack support channel, and Stack Overflow Enterprise tags.
|
||||
|
||||
|
||||
|
||||
But this is just one way to do it. Today we’re most excited for what the open version of TechDocs can become.
|
||||
|
||||
## Okay, let’s start collaborating
|
||||
|
||||
If you go to [GitHub](https://github.com/backstage/backstage/tree/master/plugins) now, you’ll find everything you need to start collaborating with us to build out the docs-like-code Backstage plugin — we’ll call it TechDocs in the open as well.
|
||||
|
||||
You’ll find the code in [techdocs](https://github.com/backstage/backstage/tree/master/plugins/techdocs) (frontend) and [techdocs-backend](https://github.com/backstage/backstage/tree/master/plugins/techdocs-backend). (There are also two separate packages [techdocs-cli](https://github.com/backstage/techdocs-cli) and [techdocs-container](https://github.com/backstage/techdocs-container).)
|
||||
|
||||
You’ll find issues to work on in the [issues queue](https://github.com/backstage/backstage/issues?q=is%3Aissue+is%3Aopen+label%3A%22docs-like-code%22+label%3A%22help+wanted%22), typically starting with TechDocs: and labeled with docs-like-code, some labeled good first issue. Feel free to add your own issues, of course.
|
||||
|
||||
|
||||
|
||||
What we have on GitHub so far is a first iteration of TechDocs that you can use end-to-end — in other words, from docs written in Markdown in GitHub to a published site on Backstage.
|
||||
|
||||
More specifically, with this first iteration, you can:
|
||||
|
||||
- Run TechDocs locally and read documentation.
|
||||
- Configure your entity (e.g. service, website) so that Backstage builds your documentation and serves it in TechDocs. Documentation is displayed on the Docs tab in the Service Catalog and on its own page.
|
||||
- Get documentation set up for free in your project when you create a new component out of one of the non-experimental templates (labeled with recommended). If you are looking for a standalone documentation project, use the docs-template.
|
||||
- Choose your own storage solution for the documentation.
|
||||
- Define your own API to interface with your documentation solution.
|
||||
|
||||
For a full overview, including getting started instructions, check out our [TechDocs Documentation](https://backstage.io/docs/features/techdocs/).
|
||||
|
||||
But before you go there, let me tell you a bit about the TechDocs story — and why we believe TechDocs is such a powerful yet simple solution for great documentation.
|
||||
|
||||
## The TechDocs story
|
||||
|
||||
Here is the TechDocs story. It’s not an uncommon one (we have learned from many other companies).
|
||||
|
||||
About a year and a half ago, we conducted a company-wide productivity survey. The third largest problem according to all our engineers? Not being able to find the technical information they needed to do their work. And it’s not surprising. There was no standard way to produce and consume technical documentation, so teams were going their own way — using Confluence, Google Docs, README files, custom built websites, GitHub Pages, and so on and on. And those searching for information were left to hunt for it in all those different places until they found what they were looking for (if they ever did). Worse, if you did happen to find the documentation that you needed, there was no way to know whether the information was up-to-date or correct. In other words, there was no way to know whether you could trust what you found. We did have technical writers at the company, but they were mostly scattered across the company solving documentation problems within their own particular domain.
|
||||
|
||||
So this is the fertile soil on which TechDocs was built.
|
||||
|
||||
After a Hack Week implementation attracted interest from high up in the company, we formed a cross-functional team made up of technical writers and engineers with the mission to solve internal technical documentation at Spotify. And we started to build TechDocs. We went for a docs-like-code approach, fiercely optimizing for engineers and engineering workflows. We also went for an opinionated approach, telling everybody: This is the standard way to do technical documentation at Spotify. The sense was that engineers appreciated a documentation solution that was in line with their workflow and, after all the frustration of multiple tools, were relieved to be told “this is the way to do it”.
|
||||
|
||||
For more information about this journey, take a look at my 20-minute talk from DevRelCon London from last December: [The Hero’s Journey: How we are solving internal technical documentation at Spotify](https://www.linkedin.com/posts/garyniemen_how-we-are-solving-internal-technical-documentation-activity-6646078605594030080-4L31).
|
||||
|
||||
## Key problem areas that we are solving
|
||||
|
||||
We have come a long way, fast — both in our implementation and in our thinking. Here are some of the key problem areas that we are addressing. Note that they are in various stages of implementation, and we won’t be able to release everything within our minimum plugin. In fact, see this as an appetite taster. What we hope is that we can build together.
|
||||
|
||||
### Stuck to unstuck
|
||||
|
||||
Very early on, we decided that the main problem we were trying to solve was to help engineers (when using technical documentation) go from stuck to unstuck, and fast. This became our guiding principle. Is what we are building helping engineers get unstuck faster? From this, it follows that we need to promote quality documentation on the one hand, and provide a high level of discoverability on the other. One without the other is not going to cut it.
|
||||
|
||||
### Feedback loops
|
||||
|
||||
What we want to build is a thriving community of technical documentation creators, contributors, and readers. We want this because, we believe, this is the way to drive up the quality of the documentation. More readers, more feedback, more doc updates. And driving up the quality of the corpus of technical documentation leads to trust which in turn leads to more engagement and, hence, more of a thriving community.
|
||||
|
||||
To get this working, we recognised that we need to remove ‘friction from the system’ — we need to build in efficient feedback loops. For example, help engineers get their doc site up by providing documentation improvement hints and build information as close as possible to where they are already working. And for readers, make it easy to give feedback. And then for doc site owners, ensure that they are notified when there is feedback and incentivised to make the fix.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Trust
|
||||
|
||||
How do I know whether to trust this piece of documentation? This is a question we want to be able to answer for those using technical documentation in Backstage. It’s not an easy nut to crack. It is almost, one could say, the hard problem of technical documentation. For example, some might say ‘last updated’ is a key factor. But what about stable, good quality documentation that has no need to be updated? What about page views? Yes, this is a good sign that the documentation is being found and viewed, but it doesn’t say anything about whether the documentation can be trusted. How about a button: Did this documentation help? This is good, but will people use it? Will we get enough data to show trust? We have lofty ambitions of one day providing a trust score on the doc site informed by a super-intelligent algorithm. But we are not there yet. For now, we have landed on surfacing when the documentation was last updated, top five contributors, the support channel, owning team, and number of open GitHub Issues. But going forward we are definitely up for solving the hard problem. We think there’s much more work to be done here and look forward to seeing ideas from the community.
|
||||
|
||||
### Discoverability and search
|
||||
|
||||
How to find stuff? That is another big question. As mentioned above, it’s all well and good having quality documentation, but it’s no use whatsoever if you can’t find it. If you know what you are looking for, then you can use a search engine. If you don’t know what you are looking for, then you are going to need more — like a well designed information architecture, a user friendly browse experience, and even intelligent suggestions based on your role and what you have searched for previously.
|
||||
|
||||
In this problem area, we made use of Elasticsearch, the open source search engine that was already being used in Backstage, to implement documentation search across all documentation sites and per documentation site. In terms of discoverability, we implemented a documentation home page in Backstage that surfaces Spotify’s most important documents and uses metrics to list the company’s most used doc sites as well as the documentation equivalent of a “your daily mix” playlist.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
There is much more to do in the area of discoverability and search.
|
||||
|
||||
### Use case variations
|
||||
|
||||
The standard use case for TechDocs is: One component in Backstage equals one GitHub repository, equals one doc site. This use case comes in two flavours: the repository is a code repository with docs or a docs-only repository. Then, to meet the needs of one large part of the Spotify engineering organisation that uses monorepos (multi-component repositories), we added a third use case. We built an MkDocs plugin that enabled doc site creators to include documentation from doc folders in other parts of the repository. So this use case is: One main component in Backstage equals a monorepo with distributed documentation, equals one doc site.
|
||||
|
||||
These three use cases satisfy most of the needs, but we have had plenty of requests for additional use cases, for example, the ability to create multiple doc sites from a multi-component repository and the ability to create one doc site from documentation in multiple repositories.
|
||||
|
||||
### Metrics
|
||||
|
||||
There are many good arguments for standardizing the way that technical documentation is produced and consumed. One of them is metrics. If we have one way of producing technical documentation (in our case, GitHub Enterprise) and one place where it shows up (in our case, Backstage), we are in a strong position to build up metrics that help all the various stakeholders — for example, us building TechDocs, teams creating documentation sites, and engineers trying to get unstuck. Just imagine how much harder this would be if technical documentation was produced and consumed in a plethora of places, such as Confluence, Google Docs, README files, custom web sites, and GitHub Pages.
|
||||
|
||||
One thing we have recently completed is a Manage page in Backstage for doc site owners. Here teams can see all the documentation that they own, the number of GitHub Issues per doc site or page, and last updated. We have also built a large dashboard using the open source analytics software Redash to inform our own product development process.
|
||||
|
||||
|
||||
|
||||
Again, there is a lot more that can be done in the area of metrics. Did I mention the trust score?
|
||||
|
||||
### Code-like-docs
|
||||
|
||||
Code-like-docs, what? Okay, it’s just my little play on words. This is what I mean. One request that we keep getting is to be able to have code in the documentation fetched from and in sync with code in GitHub. In this way, you can avoid code in the documentation going stale. MkDocs does have an extension for this — but it has some limitations. For example, the code has to be in the /docs folder with the Markdown files. We are working on developing a wider and more flexible solution.
|
||||
|
||||
### Golden Paths
|
||||
|
||||
At Spotify, we have the concept of [Golden Paths](https://engineering.atspotify.com/2020/08/17/how-we-use-golden-paths-to-solve-fragmentation-in-our-software-ecosystem/) — one for each engineering discipline. My favourite definition of Golden Path is that it is the “opinionated and supported path”. Each Golden Path has an accompanying Golden Path tutorial that walks you through the opinionated and supported path.
|
||||
|
||||
The Golden Path tutorials are Spotify’s most used and important documents and have shown themselves to be the most challenging to manage within a docs-like-code environment. One reason for this is that they are long, divided into many parts, and ownership is typically spread among many different teams. We have had to make use of GitHub codeowners to handle ownership and had to create datasets and data pipelines to be able to attach GitHub Issues to the specific parts or files that a team owns. Another challenge of the Golden Path tutorials is that parts are often dependent on other parts. We are just starting to look into how we can solve these dependency challenges in order to remove friction for engineers writing tutorial documentation.
|
||||
|
||||
---
|
||||
|
||||
So that’s it for now. As you can see, we have come a long way AND there is much more to do. We are looking forward to continuing our docs-like-code journey out in the open with new, enthusiastic technical documentation friends.
|
||||
@@ -1,21 +0,0 @@
|
||||
---
|
||||
title: Backstage has been accepted into the CNCF Sandbox
|
||||
author: Stefan Ålund, Spotify
|
||||
authorURL: https://twitter.com/stalund
|
||||
---
|
||||
|
||||
**TL;DR** The Cloud Native Computing Foundation (CNCF) announced that Backstage can begin incubating as an early stage project in the [CNCF Sandbox](https://www.cncf.io/sandbox-projects/). Released open source in March, the platform is built around an advanced service catalog and is designed to streamline software development from end to end.
|
||||
|
||||
|
||||
|
||||
<!--truncate-->
|
||||
|
||||
Backstage garnered quite a bit of interest from developers and organizations when it was first announced, and community interest continues to grow as plugins and new features are added with the open source community. We released the open source version of Backstage ‘early’. That was intentional. Because even though we’ve been using Backstage internally for years, we wanted the open source version to be developed with input and contributions from the community. And that’s exactly the product that’s going into the [CNCF Sandbox](https://www.cncf.io/sandbox-projects/) today.
|
||||
|
||||
Backstage’s ability to simplify tooling and standardize engineering practices has attracted interest from other major tech companies, as well as airlines, auto manufacturers, investment firms, and global retailers. We know that Backstage solves a problem — infrastructure complexity — that’s common to a lot of large and growing companies today. But different companies work differently, use particular toolsets, and have unique use cases. By making Backstage open source, we can build it with people working inside a variety of engineering organizations all over the world. It makes for a better product that serves a wider group of users (beyond that of Spotify’s) and their needs.
|
||||
|
||||
The Backstage community is healthy and growing quickly. Over [130 people](https://github.com/backstage/backstage/graphs/contributors) have contributed to the project, and roughly 40% of pull requests are now coming from external, non-Spotify, contributors. With companies now deciding to [adopt Backstage](https://github.com/backstage/backstage/blob/master/ADOPTERS.md) we are also seeing a shift in the kinds of contributions we are getting from the community. It is truly amazing to see contributions to core parts of the platform as well as significant functionality additions through working [plugins](https://backstage.io/plugins).
|
||||
|
||||
We’re excited to embark on this journey with the CNCF community. There’s so much great tech being built here, and it’s about time we share it to build even greater products, together. Entering into the CNCF Sandbox is just the first step. We are committed to working with the community to bring Backstage through the Incubation step, and finally all the way to becoming a Graduated, top-level project.
|
||||
|
||||
Thanks to everyone for your support so far. We hope you [join us](https://info.backstage.spotify.com/newsletter_subscribe) in this next chapter of Backstage's journey. If you have questions or feedback, feel free to [email](mailto:backstage-interest@spotify.com) me directly.
|
||||
@@ -1,107 +0,0 @@
|
||||
---
|
||||
title: How to design for Backstage (even if you’re not a designer)
|
||||
author: Kat Zhou, Spotify
|
||||
authorURL: http://twitter.com/katherinemzhou
|
||||
---
|
||||
|
||||
|
||||
|
||||
We are excited to launch the Backstage Design System, which includes a [Figma UI kit](https://www.figma.com/community/file/850673348101741100), a rich set of [reusable code components](http://backstage.io/storybook) on Storybook, and [Guidelines](https://backstage.io/docs/dls/design) for designers and developers as they build plugins for Backstage.
|
||||
|
||||
<!--truncate-->
|
||||
|
||||
## Not just the way it looks
|
||||
|
||||
We see great design as one of the secret weapons of Backstage. Design should never be an afterthought — we believe an elegant, cohesive UX is vital to what makes Backstage such a productive, end-to-end development environment.
|
||||
|
||||
Backstage keeps engineers from getting lost inside the complexity of your infrastructure by bringing order to your software ecosystem (through the [service catalog](https://backstage.io/blog/2020/06/22/backstage-service-catalog-alpha)) and providing an abstraction layer on top of it. How that abstraction layer works is essential to how Backstage works. So we’ve spent time figuring out how to make great design in Backstage easier to achieve for both designers and non-designers alike.
|
||||
|
||||
Since making Backstage open source, we’ve been able to host design studios and user interviews with teams outside Spotify to get feedback and collaborate on a design system, together. (And we’re always keen on collaborating with more organizations.)
|
||||
|
||||
|
||||
_Screenshot of our design studio for Backstage Search, which included stakeholders inside and outside of Spotify._
|
||||
|
||||
As Backstage has gained traction, we’ve seen the importance of creating a scalable and coherent design system. It’s through the shared guidelines of our design system that we are able to maintain a unified ecosystem of plugins for our users, globally. Let’s get started by taking a closer look at the different design components of a plugin.
|
||||
|
||||
## Anatomy of a plugin
|
||||
|
||||
|
||||
|
||||
Plugins are what provide the feature functionality in Backstage, allowing you to customize it to fit your infrastructure. They are integrated into Backstage's frontend, so that no matter what tool or service is being accessed, users are guaranteed a seamless experience.
|
||||
|
||||
As you begin to [build your own plugins](https://backstage.io/docs/plugins/), we encourage you to explore the [open source plugins](https://backstage.io/plugins) we have available in Backstage, as reference. The anatomy of a plugin is simple. In the example below, we’ve highlighted a few of the standard components you should consider when designing your plugin.
|
||||
|
||||
|
||||
|
||||
1. **Tabs.** Want to include multiple pages in your plugin? Use our tab component so users can easily navigate through your plugin.
|
||||
2. **Title.** Plugin pages should always have a title. Subheads are optional. Typically, the ‘star’ icon is included in the overview tab, which allows the user to favorite the plugin, adding it to the side navigation.
|
||||
3. **Cards.** Use the card components to display different kinds of content and functionality. You can follow our 12-column, responsive grid system to arrange the cards.
|
||||
4. **Support.** There should always be a support button (tertiary style, with icon). There can also be a primary action button as well as a secondary one.
|
||||
5. **Header.** Use the Backstage header to allow for users to easily understand what they’re looking at. You can include an optional subhead as well as other information. The color varies depending on the type of plugin you’ve built (stand-alone tool, service, app, website, etc.).
|
||||
|
||||
Now that we’ve familiarized ourselves with the basic parts of a plugin, let’s take a look at some of the tools and resources that make designing plugins even easier.
|
||||
|
||||
## Tools and resources
|
||||
|
||||
The quickest way to start is by duplicating our [Figma UI kit](https://www.figma.com/community/file/850673348101741100), then clicking on the Create a Plugin page on the left-hand side to grab some templates. Feel free to experiment and play around! Figma is a fantastic, multiplayer tool that allows for designers and developers to co-create components and share specs with ease. We’re excited to see what you design and develop.
|
||||
|
||||
As you’re designing and building your plugins, make sure to take advantage of these helpful resources.
|
||||
|
||||
|
||||
|
||||
|
||||
### [Figma Community](https://www.figma.com/@backstage)
|
||||
|
||||
We are thrilled to be using [Figma Community](https://www.figma.com/@backstage) to share our design assets. You can duplicate our UI kit and design your own plugin for Backstage. Figma Community is currently in beta, so this is a neat opportunity to be testing out a new way of working. At the moment, it doesn’t support auto-updating of duplicated files, so we’ll be announcing new versions of our UI kit on Discord in the #design channel.
|
||||
|
||||
|
||||
|
||||
### [Storybook](https://backstage.io/storybook/)
|
||||
|
||||
You can view (and grab) our [reusable components on Storybook](https://backstage.io/storybook/). If you’d like to help build up our design system, you can also help us add components that we’ve designed to Storybook as well. We post newly designed components and patterns to GitHub as issues, where contributors can pick them up and add them to our Storybook so they’re available for the rest of the Backstage community.
|
||||
|
||||
|
||||
|
||||
### [Guidelines](https://backstage.io/docs/dls/design)
|
||||
|
||||
To keep up with our latest design guidelines, go to [Designing for Backstage](https://backstage.io/docs/dls/design). You’ll find more how-to’s and you can also learn more about our design philosophy and practices there. Down the line, we plan on including more in-depth component rules in this section (i.e., dos/don’ts, use cases, etc.).
|
||||
|
||||
|
||||
|
||||
### [GitHub](https://github.com/backstage/backstage)
|
||||
|
||||
Join in on the action [at backstage/backstage on GitHub](https://github.com/backstage/backstage) by submitting issues and opening pull requests for all things related to components and patterns in Backstage.
|
||||
|
||||
|
||||
|
||||
### [Discord](https://discord.com/invite/MUpMjP2)
|
||||
|
||||
All design questions should be directed to the [#design](https://discord.com/channels/687207715902193673/696709358544879716) channel in [Discord](https://discord.com/invite/MUpMjP2).
|
||||
|
||||
## What's next for Backstage design
|
||||
|
||||
There are a lot of exciting things that we’re envisioning for Backstage and open source design at Spotify. These include:
|
||||
|
||||
- Expanding our Backstage Design System by building on the UI kit and component library in Figma and Storybook
|
||||
|
||||
* Collaborating with more of our amazing contributors to ensure our Backstage Design System works for everyone
|
||||
|
||||
* Featuring rad plugins that folks have created, using our design system, in our Figma Community space
|
||||
|
||||
* Building up our Guidelines by continuing to creating robust design documentation
|
||||
|
||||
* Ensuring that we maintain accessible practices throughout our experience
|
||||
|
||||
|
||||
|
||||
## Get involved
|
||||
|
||||
Designing in the open needs to be democratic and participatory, which is why we invite you to join in on the fun! There are a couple things you can do to get involved, such as:
|
||||
|
||||
- **Build with us!** Are there components/plugins that you’d like to see in Backstage? Feel free to create an example/prototype of what you’re envisioning and create a UX component issue in our GitHub repo.
|
||||
|
||||
- **Chat with us!** If you have questions, ideas, or puppy GIFs, feel free to reach out to us on Discord in the #design channel.
|
||||
|
||||
- **Share with us!** One of our priorities is making Backstage more accessible, and we need your help. If you’ve got A11Y insights and ideas on how we can improve our product, please let us know!
|
||||
|
||||
- **Work with us!** We are hiring for product designers to work on Backstage. We strongly stand for breaking traditional pipelines and elevating our caliber by hiring the best folks who are underrepresented minorities in tech today. Keen on joining? Know someone who has a knack for open source design and design systems? Send a direct message to @katz on Discord!
|
||||
@@ -1,43 +0,0 @@
|
||||
---
|
||||
title: The Plugin Marketplace is open
|
||||
author: Stefan Ålund, Spotify
|
||||
authorURL: https://twitter.com/stalund
|
||||
---
|
||||
|
||||
Backstage has an ambitious goal: to provide engineers with the best possible developer experience.
|
||||
|
||||
A great developer experience leads to happy, creative, and productive engineers. Our belief is that engineers should not have to be experts in various infrastructure tools or disciplines (e.g., machine learning or backend) to be productive. Infrastructure should be abstracted away, so that developers can spend more cycles building and testing, quickly and safely. Backstage unifies all your infrastructure tooling, services, and documentation to create a streamlined development environment from end to end.
|
||||
|
||||
Now you may be thinking, “Yeah, sure, that sounds nice and all, but how does Backstage actually abstract away infrastructure?” The short answer: [plugins](https://backstage.io/plugins).
|
||||
|
||||
|
||||
|
||||
<!--truncate-->
|
||||
|
||||
Think of plugins as a mini version of an infrastructure tool or service — just the parts you need, made quick and easy. The advantage of using a Backstage plugin instead of a tool’s dedicated UI is that all your infrastructure is packaged into a “single pane of glass” instead of being spread out like independently built “islands”. Once you grow your infrastructure portfolio, the complexity really starts to add up. The Backstage plugin model allows you to add more tools without increasing the cognitive load for your users.
|
||||
|
||||
Our goal for the plugin ecosystem is that anything can be a plugin. The definition of a plugin is flexible enough to allow you to expose pretty much any kind of infrastructure or software development tool as a plugin in Backstage. By following clear [design guidelines](https://backstage.io/blog/2020/09/30/backstage-design-system) we ensure the overall user experience stays consistent between plugins. If we all do our job well, the end user of Backstage does not see the boundaries between plugins. They are interacting with one consistent product — with many features.
|
||||
|
||||
## Building an ecosystem
|
||||
|
||||
Imagine a not-so-distant future where you walk up to Backstage, install it in your environment, and then choose from a gallery of existing, open source plugins that serve and match whatever infrastructure and software development needs you have inside your company. That means you can get started with Backstage and see the gains of improved productivity within days, not months. That is our vision for the Backstage plugin ecosystem.
|
||||
|
||||
Running services on Kubernetes? There’s a plugin for that. Using Snyk for security scanning? There’s a plugin for that. Grafana, DataDog, or Rollbar for monitoring? There’s a plugin for that. Using Jenkins, CircleCI, GitHub Actions, or Travis CI? Pick the CI plugin of your choice. You get the picture. Regardless of your stack, there’s a plugin that you can use.
|
||||
|
||||
Like this vision? So do we! But we can’t do it alone. We’ll need your help. For this vision to come true, we need to foster a community where many companies and individual developers build and contribute their plugins. Having been [accepted into the CNCF Sandbox](https://backstage.io/blog/2020/09/23/backstage-cncf-sandbox) provides us with the groundwork and guidance to broaden the community even faster.
|
||||
|
||||
This grand vision is actually not that far off. Already today there is a growing ecosystem of Backstage plugins. To highlight all the amazing work that has been done by the community, and make it easier for Backstage adopters to see what plugins are available, we now have a Plugin Marketplace: [https://backstage.io/plugins](https://backstage.io/plugins)
|
||||
|
||||
|
||||
|
||||
## Creating and suggesting new plugins
|
||||
|
||||
Not all plugins you need will be open source. Every company has their own homegrown tooling. Building internal plugins lets you tailor your version of Backstage to be a perfect fit for your infrastructure and software development needs. If you end up [building plugins](https://backstage.io/docs/plugins/create-a-plugin) that could be useful for other companies, please consider releasing them as open source and [add them to the Marketplace](https://backstage.io/docs/plugins/add-to-marketplace).
|
||||
|
||||
If you start developing a plugin that you aim to release as open source, we suggest that you create a [new plugin Issue](https://github.com/backstage/backstage/issues/new?labels=plugin&template=plugin_template.md&title=%5BPlugin%5D+THE+PLUGIN+NAME). This helps the community know what plugins are in development and opens up opportunities for collaboration. You can also use this process if you have an idea for a good plugin, but you need help building it.
|
||||
|
||||
We are really excited to see all the amazing plugins that have already been built, and look forward to seeing even more ideas and collaboration as the Backstage community continues to grow.
|
||||
|
||||
What plugins would you like to see in the Plugin Marketplace? [Tell us](https://github.com/backstage/backstage/issues/new?labels=plugin&template=plugin_template.md&title=%5BPlugin%5D+THE+PLUGIN+NAME)!
|
||||
|
||||
_Special shout-out to community member [Iain Billett](https://github.com/iain-b) from [Roadie](https://roadie.io) for helping build and contribute the [Plugin Marketplace page](https://backstage.io/plugins) (as his first PR no less!)._
|
||||
@@ -1,80 +0,0 @@
|
||||
---
|
||||
# prettier-ignore
|
||||
title: "New Cost Insights plugin: The engineer’s solution to taming cloud costs"
|
||||
author: Janisa Anandamohan, Spotify
|
||||
authorURL: https://twitter.com/janisa_a
|
||||
---
|
||||
|
||||
How did Spotify save millions on cloud costs within a matter of months?? We made cost optimization just another part of the daily development process. Our newly open sourced [Cost Insights plugin](https://github.com/backstage/backstage/tree/master/plugins/cost-insights) makes a team’s cloud costs visible — and actionable — right inside Backstage. So engineers can see the impact of their cloud usage (down to a product and resource level) and make optimizations wherever and whenever it makes sense. By managing cloud costs from the ground up, you can make smarter decisions that let you continue to build and scale quickly, without wasting resources.
|
||||
|
||||
<iframe width="780" height="440" src="https://www.youtube.com/embed/YLAd5hdXR_Q" frameBorder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowFullScreen></iframe>
|
||||
|
||||
Are we turning engineers into accountants? Nope, we’re just letting engineers do what they do best, in the place that feels natural to them: inside Backstage.
|
||||
|
||||
<!--truncate-->
|
||||
|
||||
## Why put a cost management tool in the hands of engineers?
|
||||
|
||||
Engineers are closest to the metal in terms of knowing why a specific feature, product, or service is using cloud resources. So they’re in the best position to understand how costs impact ongoing development (and vice versa).
|
||||
|
||||
If you manage costs top-down from a 10,000-foot view of your cloud infrastructure, you’re likely making decisions far removed from products, especially in larger organizations. Set a broad cost-cutting goal, and you could be creating unintended consequences — curtailing spending at the expense of growth or experimentation.
|
||||
|
||||
## Ground-level intelligence, data-driven solutions
|
||||
|
||||
Our hypothesis at Spotify was, if you bring spending data into an engineer’s everyday development workflow, they’ll naturally look for cost optimizations just like they look for any other optimization. And the cost optimizations will be more efficient and effective, because the decisions are informed at the ground level.
|
||||
|
||||
The problem is that most cloud platforms don’t provide cost data at a granular enough level to make those decisions. And the bigger your organization (say, two-thousand-microservices and four-thousand-data-pipelines big, like Spotify), then the less you can attribute these large, fuzzy numbers to the right team, let alone a shipping product or internal service.
|
||||
|
||||
That’s where Cost Insights comes in. Instead of making cost management and product development separate departments on the org chart, Backstage brings them together — with a level of detail and specificity engineers relate and respond to.
|
||||
|
||||
## How to turn dollars into sense
|
||||
|
||||
It’s not enough to make costs visible. To be useful, the numbers need to be relevant, relatable, and actionable. In other words, not just cost information, but insights. There are several ways the plugin puts data from your cloud provider in a more helpful context.
|
||||
|
||||
### Use business metrics to evaluate costs
|
||||
|
||||
Cost Insights will show you trends at a glance and also let you compare costs quarter over quarter. More importantly, you can also evaluate costs against business metrics that you care most about. In the example below, should the upward slope shown in the first screen be cause for worry? Perhaps not — if you switch views, you’ll see that cost per daily average user (DAU) is actually going down. Exactly what you hope to see as you scale.
|
||||
|
||||
|
||||
_(Note: Screens are examples; they do not show real data.)_
|
||||
|
||||
### Illustrate costs with relatable, real-world comparisons
|
||||
|
||||
In addition to dollar amounts, Cost Insights allows teams to visualize and convert cost overages into more relatable terms. In the example below, we equate the growth in costs for virtual machine instances (100% increase) to developer time spent (about 1 engineer). We use this particular comparison in the plugin because we found it resonated with our own engineers — providing a useful perspective for spending increases. You can configure what the “cost of an engineer” means to your organization. Or engineers can build in their own comparisons — cups of coffee, carbon offset credits, electric luxury vehicles — whatever makes costs more tangible for them.
|
||||
|
||||
|
||||
_(Note: Screens are examples; they do not show real data.)_
|
||||
|
||||
### Tie spending to specific products and resources
|
||||
|
||||
The more detailed the cost data, the more relevant, actionable, and helpful it is. Cost Insights allows you to attribute costs to products and resources in a way that makes sense to your engineers. For example, here we see a breakdown of data processing costs by individual pipelines. This allows your team to target optimizations more precisely.
|
||||
|
||||
|
||||
_(Note: Screens are examples; they do not show real data.)_
|
||||
|
||||
## Driving down costs without slowing down development
|
||||
|
||||
When it comes to cutting costs, we actually want to guard against over-optimization. Growth and costs can go hand in hand. The trick is knowing when one is out of balance and needs addressing. Our product highlights when there’s been a large increase in spending, so that engineers are thinking about cost only when they must and aren’t distracted from their set goals and priorities.
|
||||
|
||||
Engineers can then determine for themselves if the time invested in an optimization was valuable compared to the costs saved. Cost Insights puts the decision in our engineers’ hands for them to choose when to focus on growth efforts and when to focus on cost. Control, as ever, remains with our developers, where we think it belongs.
|
||||
|
||||
## Getting started
|
||||
|
||||
You can begin working with the Cost Insights plugin today on [GitHub](https://github.com/backstage/backstage/tree/master/plugins/cost-insights). We include an example client with static data in the expected format. The `CostInsightsApi` should talk with a cloud billing backend that aggregates billing data from your cloud provider.
|
||||
|
||||
The current release of Cost Insights includes:
|
||||
|
||||
- Daily cost graph by team or billing account
|
||||
- Cost comparisons against configurable business metrics (including an option for Daily Active Users)
|
||||
- Insights panels — configurable for the cloud products your company uses
|
||||
- Cost alerts and recommendations
|
||||
- Selectable time periods for month-over-month or quarter-over-quarter comparisons
|
||||
- Conversion of cost growth into “cost of average engineer” to help optimization trade-off decisions
|
||||
|
||||
Our hope is to help other companies translate their cloud cost in a relatable way for their engineers to better understand their impact and accurately identify their opportunities for optimizations.
|
||||
|
||||
And if you’re interested in contributing to our outstanding issues, you can find them in the issues queue, filtered under the [‘cost-insights’ label](https://github.com/backstage/backstage/labels/cost-insights).
|
||||
|
||||
## Ready for DevSecCostOpsPlus (and whatever’s next)
|
||||
|
||||
There’s DevOps, there’s DevSecOps, and then there’s Backstage: one frontend for all your infrastructure. From building, testing, and deploying to monitoring and security — Backstage helps you manage your entire tech organization and provides a seamless developer experience for engineers, from end to end to end. And now that also extends to cost management for your cloud infrastructure and tooling. Happy building and [happy optimizing](https://github.com/backstage/backstage/tree/master/plugins/cost-insights).
|
||||
@@ -1,44 +0,0 @@
|
||||
---
|
||||
title: Announcing the Backstage Stability Index
|
||||
author: Patrik Oldsberg, Spotify
|
||||
authorURL: https://github.com/Rugvip
|
||||
---
|
||||
|
||||
2022-01 update: The stability is now replaced by the [versioning policy](https://backstage.io/docs/overview/versioning-policy).
|
||||
|
||||
**TL;DR** Backstage is heading out of alpha and moving onto the path to stable releases and an eventual version 1.0. As the community and ecosystem continue to grow at an increasing rate, we want to provide a solid foundation for everyone building things in, with, and around Backstage. So, today we’re introducing the [Stability Index](https://backstage.io/docs/overview/versioning-policy) — a simple way to find out how likely (or unlikely) a specific package or plugin inside Backstage might be updated with major changes. By indicating the reliability of key features and APIs, this quick reference will help contributors and adopters better plan and coordinate their development efforts going forward.
|
||||
|
||||
|
||||
|
||||
<!--truncate-->
|
||||
|
||||
Backstage has a great and growing community of users and contributors. With so much valuable feedback, this inevitably means that sometimes we will go back and revise design decisions that introduce breaking changes. Furthermore, as we continue to ship new features and systems, we’ll continue this cycle of iterating, gathering feedback, and iterating again before reaching a stable API.
|
||||
|
||||
This rapid evolution can create uncertainty around which parts of the project are considered stable and which are not. Regardless of whether you're contributing to the project directly, setting up your own Backstage, or building plugins, you will be using various parts of the project that vary in stability. While many API surfaces of Backstage are reasonably solid and are unlikely to see any big breaking changes, others are more unstable or experimental.
|
||||
|
||||
## The Stability Index
|
||||
|
||||
In order to tackle the problem of uncertainty, and help align contributors, we have recently introduced a Stability Index. Inspired by a [similar concept with the same name in Node.js](https://nodejs.org/docs/latest-v4.x/api/documentation.html#documentation_stability_index), it’s a score assigned to subsets of the project, indicating the level of maturity of the API and the commitment to backwards compatibility. However, because of the current phase of the project, we have used a slightly different implementation. Rather than the score indicating a perceived stability, a higher score is instead a commitment to providing a smoother upgrade path for users, both through better documentation and backwards compatibility. Importantly, the Stability Index does not supersede [semantic versioning](https://semver.org/) (or semver), meaning we will still adhere to semver and only do breaking changes in minor releases as long as we are on 0.x.
|
||||
|
||||
You can find more details about the scores on the [Stability Index](https://backstage.io/docs/overview/versioning-policy) page, but the following is a TL;DR of the 0–3 scores:
|
||||
|
||||
- **0** — There's a changelog entry.
|
||||
- **1** — There's a migration guide.
|
||||
- **2** — Two weeks of deprecation.
|
||||
- **3** — Three months of deprecation.
|
||||
|
||||
The Stability Index has been tailored for the phase that the project is currently in, and we do not intend to keep it in place in its current form forever. It is, for example, likely that we in the future will increase the deprecation time limits.
|
||||
|
||||
## Staying up to date
|
||||
|
||||
In addition to the Stability Index, we have also recently adopted a weekly release cadence where we cut new releases every Thursday. Along with the two-week deprecation period of many of the API surfaces in Backstage, there is an excellent opportunity to form a routine to update your own Backstage projects either weekly or biweekly.
|
||||
|
||||
In order to make the update process easier, we’ve added a new command to the Backstage CLI that allows you to easily update your project to use the latest Backstage release. The command is called `version:bump` and is executed in the root of your project using the CLI. You can see what it looks like in action below.
|
||||
|
||||
|
||||
|
||||
## Impact
|
||||
|
||||
The Stability Index has already been active for a couple of weeks, and we have immediately seen an impact on the consideration and care taken when working in parts of the project that we have committed to keeping more stable. Both members of the core maintainer team and contributors from the community have taken care to roll out updates responsibly, with examples such as [PR #3524](https://github.com/backstage/backstage/pull/3524) and [PR #3465](https://github.com/backstage/backstage/pull/3465).
|
||||
|
||||
The core team is working hard to bring more stability to broader parts of Backstage, and engineering it in a way that allows for long-term evolution. There are more learnings to be discovered as we continue evolving Backstage, but we are confident that the Stability Index will allow for a clearer path and a smoother ride for everyone involved!
|
||||
@@ -1,73 +0,0 @@
|
||||
---
|
||||
# prettier-ignore
|
||||
title: "New Backstage feature: Kubernetes for Service owners"
|
||||
author: Matthew Clarke, Spotify
|
||||
authorURL: https://github.com/mclarke47
|
||||
---
|
||||
|
||||
|
||||
|
||||
TLDR; We’re rethinking the Kubernetes developer experience with a new feature: a Kubernetes monitoring tool that’s designed around the needs of service owners, not cluster admins. Now developers can easily check the health of their services no matter how or where those services are deployed — whether it’s on a local host for testing or in production on dozens of clusters around the world.
|
||||
|
||||
And since Backstage uses the native Kubernetes API, the feature works with whichever cloud provider (AWS, Azure, GCP, etc.) or managed service (OpenShift, IBM Cloud, GKE, etc.) you already use.
|
||||
|
||||
<!--truncate-->
|
||||
|
||||
## The missing link between K8s and your service
|
||||
|
||||
A core feature of Backstage is its service catalog, which aggregates information about software systems together inside a single tool, with a consistent, familiar UI.
|
||||
|
||||
By navigating to a service’s overview page in Backstage, you can see everything you need to know about the service: what it does, its APIs and technical documentation, CI/CD progress — and now detailed information about its presence on Kubernetes clusters.
|
||||
|
||||
## No more context switching
|
||||
|
||||
Kubernetes in Backstage can be configured to search multiple clusters for your services. It will then aggregate them together into a single view. So if you deploy to multiple clusters you will no longer need to switch kubectl contexts to understand the current state of your service.
|
||||
|
||||
|
||||
|
||||
## Automatic error reporting
|
||||
|
||||
Instead of trying different kubectl commands to figure out where an error occurred, Backstage will automatically find and highlight errors in Kubernetes resources that are affecting your service. So you can spend time fixing errors, not hunting for them.
|
||||
|
||||
|
||||
|
||||
## Autoscaling limits at a glance
|
||||
|
||||
Backstage also shows you how close your service is to its autoscaling limit. Coming up to a period of high load? Now you will be able to see how your horizontal autoscaling is dealing with it across multiple clusters.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## Pick a cloud, any Cloud
|
||||
|
||||
Since Backstage communicates directly with the Kubernetes API, it’s cloud agnostic — it doesn’t matter how or where you’re running Kubernetes. You’ll always get the same familiar view of your deployments, whether you’re:
|
||||
|
||||
- Deploying to clusters on AWS, Azure, GCP, or another cloud provider
|
||||
- Using an unmanaged or managed Kubernetes service (like OpenShift, etc.)
|
||||
- Migrating from one cloud provider or service to another
|
||||
- Testing on a single local machine or deploying to a dozen clusters in production
|
||||
|
||||
In short: local or global, single or multi-cloud, managed or unmanaged — Backstage always provides a seamless Kubernetes experience for your service owners’ day-to-day development needs.
|
||||
|
||||
## Rethinking the developer experience
|
||||
|
||||
The philosophy behind Backstage is simple: improve developer experience by reducing infrastructure complexity. As popular and widespread as Kubernetes has become, all of the tools to date have been geared toward the needs of cluster admins. These tools add unnecessary complexity to the workflows of the typical developer building, testing, and deploying services.
|
||||
|
||||
We believe Backstage Kubernetes gives developers back control of their services by providing a more focused and consistent experience. Backstage provides a single standard for developers to monitor their Kubernetes deployments, regardless of the underlying cloud infrastructure.
|
||||
|
||||
## Future iterations
|
||||
|
||||
The current focus of Kubernetes in Backstage is Deployments/ReplicaSets/Pods — but we know that not everyone utilizes these.
|
||||
|
||||
As we continue to grow and develop Kubernetes in Backstage with the community, we hope to offer support for Kubernetes resources beyond Deployments and Custom Resource Definitions. You can browse or add open issues for the plugin [here].
|
||||
|
||||
## Getting started
|
||||
|
||||
We made the Kubernetes plugin a core feature of Backstage. Like Software Templates (scaffolder) and TechDocs, the k8s-plugin is installed with the core app. When you update the app to the latest version and go to the Kubernetes tab of any service, you will be asked to provide your cloud provider credentials. To learn more, including details on configuration and surfacing your Kubernetes components as part of an entity, [read the docs].
|
||||
|
||||
To contribute or get more information on Kubernetes in Backstage, [join the discussion on Discord]!
|
||||
|
||||
[here]: https://github.com/backstage/backstage/issues?q=is%3Aissue+is%3Aopen+kubernetes+label%3Ak8s-plugin
|
||||
[read the docs]: https://backstage.io/docs/features/kubernetes/overview
|
||||
[join the discussion on discord]: https://discord.gg/backstage-687207715902193673
|
||||
@@ -1,135 +0,0 @@
|
||||
---
|
||||
title: Where do you start when adopting Backstage?
|
||||
author: Austin Lamon, Spotify
|
||||
authorURL: https://www.linkedin.com/in/austinlamon
|
||||
---
|
||||
|
||||
|
||||
|
||||
One of the greatest strengths of Backstage also presents a never-ending challenge: Backstage is highly customizable and allows you to easily build a unique developer portal suited to your organization’s needs. The downside of this flexibility is that it can be hard to know where to start. Backstage can do so many things — integrating every part of your tech infrastructure and developer experience — but if you set off building a developer portal without a plan, it’s easy to get overwhelmed by all the possibilities. To help you form your plan, this post will detail how Spotify came to design our internal portal and recommend potential models for you to use when designing and building your own.
|
||||
|
||||
<!--truncate-->
|
||||
|
||||
## Infrastructure as tech culture
|
||||
|
||||
Before providing recommendations on getting started with Backstage, it’s helpful to have a bit of context as to why Spotify made the design decisions we did. No two companies are identical — and thus, no two Backstage implementations are the same.
|
||||
|
||||
Rolling back the clock just a few years, [Spotify was challenged](https://engineering.atspotify.com/2021/05/18/a-product-story-the-lessons-of-backstage-and-spotifys-autonomous-culture/) to continue to scale our engineering team (and the number of features and components built) but retain the speed of product development. Some user research with Spotify developers highlighted a clear problem: there was simply too much non-documented institutional knowledge needed to get things done. No one could find anything and everyone was interrupting everyone else trying to figure things out.
|
||||
|
||||
Spotify’s developers were facing three big challenges on a daily basis:
|
||||
|
||||
- They not only needed to build software quickly, they also needed to pass along knowledge to new joiners about how best to create new components.
|
||||
- They needed to somehow maintain a mental model of the systems their squad owned. (Or, if they were lucky, they found a hopefully-up-to-date spreadsheet tracking this information.)
|
||||
- They needed to keep an eye on what squads around them might be building to ensure they could reuse systems when they needed to solve similar problems in the future.
|
||||
|
||||
In short, Spotify developers needed to continue building industry leading features at breakneck speed, while simultaneously maintaining a mental model for all the software at Spotify (oh, and help every new joiner develop that mental model as well!).
|
||||
<br/>
|
||||
|
||||
## Three jobs: Create, manage, explore
|
||||
|
||||
Around the same time, the [jobs to be done](https://hbr.org/2016/09/know-your-customers-jobs-to-be-done) framework was becoming popular and luckily, a few Spotifiers helped guide the vision for a _sense-making tool for developers_ toward using it. After user research and many failed attempts, we landed on three jobs Spotify developers needed to do consistently:
|
||||
<br/>
|
||||
|
||||
- **Create**: Spotify developers want to delight their customers with incredible features. They create new software to do that.
|
||||
- **Manage**: Spotify developers are proud of their work and treat their software and data like products. That requires maintaining all the software they own on an ongoing basis.
|
||||
- **Explore**: Spotify developers want to solve new, yet unsolved problems. They try to build on existing systems to help them do that.
|
||||
|
||||
So: make software, maintain the software you own throughout its lifecycle, and integrate with other people’s software.
|
||||
|
||||
Within today’s complex development environments, there are barriers both big and small that get in the way of those three jobs. Backstage provides the building blocks for removing those barriers, streamlining your development cycle, and letting developers do what they really want to do: build great features. Let’s take a closer look at each of these jobs.
|
||||
|
||||
|
||||
|
||||
### Create
|
||||
|
||||
**Job:** You’re an engineer, ready to start building a new microservice. Do you just pick whatever framework you want? How do you reserve capacity to run your service in production? What about managing CI/CD?
|
||||
|
||||
**Tool:** At Spotify, we use **Backstage Software Templates** to simplify all of this, reducing time–to–Hello World to just a few clicks. Instead of researching Spring Boot versus Helidon, opening a Jira ticket, rummaging through docs, and configuring CI automations, you just choose a template and your project is automatically set up in the repo for you, with the CI already running your first build.
|
||||
|
||||
**Result:** By making it easier to start new projects, your engineers get to the good part of coding features faster. And your organization’s best practices are built into the templates, encouraging standards and reducing complexity in your tech ecosystem.
|
||||
|
||||
|
||||
|
||||
### Manage
|
||||
|
||||
**Job:** You’re on a small team that owns a dozen services. Whenever you update and deploy those services, you’re switching between your CI, the AWS console, a security dashboard, and a CLI so you can try to figure out which Kubernetes cluster your service ended up on. In other words, you have a lot of open windows and tabs, and each step means switching to a new interface.
|
||||
|
||||
**Tool:** All of your team’s software components are organized together on one page in the **Backstage Service Catalog**. Go to any service’s page from there and its CI/CD status, [Kubernetes deployment status](https://backstage.io/blog/2021/01/12/new-backstage-feature-kubernetes-for-service-owners), documentation, security checks — and everything else related to that service — is grouped together in one seamless interface that shows you only the info you want.
|
||||
|
||||
**Result**: One page in Backstage has everything you need to manage the software you own. No more context-switching. No more digging through your cloud provider’s obscure admin features. Outside the repo and your IDE, everything you need to manage your service is right inside Backstage.
|
||||
|
||||
|
||||
|
||||
### Explore
|
||||
|
||||
**Job:** You're building a new mobile feature that needs to ensure a user is paying for the premium version of your product — but someone must’ve already built a library that handles that, right? A company-wide email and a few calls for help on Slack yield no response, so you resign yourself to building the capability yourself. Turns out someone did build the library you needed. They were just on vacation so they didn’t see your messages. How do you enable better discovery and collaboration across your org?
|
||||
|
||||
**Tools:** At Spotify, anyone can find everyone else’s software — because everything is centralized inside Backstage, organized by the **Backstage Service Catalog** and accessible by **search**. Go to any library or services page, and you’ll find the owners and documentation, even its API and how to extend it if need be.
|
||||
|
||||
**Result:** One place for everything, one place to search. Developers can more easily share components, build on top of each other’s work, and discover tools, libraries, frameworks, documentation, system designs, org charts, and more.
|
||||
|
||||
## Sounds great. Where do I start?
|
||||
|
||||
After talking with companies who have already adopted Backstage, we’ve seen a few common strategies for getting started. The different strategies are based on the size of your engineering org (which often also corresponds with how fast you’re growing).
|
||||
|
||||
|
||||
<br/>
|
||||
|
||||
### My org has ~200 engineers (and is growing fast)
|
||||
|
||||
You’re big enough to start feeling the pain, and only getting bigger. Onboarding and discoverability are your biggest challenges.
|
||||
|
||||
**Pain points:**
|
||||
|
||||
- This size seems to be the tipping point — where complexity is taking hold, collaboration starts breaking down, and ad hoc solutions stop working.
|
||||
- Often this is also when you’re growing so fast (doubling in size every 6–12 months) that there are now more new engineers than old engineers.
|
||||
- New engineers can’t find anything, so they ask around, which pulls all your other engineers off-task with interruptions.
|
||||
- Logjams form. One company told us how it was taking 3–4 days for pull requests to get merged.
|
||||
|
||||
**Recommendation — Explore, then create:**
|
||||
|
||||
- New engineers need an easy way to find out how to do things, so you’re not just adding bodies, you’re adding happy, productive contributors.
|
||||
- To streamline onboarding, start with centralizing your documentation and making your tools and software components discoverable in Backstage.
|
||||
- At this size, you might not have a dedicated platform/infra team in place yet, but Backstage can provide the framework for centralizing and sharing knowledge — from managing compliance requirements to finding the right API documentation.
|
||||
- This allows both new and old engineers to collaborate more efficiently, easily discover best practices, and cuts down on duplicated work (e.g., a new team doesn’t end up rebuilding a database that already exists but nobody can find).
|
||||
|
||||
|
||||
|
||||
### My org has ~1,000 engineers
|
||||
|
||||
You’re officially big. Lots and lots of teams are managing lots and lots of software — and the frustration of switching between all the various tools to do that is growing exponentially.
|
||||
|
||||
**Pain points:**
|
||||
|
||||
- Fragmentation and entropy are real threats to productivity. From security requirements to cluster management to a thousand data endpoints, there’s too much to keep track of, leading to cognitive overload.
|
||||
- A death by a thousand cuts: constantly logging into new interfaces — from your cloud provider’s console to some brand new security tool then back to your CI/CD — is bogging your engineers down with too much context-switching and a lot of noise.
|
||||
- Every day, it’s getting more and more difficult for one team to manage their own microservices, data, and documentation, let alone share their knowledge with other teams.
|
||||
|
||||
**Recommendation — Manage, then explore, then create:**
|
||||
|
||||
- Backstage will allow your teams to get a handle on the software they own, since everything they need to manage it is in one place.
|
||||
- From CI/CD status to documentation to deciphering a monorepo, Backstage makes it easy to manage a service (or other software component) on a day-to-day basis.
|
||||
- The service catalog also helps your developers visualize your existing software ecosystem, beyond the software they own. And with Backstage Software Templates, every new software component is already added to the catalog.
|
||||
- Even at this scale, a small platform team should be all it takes to build and maintain your own version of Backstage. At Spotify, we have a 4-person team responsible for our internal version of Backstage, which is used by all of Spotify’s 1,600+ developers.
|
||||
|
||||
|
||||
|
||||
### My org has 1,000+ engineers
|
||||
|
||||
Integrating infrastructure of this size and complexity can seem overwhelming. It’s an even bigger challenge to bring this level of change to a well-established culture with ingrained processes.
|
||||
|
||||
**Pain points:**
|
||||
|
||||
- When you’re this large, you’ve incorporated a lot of technology and processes, as well as a lot of partners, each with their own technologies and processes.
|
||||
- You’re focussed on “replacing cruft” and bringing discoverability and order to your vast ecosystem of components and tools.
|
||||
- Getting your tools adopted by your engineers while modernizing your tech stack and coordinating with your infra teams to improve your engineering practices across the whole company… it’s a lot.
|
||||
|
||||
**Recommendation — Create, then manage, then explore:**
|
||||
|
||||
- The fastest way to bring change to your ecosystem is to start at the beginning of the chain with Backstage Software Templates.
|
||||
- With every new component created with your templates, you’re establishing best practices and rewarding your developers with a streamlined experience focused on their needs — all the while building up your new service catalog.
|
||||
- The more the templates ease the process of starting up a project, the more your engineers will adopt them, and the faster the other benefits of Backstage will build up, transforming productivity across your organization. ([That’s how we did it at Spotify](https://open.spotify.com/episode/7iuQ3ew1Wwpuiq6LbBKzCl).)
|
||||
|
||||
## More questions about adopting Backstage?
|
||||
|
||||
[Contact the Backstage team at Spotify.](https://backstage.spotify.com/) We’ll share more about what we’ve learned from our experience here at Spotify — and from other companies who are already using Backstage to transform their developer experience.
|
||||
@@ -1,75 +0,0 @@
|
||||
---
|
||||
title: How Spotify is helping more companies adopt Backstage
|
||||
author: Austin Lamon, Spotify
|
||||
authorURL: https://www.linkedin.com/in/austinlamon
|
||||
---
|
||||
|
||||
[](https://backstage.spotify.com/)
|
||||
_[backstage.spotify.com](https://backstage.spotify.com)_
|
||||
|
||||
The Backstage community is growing! In just over [a year](https://engineering.atspotify.com/2021/03/16/happy-birthday-backstage-spotifys-biggest-open-source-project-grows-up-fast/), Backstage has gone from a few open source building blocks to a thriving platform used by engineering orgs with thousands of developers. But even with 30+ [adopting companies](https://github.com/backstage/backstage/blob/master/ADOPTERS.md) and 400+ contributors, we are still in the very early stages of reaching the platform’s potential.
|
||||
|
||||
In order to grow Backstage further, Spotify is increasing the support we provide both adopters (the people integrating Backstage into their organizations) and contributors (the people building features and improving the code). The more companies that adopt Backstage, the more support the project gets, the stronger the platform becomes for everyone.
|
||||
|
||||
And while Spotify remains committed to maturing the Backstage platform — both as original creator and active maintainer — we also want to make room for the community to take greater ownership. Backstage may have started inside Spotify, but it belongs to all of you. So, we hope you join us in what’s next.
|
||||
|
||||
<!--truncate-->
|
||||
|
||||
## What’s next: More support for adopters and contributors
|
||||
|
||||
Alongside the code contributions, technical support, and community leadership provided by our dedicated (and still growing) Backstage team, Spotify is introducing three additional ways to help lower the barriers to adopting the platform:
|
||||
|
||||
1. **New consulting support.** In addition to investing in the Backstage getting started experience and the technical support we already provide, we’re adding [consulting support](https://backstage.spotify.com) for companies who are looking to adopt (or are already in the middle of adopting) Backstage.
|
||||
2. **Double the community sessions.** We are creating separate meetups for Backstage adopters and Backstage contributors for more focused discussions. (Come to both!)
|
||||
3. **Adding reviewers and maintainers.** We recently introduced [reviewers](https://github.com/backstage/backstage/pull/5137) to the Backstage project to speed up PR reviews and approvals, with the hope of also adding more maintainers in the future.
|
||||
|
||||
## Why Spotify is increasing its investment in open source (and why now)
|
||||
|
||||
Before we talk in more detail about these new efforts, why is Spotify doing this? The short answer is the same answer as when we released the very first open source version of Backstage: we envision Backstage as the standard developer portal platform across the industry.
|
||||
|
||||
### Setting the standard, both inside and outside Spotify
|
||||
|
||||
We believe in Backstage — we believe in the developer experience it provides, the developer-centric culture it encourages, and the immense value that the open source community brings to it. It is no exaggeration to say that we depend on Backstage every day at Spotify. It’s the central hub for our internal R&D community, and it’s both mission-critical to our daily operations and our future growth.
|
||||
|
||||
### We’re an adopter, too
|
||||
|
||||
We (that includes Spotify’s leadership, as well as our platform teams and dedicated Backstage team) also believe that Backstage’s continued success here — inside Spotify — depends on its success out here — in the wider open source community, where Backstage can reach its full potential. Like other adopters, we’re fully invested in the platform’s growth.
|
||||
|
||||
### An open platform is the strongest platform
|
||||
|
||||
We genuinely believe that the best platform for developers can only be shaped by the most diverse group of developers. Each new adopter and every new contributor brings unique perspectives and experiences to the challenges of improving developer experience and effectiveness. As the project scales — and progresses toward CNCF graduation — we need to make more room in the community for both adopters and contributors.
|
||||
|
||||
So, let’s get to it.
|
||||
|
||||
## Consulting support (and a new website) for adopters
|
||||
|
||||
[](https://backstage.spotify.com/)
|
||||
|
||||
We’ve launched a new website at: [backstage.spotify.com](https://backstage.spotify.com). It’s a hub for new and potential adopters to receive support from Spotify and our Preferred Partners. The site is focused on helping organizations get up and running with Backstage by addressing their unique needs and use cases.
|
||||
|
||||
You’ll find a high-level introduction to the platform, tips and tricks tested by Spotify to accelerate developer effectiveness, and access to a group of partners that have scaled Backstage for numerous adopters. You can also use the site to book product overviews, demos, and technical deep dives with members of the Spotify team.
|
||||
|
||||
We will continue to post important product announcements, technical documentation, feature demos, and community news here on Backstage.io. ([Subscribe to the newsletter](https://info.backstage.spotify.com/newsletter_subscribe) to stay up to date.) And both contributors and adopting companies can continue to find around-the-clock/around-the-world technical support on [GitHub](https://github.com/backstage/backstage) and [Discord](https://discord.gg/backstage-687207715902193673).
|
||||
|
||||
## Separate community sessions for adopters and contributors
|
||||
|
||||
[](https://github.com/backstage/community/#backstage-community)
|
||||
|
||||
Earlier this year, we began hosting [Backstage Community Sessions](https://github.com/backstage/community/#backstage-community) — official meetups for anyone who wanted to join them. Since [the very first one](https://youtu.be/4-VX9tDdJYY), the Backstage team has been inspired and humbled by the community’s participation in these sessions — from hearing the [Expedia Group team share their journey adopting Backstage](https://youtu.be/rRphwXeq33Q?t=1509) to discussions about TypeScript and Material-UI. It’s great collaborating through code — but it’s also a lot of fun when you can see each other’s faces and have a conversation.
|
||||
|
||||
And while these sessions have been a success, the feedback we’ve gotten from the community has been very clear: more frequent and more focused conversations. So, later this summer, we’ll be launching standalone Backstage Adopter Sessions and Backstage Contributor Sessions. We hope this will lead to more useful sessions for everyone — and, of course, you are welcome to attend either or both:
|
||||
|
||||
- **For the adopter sessions:** we invite you to share the challenges, learnings, and use cases you’re facing with companies similar to yourselves.
|
||||
- **For the contributor sessions:** we invite you to share thoughts, suggestions, and gaps in the Backstage core with the maintainers and reviewers.
|
||||
|
||||
Speaking of reviewers and maintainers…
|
||||
|
||||
## Adding reviewers and maintainers
|
||||
|
||||
[](https://github.com/backstage/backstage/blob/master/GOVERNANCE.md#reviewers)
|
||||
|
||||
We have introduced [reviewers](https://github.com/backstage/backstage/blob/master/GOVERNANCE.md#reviewers) to the project! By adding this new role, we’ve expanded the number of people who are permitted to approve and merge pull requests. This will offload some of the review work from the maintainers, simplifying and speeding up the review process for contributors.
|
||||
|
||||
Of course, with these new efforts, we expect even more companies to adopt Backstage, which means the platform will continue to grow, and the number of PRs will continue to grow with it. As that happens, we hope to add to both the maintainer and reviewer teams in the future.
|
||||
|
||||
So, I’ll end this post as it began: the Backstage community is growing! And we look forward to growing even bigger, even faster, together.
|
||||
@@ -1,102 +0,0 @@
|
||||
---
|
||||
# prettier-ignore
|
||||
title: "Announcing the Backstage Search platform: a customizable search tool built just for you"
|
||||
author: Emma Indal, Spotify
|
||||
authorURL: https://www.linkedin.com/in/emma-indal
|
||||
---
|
||||
|
||||
|
||||
|
||||
**TLDR;** The new Backstage Search is now available in alpha, ready for you to start building on. A total rethinking of the core search feature in Backstage, it’s more than just a box you type into — it’s a mini platform all by itself. With its composable frontend and extensible backend, you can design and build the search tool that suits your organization’s needs.
|
||||
|
||||
So, you don’t just get an improved out-of-the-box experience for searching whatever is in your software catalog. You can also add support for searching other sources, too. Customize it the way you want and you can search your catalog, your plugins and docs — and even external sources, like Stack Overflow and Confluence — all at once, all right inside Backstage.
|
||||
|
||||
With one query, your teams can find exactly what they’re looking for: anything and everything.
|
||||
|
||||
<!--truncate-->
|
||||
|
||||
## Search and explore
|
||||
|
||||
Being able to easily explore your ecosystem — to discover software, tools, documentation, and other valuable knowledge — is one of [the three main jobs of Backstage](https://backstage.io/blog/2021/05/20/adopting-backstage#three-jobs-create-manage-explore). Teams should be able to find what other teams have already built, so they can reuse and contribute to components instead of unknowingly duplicating them. Data endpoints should be shared, not siloed away. Services and their APIs should be easily discoverable. Best practices and technical documentation should be easily found.
|
||||
|
||||
Along with the [Backstage Service Catalog](https://backstage.io/blog/2020/06/22/backstage-service-catalog-alpha), Backstage Search is essential to enabling this discoverability — allowing new hires and old hands alike to explore your infrastructure instead of getting lost inside it.
|
||||
|
||||
We also quickly realized that search looks different from organization to organization. Therefore, we built a search platform that lets you plug in your own search engine, index any information you like, or build a customized search page experience that fits your users’ needs.
|
||||
|
||||
Since finding what you are looking for in Backstage is critical for success, we started by identifying the needs and goals of search.
|
||||
|
||||
## Rethinking search, inside and out
|
||||
|
||||
Spotify’s internal version of Backstage has had some of the features of Backstage Search for a while, and open sourcing them has been top of mind since day one. But we didn’t want to just port our internal version to the open source version. We wanted to take the opportunity to apply what we’ve learned inside Spotify over the last year, address the needs we’ve observed in the community, and ultimately open source not just a search feature but a search platform. We started the process by looking at the [jobs to be done](https://hbr.org/2016/09/know-your-customers-jobs-to-be-done).
|
||||
|
||||
|
||||
_A high-level overview of the process, identifying all the jobs of search._
|
||||
|
||||
First, we looked at which jobs to be done belonged to the search plugin itself (e.g., “collect documents to index”) and which belonged to the other plugins (e.g., “format documents for indexing”), and then whether those jobs belonged to the frontend (“display results”) or the backend (“schedule indexing”).
|
||||
|
||||
Looking at all these various jobs, we defined four goals for the platform:
|
||||
|
||||
- **Flexibility:** Be search engine–agnostic
|
||||
- **Simplicity:** Make it easy for content owners to make their content searchable/discoverable
|
||||
- **Control:** Allow plugin developers to customize their search results components
|
||||
- **Reusability:** Offer reusable components/APIs that other devs can leverage
|
||||
|
||||
Beginning our journey this way — by identifying the jobs to be done first, then defining the product goals from there — we could make sure that the search platform addressed real needs and improved the search experience for both users and plugin developers.
|
||||
|
||||
This approach not only created a better search tool for the open source community, but for Spotify, as well. So, instead of just open sourcing our internal version of search, we ended up with an even better solution — one that we can all use and build on together, both inside and outside Spotify.
|
||||
|
||||
## Say hello to the Backstage Search platform
|
||||
|
||||
|
||||
|
||||
We are now happy and proud to announce our alpha version of the [Backstage Search Platform](https://backstage.io/docs/features/search/architecture), featuring:
|
||||
|
||||
- Bring your own search engine (Flexibility)
|
||||
- Collators for easily indexing content from plugins and other sources (Simplicity)
|
||||
- Composable search page experiences (Control, Reusability)
|
||||
- Customize the look and feel of each search result (Control, Reusability)
|
||||
|
||||
### Bring your own search engine
|
||||
|
||||
By introducing a Search Integration Layer, we have been able to keep the query translation of the search term and filters close to the search engine itself. This makes our search backend less focused on how a set of terms and filters should be translated to fit a certain search engine interface and more focused on querying and retrieving results as well as collecting results to index.
|
||||
|
||||
With the Search Integration Layer, your organization can bring your search engine of choice to Backstage — instead of relying on Backstage to support a specific search engine that might not fit the needs of your organization, either today or in the future.
|
||||
|
||||
But that doesn’t mean “batteries not included”. The current version of Backstage Search ships with Lunr support built-in — and support for ElasticSearch is not very far off. And we hope the number of supported search engines will continue to grow with the community’s help.
|
||||
|
||||
### Collators for easily indexing content from plugins and other sources
|
||||
|
||||
Since Backstage’s functionality comes from its plugins, we wanted the process of making plugin content searchable to be as frictionless as possible. Therefore we decided on a concept we call collators. Collators are responsible for collecting documents to index from a plugin. Your collators live inside your own plugin, but are registered in the Backstage app’s search backend.
|
||||
|
||||
Collators can also be used to index external sources, like Stack Overflow and Confluence. You can watch a demo of how easy it is to extend search with collators [here](https://youtu.be/Z78FFaObTfk?t=339).
|
||||
|
||||
### Composable search page experiences
|
||||
|
||||
Every engineering org has different needs — that is something we have definitely learned over the last year. Your software catalog might be set up differently than ours and therefore your needs for how search results look and how the search filters work will also differ.
|
||||
|
||||
That's why we have put effort into making your search page experience composable to your organization's needs. What do we mean by that? When you adopt Backstage and set up your app, you can set up — or, compose — your search page by using existing components or by creating your own custom ones.
|
||||
|
||||
### Customize the look and feel of each search result
|
||||
|
||||
A good example of the level of customization the platform allows is how list items are displayed in search results. A search result component can be a list, this list can consist of different list items (search results returned from the search engine) — but these list items could look different depending on what the search result returns in terms of its fields.
|
||||
|
||||
Let’s say that for an entity returned from the software catalog maybe the most important information to show is the name, while a result returned from the TechDocs plugin should maybe show the text content as the most important information. This can be customized by creating <CustomResultListItem /> components (like TechDocsResultListItem or CatalogResultListItem or whatever list item component you want) and configuring them in the app.
|
||||
|
||||
If there is no need to customize your search result list items, the <DefaultResultListItem /> component is there for you to reuse.
|
||||
|
||||
## Getting started with Backstage Search
|
||||
|
||||
We put together [a getting started guide](https://backstage.io/docs/features/search/getting-started) that provides two different ways to set up Backstage Search:
|
||||
|
||||
- Create a new app and get the most out of the search setup right out of the box, or
|
||||
- Add the new Backstage Search setup to your existing Backstage app.
|
||||
|
||||
Whichever situation you’re in, we have you covered.
|
||||
|
||||
## What’s next?
|
||||
|
||||
We’ve built the foundation for the Backstage Search platform, and we can't wait to see the exciting engines, collators, and components the community builds on the platform.
|
||||
|
||||
You can check out our [project roadmap](https://backstage.io/docs/features/search/#project-roadmap) in our search documentation or track the progress of our [Beta milestone](https://github.com/backstage/backstage/milestone/27) and [GA milestone](https://github.com/backstage/backstage/milestone/28).
|
||||
|
||||
For any questions, feedback or ideas about the Backstage Search platform, join us in the #search channel on [Discord](https://discord.gg/backstage-687207715902193673)!
|
||||
@@ -1,68 +0,0 @@
|
||||
---
|
||||
title: Software Templates is now in Beta
|
||||
author: Ben Lambert, Spotify
|
||||
authorURL: https://github.com/benjdlambert
|
||||
authorImageURL: https://avatars.githubusercontent.com/u/3645856?v=4
|
||||
---
|
||||
|
||||
|
||||
|
||||
**TLDR**; At a high level, Backstage performs three main jobs: [Create, Manage, and Explore](https://backstage.io/blog/2021/05/20/adopting-backstage#three-jobs-create-manage-explore). Throughout the year, we’ve been focussed on improving the stability and scalability of these areas while enhancing the feature sets based upon requests from the community. Software Templates — which enable push-button deployments with all your standards and best practices built-in — is our first feature-complete release candidate to graduate to beta. Read on to learn how this release improves template customization and flexibility, as well as performance.
|
||||
|
||||
<!--truncate-->
|
||||
|
||||
Let’s rewind a little bit, around a year in fact. Backstage had been open sourced, and we released our first version of Software Templates and our Scaffolder plugin.
|
||||
|
||||
In case you missed it, [Software Templates](https://backstage.io/blog/2020/08/05/announcing-backstage-software-templates) are part of the Create feature set, where you can set up Backstage to give your engineers the ability to spin up a new microservice, website, or any other software component with your organization’s best practices built-in, right from the start.
|
||||
|
||||
Back when we released the first version of these templates, with the `apiVersion` `backstage.io/v1alpha1`, they were a little restrictive in what they could do. The generated repository could only have one template source and it was restricted to only being [cookiecutter](https://github.com/cookiecutter/cookiecutter) templates. And it had to fit into the three stages of templating which was `Prepare`, `Template`, and `Publish`.
|
||||
|
||||
We [opened up for feedback](https://github.com/backstage/backstage/issues/2771) from the community knowing that this wasn’t going to be the final version, but something of a stepping stone to where we want to be in the future.
|
||||
|
||||
And now we come to today…
|
||||
|
||||
## Anddddd… Action(s)! 🎬
|
||||
|
||||
Following the removal of the previously deprecated `backstage.io/v1alpha1` templates, today we’re officially announcing the beta version of Software Templates, or `backstage.io/v1beta2`.
|
||||
|
||||
With it comes an entirely new architecture to the Software Templates functionality, and a load of new exciting features, which I’ll dig into a little deeper.
|
||||
|
||||
### Template actions
|
||||
|
||||
We’ve totally opened up the ability to compose your own workflows for each Template that you have registered in Software Templates. This means no restrictions on where your template skeleton is kept, and no restrictions on what your workflow should look like.
|
||||
|
||||
Template Actions are customizable JavaScript functions that allow you to extend the capabilities of the Software Templates by adding your own business logic or reusing some of our Built-In actions.
|
||||
|
||||
|
||||
|
||||
_An example of the new template syntax with steps and parameters_
|
||||
|
||||
The workflow for Software Templates are now step-based, and each Software Template can have a customizable amount of steps which will in turn call these new actions.
|
||||
|
||||
|
||||
|
||||
_An example of a Template with customizable steps_
|
||||
|
||||
These actions are very heavily inspired by GitHub Actions and GitHub Workflows, and we’ve given back a lot of control to the template authors so they can build the boilerplate and push the code however they want.
|
||||
|
||||
### Custom UI extensions
|
||||
|
||||
A large part of the Software Templates feature is the form that we use to collect user input which is then passed on to these new actions. Sometimes, it makes sense that Template Authors want to provide their own React components which can be rendered in the frontend to maybe do some more complex things like calling internal APIs to provide autocomplete.
|
||||
|
||||
This is now possible with the new `ScaffolderFieldExtensions`.
|
||||
|
||||
|
||||
|
||||
_An example of `ScaffolderFieldExtension` is the `OwnerPicker` component which can automatically add options and suggest typeahead with data from an async API request_
|
||||
|
||||
Template Authors can create their own components to provide data to the custom actions in any way you see fit, and even override our own built in ones too like the `RepoUrlPicker`.
|
||||
|
||||
### Horizontal scalability
|
||||
|
||||
The Scaffolder Service and Software Templates are now horizontally scalable, coordinating work between your deployed backend machines. This means now that the number of instances of the `@backstage/plugin-scaffolder-backend` plugin you have, is the same amount of jobs that you can have in parallel. This ensures that your tasks are handled quickly and reliably, while providing great feedback in the process.
|
||||
|
||||
## Try out the new templates
|
||||
|
||||
We’re still on the journey to making the Software Templates a great user experience for both authors and developers — but we’re not done yet, so watch this space for new exciting features to come!
|
||||
|
||||
In the meantime, make sure to visit the documentation for [building templates](https://backstage.io/docs/features/software-templates/adding-templates) or creating your own [custom actions](https://backstage.io/docs/features/software-templates/writing-custom-actions).
|
||||
@@ -1,64 +0,0 @@
|
||||
---
|
||||
title: The TechDocs Beta has landed
|
||||
author: Eric Peterson, Spotify
|
||||
authorURL: https://github.com/iamEAP
|
||||
authorImageURL: https://avatars.githubusercontent.com/u/3496491?v=4
|
||||
---
|
||||
|
||||
|
||||
|
||||
**TLDR:** Another beta has landed! We continue to focus on improving the stability and scalability of Backstage while enhancing its functionality. Thanks to focused efforts from the TechDocs core team and community, we're happy to say that TechDocs — [our docs-like-code solution](https://backstage.io/blog/2020/09/08/announcing-tech-docs) for all the software in your catalog — is now, after [Software Templates](https://backstage.io/blog/2021/07/26/software-templates-are-now-in-beta), the second core feature to graduate to beta.
|
||||
|
||||
<!--truncate-->
|
||||
|
||||
In addition to new features and improvements, we made numerous compatibility updates ahead of this feature release. You'll find support for a variety of CI systems, cloud storage solutions, and source control systems — so that TechDocs works for most orgs, right out of box. But there's much more to explore in this beta, thanks to contributions from the community.
|
||||
|
||||
When we set out to define what beta looked like, we combed through GitHub issues, Discord discussions, and other media to identify common pain points and challenges encountered by those around the world who consume and author TechDocs documentation in their organization's Backstage instance. Based on this research, we put together a user-focused milestone and got to work. For an issue-by-issue breakdown, check out the milestone [on GitHub](https://github.com/backstage/backstage/milestone/29?closed=1) — or, just read on to get the highlights.
|
||||
|
||||
## Real-time builds and feedback
|
||||
|
||||
|
||||
|
||||
TechDocs can be transformational once fully up and running (update your code and your docs with the same pull request!). But for first-time users and especially those unfamiliar with the MkDocs ecosystem upon which TechDocs is built, there are often many small, obtuse hurdles that can get in the way of success. Leading up to the beta release, we worked to surface and improve relevant errors and other details during the documentation generation process. Better still, all of this detail is now provided to users _in real-time_, as docs are generated and refreshed.
|
||||
|
||||
<p>🙌 Shout out to <a href="https://github.com/dhenneke">Dominik Henneke</a> for implementing the interactive experience.</p>
|
||||
|
||||
## Custom homepages: Make TechDocs yours
|
||||
|
||||
|
||||
|
||||
We strive to make it so that you can mold Backstage into the shape that best fits your organization. With this beta release, just as you can with the Catalog entities and [Search](https://backstage.io/blog/2021/06/24/announcing-backstage-search-platform#composable-search-page-experiences), you can now customize and compose your own TechDocs homepage. Use it to level up the front page of your Backstage documentation by highlighting golden documentation at your company, or use the new and improved (and Catalog-inspired) experience. Read more about [how to customize the TechDocs homepage](https://backstage.io/docs/features/techdocs/how-to-guides#how-to-customize-the-techdocs-home-page).
|
||||
|
||||
<p>🙏 Thanks to <a href="https://github.com/kuangp">Phil Kuang</a> for the improved default TechDocs home experience.</p>
|
||||
|
||||
## Simpler YAML annotations: What's in a ref?
|
||||
|
||||
|
||||
|
||||
We often forget that in order to enable TechDocs on a Catalog entity, documentation authors have to sprinkle a little ref annotation voodoo into their catalog-info.yaml file. The form of this magic — the `backstage.io/techdocs-ref` annotation — has evolved over TechDocs' life. But unless you're a real Backstage aficionado, the specifics of what the value meant and how to construct it could be somewhat of a mystery.
|
||||
|
||||
In the beta, we've simplified this annotation dramatically for documentation authors, aligning its value with TechDocs' docs-like-code philosophy itself. In the vast majority of cases, its value will simply be `dir:.` — which means this catalog entity contains documentation and the mkdocs.yml file describing this documentation lives in the current directory. We continue to support edge cases for [other techdocs-ref annotation values](https://backstage.io/docs/features/techdocs/how-to-guides#how-to-understand-techdocs-ref-annotation-values), as well.
|
||||
|
||||
<p>👏 Another round of applause for Dominik for driving this improvement through.</p>
|
||||
|
||||
## Everything neat and tidy
|
||||
|
||||
If you've ever twitched a little looking at the address bar as you navigated through your TechDocs, because the "C" in "Component" was capitalized, or cringed whilst perusing through your TechDocs storage bucket, only to see assets you definitely remember deleting from a documentation site cluttering up the place…twitch and cringe no more!
|
||||
|
||||
TechDocs base paths are now case-insensitive, stale files are automatically cleaned up by the TechDocs publishing process — and even though [I say _.yaml_ and you say _.yml_](https://open.spotify.com/track/6NDaYWg85ZnJ3Ae0WkILWh) — TechDocs will now happily accept either file extension for your MkDocs YAML file.
|
||||
|
||||
## What should I do to upgrade?
|
||||
|
||||
If you've been waiting for the beta to give TechDocs a shot, good news! You'll get all of the above, plus all of TechDocs' existing features, right out of the box. Newly created Backstage apps come ready-to-go. You'll know you're on beta if you're using the following versions:
|
||||
|
||||
- TechDocs Plugin version >= 0.11.0
|
||||
- TechDocs Backend Plugin version >= 0.10.0
|
||||
- TechDocs CLI version >= 0.7.0
|
||||
|
||||
If you're upgrading from a prior, alpha version of TechDocs, be aware that there are some breaking changes that you will need to account for. Most importantly:
|
||||
|
||||
- Be sure your app's instance of TechDocs is wired up to use the composability API. [See full routing instructions here](https://github.com/backstage/backstage/blob/master/packages/create-app/CHANGELOG.md#0338).
|
||||
- If you've configured TechDocs to publish generated content to a remote storage solution provider like AWS S3, Google Cloud Storage, or Azure Blob Storage, you will need to use the TechDocs CLI to migrate the contents of your storage bucket. [See full migration instructions here](https://backstage.io/docs/features/techdocs/how-to-guides#how-to-migrate-from-techdocs-alpha-to-beta).
|
||||
- In order to take advantage of the stale file deletion functionality, you may need to add some permissions to the account or role used by your TechDocs backend to publish contents to your storage provider. [See "Using Cloud Storage docs"](https://backstage.io/docs/features/techdocs/using-cloud-storage) for updated permissions recommendations.
|
||||
|
||||
Thanks again to the whole community for hitting this milestone with us! Catch us in [Discord](https://discord.gg/backstage-687207715902193673) or an [upcoming community session](https://github.com/backstage/community) if you have any questions.
|
||||
@@ -1,45 +0,0 @@
|
||||
---
|
||||
title: The Big 5-0
|
||||
author: Francesco Corti, Spotify
|
||||
authorURL: https://github.com/fcorti/
|
||||
authorImageURL: https://avatars.githubusercontent.com/u/6010860?v=4
|
||||
---
|
||||
|
||||
We’re excited to celebrate an important milestone for the Backstage community: 50+ [public adopters](https://github.com/backstage/backstage/blob/master/ADOPTERS.md)!
|
||||
|
||||
|
||||
|
||||
Before digging into why we believe this is so important, we want to send a huge “thank you” to all the Backstage adopters and contributors who have helped grow the Backstage community. First, to the publicly listed adopters as your visible support for the project excites others to learn more about Backstage. Second, to those non-listed adopters, many of whom still engage in the community via issues, comments, or code contributions. Thank you!
|
||||
|
||||
<!--truncate-->
|
||||
|
||||
## Why we care about public adopters
|
||||
|
||||
|
||||
|
||||
If you roll the clock back to early 2020 when Backstage was open sourced, we never could’ve imagined surpassing this milestone. It feels particularly big given that Backstage tends to be adopted by complex organizations with hundreds (if not thousands of) developers and thousands (if not tens of thousands) of software components.
|
||||
|
||||
We’ve also seen such diverse examples of Backstage in the wild. Adopters as varied as [American Airlines][am] and [Splunk][sp] have demoed their Backstage-built developer portals. We’ve seen digital-first companies like [Zalando][za] and [DAZN][da] share their journey from proof-of-concept to in-production. And the developer experience team at [Expedia Group][ex] has been shared at multiple Community Sessions, detailing their adoption journey as well as contributing back with ideas for new features.
|
||||
|
||||
For the Backstage project, public adopters are important because they provide a wide variety of use cases, industries, and degrees of complexity (teams, number of services, etc.) that Backstage is able to support. In addition, a growing adopters list shows the project’s maturity and helps other organizations understand the benefits and make the decision to join the project and the community.
|
||||
|
||||
In other words, the more the public adopters list grows and becomes more diverse, the more the community will grow and provide contributions that benefit all adopters.
|
||||
|
||||
## Fifty is just the beginning
|
||||
|
||||
|
||||
|
||||
While we’re thrilled to celebrate this milestone, the public adopters list is just one metric we monitor in the overall health of the Backstage project. It definitely doesn’t tell the whole story! We’re seeing continued growth within the contributor community, PRs, and GitHub overall ratings as well. As fate would have it, we also recently reached 50+ plugins in the [Backstage Plugin Marketplace][plugins]!
|
||||
|
||||
## Join us!
|
||||
|
||||
If you are a Backstage enthusiast, please [join me][news] and the entire Backstage Team in celebrating this milestone. And if you are a Backstage adopter not already listed in the [GitHub page][gh], consider adding your name to better inform the community and participate in the project.
|
||||
|
||||
[am]: https://backstage.spotify.com/blog/adopter-spotlight/american-airlines-runway/
|
||||
[sp]: https://backstage.spotify.com/blog/community-session/splunk-pink-phonebook/
|
||||
[za]: https://youtu.be/6sg5uMCLxTA
|
||||
[da]: https://medium.com/dazn-tech/developer-experience-dx-at-dazn-e6de9a0208d2
|
||||
[ex]: https://backstage.spotify.com/blog/community-session/firehydrant-expedia-loblaw/
|
||||
[plugins]: https://backstage.io/plugins
|
||||
[news]: https://info.backstage.spotify.com/newsletter_subscribe
|
||||
[gh]: https://github.com/backstage/backstage/blob/master/ADOPTERS.md
|
||||
@@ -1,145 +0,0 @@
|
||||
---
|
||||
title: Backstage Wrapped 2021
|
||||
author: Lee Mills, Spotify
|
||||
authorURL: https://github.com/leemills83
|
||||
authorImageURL: https://avatars1.githubusercontent.com/u/1236238?s=460&v=4
|
||||
---
|
||||
|
||||
|
||||
|
||||
What a year 2021 has been for the Backstage project and community. As the year comes to a close, we can look back at some of the happenings, the successes, and welcome all the newcomers to our growing community.
|
||||
|
||||
In a year that has had its fair share of ups and downs, this community has been something that has brought me so much in the support you provide each other, your eagerness, passion, and willingness to share. Thank you to all of you for creating such a great community, and welcome to everyone joining us. I can’t wait to meet you all and see what great things we can create together in the new year.
|
||||
|
||||
In 2021 we’ve seen the project and community grow in every dimension, reaching over 75 public adopters, over 500 contributors from around the world all bringing new ideas and perspectives. We’ve had so many of you sharing and demoing your hard work in our monthly community sessions, added new plugins, built new features and really started to see Backstage have an impact for engineering teams across so many of our users.
|
||||
|
||||
Now let’s hear from the maintainers and look at the stats!
|
||||
|
||||
<!--truncate-->
|
||||
|
||||
## The community grew…and grew
|
||||
|
||||
This year, Netflix, [Expedia][metrics], Wayfair, Peloton, [Box][10], [DAZN][dazn], TELUS, and Unity all officially joined the community — along with more than 50 other public [adopters][md]. Contributors grew by leaps and bounds, too.
|
||||
|
||||
Patrik Oldsberg ([@Rugvip][rugvip]):
|
||||
|
||||
> It’s been awesome to see the engagement by the community grow even more in 2021, especially the way people within the community support each other. Thanks to our growing number of stable, experienced, and knowledgeable contributors it’s now possible to get help in places like Discord anytime, day or night.
|
||||
|
||||
### More adopters, more contributors
|
||||
|
||||
|
||||
|
||||
In January, Backstage had 17 public adopters. By September, [we had 50][50]. And the curve only got steeper from there.
|
||||
|
||||
- **75+ public adopters**
|
||||
- **500+ contributors**
|
||||
- **4,000+ Discord members**
|
||||
- **9,000+ PRs & issues**
|
||||
|
||||
### A very busy repo
|
||||
|
||||
Along with the growth in contributors, PRs, and issues, our active, thriving community has crossed (or is just about to cross) other big milestones on GitHub, too.
|
||||
|
||||
- **Nearly 2,000 forks**
|
||||
- **20,000+ commits**
|
||||
- **14,000+ GitHub stars**
|
||||
|
||||
### Where in the world is the Backstage community?
|
||||
|
||||
Watch the visualization below to see where in the world all those contributions came from this past year.
|
||||
|
||||
<iframe width="780" height="440" src="https://www.youtube.com/embed/O1xtDv_XDt4" frameBorder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowFullScreen></iframe>
|
||||
|
||||
### What does 9,000 contributions look like?
|
||||
|
||||
<iframe width="780" height="440" src="https://www.youtube.com/embed/bCqhoK7it2g" frameBorder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowFullScreen></iframe>
|
||||
|
||||
Can you spot your name in the video above?
|
||||
|
||||
Picking up from the end of 2020, the video shows every single contribution to the Backstage source code over this past year. The visualization was built using [Gource.io][gource]:
|
||||
|
||||
> Software projects are displayed by Gource as an animated tree with the root directory of the project at its centre. Directories appear as branches with files as leaves. Developers can be seen working on the tree at the times they contributed to the project.
|
||||
|
||||
And if your name isn’t in there, it’s never too late to get started [contributing][contributing] — so that you too can become a bright, sparkling, laser-beam-shooting spider-node thing in 2022!
|
||||
|
||||
## Other 2021 milestones
|
||||
|
||||
As the community grew, so did the product — with the addition of new features as well as important performance and stability improvements to the core.
|
||||
|
||||
Ben Lambert ([@benjdlambert][blam]):
|
||||
|
||||
> We’ve had a lot of priorities this year. Our first priority was rebuilding the catalog to make it more efficient. Then, toward the later part of the year, we’ve been stabilizing the core with deprecations and API changes ahead of our 1.0 release of the Core Framework next year.
|
||||
>
|
||||
> It’s been a super productive year for us all as Core Maintainers, and the product has come on leaps and bounds with the help of everyone involved in the project!
|
||||
|
||||
### New features
|
||||
|
||||
These new features were built with the community, and made with customization and extensibility in mind.
|
||||
|
||||
- **Kubernetes Service Monitoring ([RFC][k8s])**
|
||||
- **Search Platform ([Alpha][search])**
|
||||
- **Composable Homepage ([README][home])**
|
||||
- **Authorization Framework ([RFC][auth])**
|
||||
|
||||
### Major stability updates
|
||||
|
||||
As we get the ball rolling for [CNCF Incubation][cncf], we’ve been busy updating, refining, documenting, deprecating, and stabilizing the core.
|
||||
|
||||
- **Software Templates ([Beta][scaffolder])**
|
||||
- **TechDocs ([Beta][techdocs])**
|
||||
- **API Reference ([docs][api])**
|
||||
|
||||
### 50+ open source plugins
|
||||
|
||||
We reached [50+ plugins][plugins] built by the community this year, including official plugins (**Snyk**, **FireHydrant**), highly requested plugins (**PagerDuty**, **Prometheus**), and plugins based on new ideas and functionality (**XCMetrics**, **[Tech Insights][techrfc]**) — all tailor-made for Backstage.
|
||||
|
||||
### In the spotlight
|
||||
|
||||
This year Backstage was center stage at both community-organized events and at major conferences.
|
||||
|
||||
- **New (and [expanded][09]) Community Sessions**
|
||||
- **Backstage Users Unconference + [Open Mic][openmic]**
|
||||
- **KubeCon + CloudNativeCon [Europe][europe] & [North America][na]**
|
||||
- **GitHub Universe 2021 [Keynote][day2]**
|
||||
|
||||
Find more talks, podcasts, blog posts, and Backstage in the news [here][news].
|
||||
|
||||
## Goodbye, 2021. Hello, 2022!
|
||||
|
||||
Lastly, thanks to everyone in the global Backstage community who contributed to the open source project in 2021.
|
||||
|
||||
This was the first year Spotify hosted [Backstage Community Sessions][meetups], and it’s been a great source of inspiration, motivation, and joy getting to know all the people behind the contributions. We look forward to seeing all your faces again in 2022 — and hopefully many new ones as well.
|
||||
|
||||
Until then, [grab this Backstage Zoom background][zoom] to use at the next Community Session.
|
||||
|
||||
|
||||
|
||||
See you then! Happy holidays from everyone on the Backstage team at Spotify!
|
||||
|
||||
[metrics]: https://backstage.spotify.com/blog/measuring-backstage-proof-of-value-at-expedia/
|
||||
[10]: https://backstage.spotify.com/blog/community-session/10-box-and-spotify-paid-plugins/
|
||||
[dazn]: https://backstage.spotify.com/blog/adopter-spotlight/dazn/
|
||||
[md]: https://github.com/backstage/backstage/blob/master/ADOPTERS.md
|
||||
[rugvip]: https://github.com/Rugvip
|
||||
[50]: https://backstage.io/blog/2021/09/30/50-public-adopters
|
||||
[gource]: https://gource.io
|
||||
[contributing]: https://github.com/backstage/backstage/blob/master/CONTRIBUTING.md
|
||||
[blam]: https://github.com/benjdlambert
|
||||
[k8s]: https://github.com/backstage/backstage/issues/2857
|
||||
[search]: https://backstage.io/blog/2021/06/24/announcing-backstage-search-platform
|
||||
[home]: https://github.com/backstage/backstage/blob/master/plugins/home/README.md
|
||||
[auth]: https://backstage.spotify.com/blog/authorization-framework-rfc/
|
||||
[scaffolder]: https://backstage.io/blog/2021/07/26/software-templates-are-now-in-beta
|
||||
[techdocs]: https://backstage.io/blog/2021/09/16/the-techdocs-beta-has-landed
|
||||
[api]: https://backstage.io/docs/reference/
|
||||
[cncf]: https://github.com/cncf/toc/pull/717
|
||||
[plugins]: https://backstage.io/plugins
|
||||
[techrfc]: https://github.com/backstage/backstage/issues/7576
|
||||
[09]: https://backstage.spotify.com/blog/community-session/09-prometheus-homepage-templates/
|
||||
[openmic]: https://backstage-openmic.com
|
||||
[europe]: https://www.youtube.com/watch?v=aIURaocR5D8
|
||||
[na]: https://backstage.spotify.com/blog/kubecon-na-2021/
|
||||
[day2]: https://www.youtube.com/watch?v=7yQJlYvpoYs&t=269s
|
||||
[news]: https://github.com/backstage/community#newsletters
|
||||
[meetups]: https://github.com/backstage/community#meetups
|
||||
[zoom]: https://drive.google.com/file/d/14wOPXEBZ5Qmi29ms4Sqp1m56dM0AIHbB/view?usp=sharing
|
||||
@@ -1,47 +0,0 @@
|
||||
---
|
||||
title: Say Hi to Backstage homepage templates!
|
||||
author: Kat Zhou, Spotify
|
||||
authorURL: https://github.com/KatherineZhou
|
||||
authorImageURL: https://avatars.githubusercontent.com/u/16808998?v=4
|
||||
---
|
||||
|
||||
_This blog post is co-authored by Emma Indal ([@emmaindal](https://github.com/emmaindal)), Spotify._
|
||||
|
||||
|
||||
|
||||
_TLDR;_ We’re excited to announce the arrival of homepage templates for Backstage. It can be intimidating to build up your own instance of Backstage, so we decided to make your life a bit easier by giving you an out-of-the-box homepage to hit the ground running. This template can be found in our [Backstage Storybook](https://backstage.io/storybook/?path=/story/plugins-home-templates--default-template), as well as future templates that we build.
|
||||
|
||||
<!--truncate-->
|
||||
|
||||
## Why homepage templates?
|
||||
|
||||
At Spotify, the Backstage homepage is one of the most commonly used pages, primarily leveraged to quickly find and easily access things. Most of our users start off their Backstage experience on the homepage to quickly pivot to their intended destination. For example, folks generally prefer having a search bar available for quickly finding what they are looking for. Backstage users at Spotify also prefer having a central toolkit for navigating to tools that exist within the organization and for accessing their favorite entities and documentation pages.
|
||||
|
||||
|
||||
|
||||
But we also know that all organizations look different and have different needs. Backstage is designed with this in mind, and so is the homepage plugin. You can modify and customize your version of the Home plugin so it fits with your needs. Sometimes customizing and configuring your app can be overwhelming to get started, with the [homepage templates](https://backstage.io/storybook/?path=/story/plugins-home-templates--default-template) and components we can provide recommendations and guidelines to make adoption of Backstage more streamlined and simplified.
|
||||
|
||||
## What are homepage templates?
|
||||
|
||||
A homepage template is just a template of what a homepage can look like. You can either copy it as a whole, or pick different components from it to use. The homepage templates live in our [Backstage Storybook](https://backstage.io/storybook/?path=/story/plugins-home-templates--default-template) and we hope to see this collection grow with contributions from you all. If you don’t want to use one of the templates, you can pick and choose from our collection of [homepage components](https://backstage.io/storybook/?path=/story/plugins-home-components) that you can use right out of the box and compose your own homepage. We’ve included the [SearchBar](https://backstage.io/storybook/?path=/story/plugins-home-components-searchbar--custom-styles), [CompanyLogo](https://backstage.io/storybook/?path=/story/plugins-home-components-companylogo--custom-logo) and [Toolkit](https://backstage.io/storybook/?path=/story/plugins-home-components-toolkit--default) components in our Backstage Storybook as of today. In the future, we plan on open sourcing the widely popular QuickAccess card, which includes Favorites, Frequently Visited, and Recently Visited options.
|
||||
|
||||
|
||||
_Composed homepage for the app using the default homepage template_
|
||||
|
||||
|
||||
_Example of the default homepage template in Backstage Storybook_
|
||||
|
||||
## How to get started
|
||||
|
||||
To get started, you first need to set up your homepage plugin in the app if you have not already, then you can move on to composing your homepage. You can find our step-by-step documentation of how to do this under the [App Configuration - Customize the look-and-feel of your App documentation](https://backstage.io/docs/getting-started/homepage). You can also access the [Backstage UI Kit in Figma](https://www.figma.com/file/nUaAw56hTgC0RIOYkuLSrB/Backstage-Design-System?node-id=2185%3A2978) to duplicate your own version and play around with a fitting homepage for your own organization.
|
||||
|
||||
|
||||
_Example of the homepage components in the Backstage UI Kit in Figma_
|
||||
|
||||
## What’s next?
|
||||
|
||||
Some future templates that we have in mind are more dashboard-esque ones that display a variety of relevant data for your organization. We will also open source more homepage components such as [Starred Entities](https://github.com/backstage/backstage/issues/6906) that you can use when you are composing your components.
|
||||
|
||||
## How to contribute
|
||||
|
||||
As mentioned above, we would love to build out these collections of both homepage components and homepage templates, so if you would like to contribute, please check out our [contribution documentation](https://github.com/backstage/backstage/blob/master/plugins/home/README.md#contributing) to get started.
|
||||
@@ -1,56 +0,0 @@
|
||||
---
|
||||
title: Avoid upgrade surprises with Backstage Upgrade Helper
|
||||
author: Vincenzo Scamporlino, Spotify
|
||||
authorURL: https://github.com/vinzscam
|
||||
authorImageURL: https://avatars.githubusercontent.com/u/8433119?v=4
|
||||
---
|
||||
|
||||
|
||||
|
||||
_TLDR;_ The Spotify team recently announced [Backstage Upgrade Helper](https://backstage.github.io/upgrade-helper): a tool that helps adopters keep their Backstage application up-to-date. **Spoiler alert**: this is also a hidden and heartwarming tale about the beauty of open source innovation.
|
||||
|
||||
<!--truncate-->
|
||||
|
||||
## Upgrading Backstage was a common pain point
|
||||
|
||||
Without a doubt, one of the most exciting things about Backstage is our community. Step into our daily [Discord conversations](https://discord.gg/backstage-687207715902193673) and the monthly [Community Sessions](https://www.youtube.com/watch?v=0QMQYSTKAx0) and you’ll find a ton of great ideas, problem-solving, and support for one another.
|
||||
|
||||
During one of these discussions, we realized we all shared the same pain point — upgrading a Backstage application.
|
||||
|
||||
The Backstage open source project is in hyper-growth mode, where dozens of pull requests are merged each day. This means adopters need to go through the upgrade process more often in order to get the latest and greatest features. The Spotify team heard a lot of feedback about how painful and manual this process was — so we decided to tackle this problem during one of our internal Hack Days.
|
||||
|
||||
At Spotify, we run Hack Days every month and a lot of ideas come from those sessions (in fact, the idea to open source Backstage itself [was born on a Hack Day](https://open.spotify.com/episode/332yTwGiILGKTS7dsHCj2P)!). During a brainstorming session, we noticed that another open source community faced a similar upgrading problem years back and came up with a really good solution.
|
||||
|
||||
If you have ever worked on a React Native project, you might immediately recognize what we are referring to: The [React Native Upgrade Helper](https://github.com/react-native-community/upgrade-helper) — a web tool to support React Native developers in upgrading their apps — might have saved hours of your time. It certainly saved us hours of ours. So we looked into the project details and discovered it could fulfill our Backstage needs.
|
||||
|
||||
We started by creating a fork from React Native’s open source project, applying a few changes on top of it to introduce Backstage support, and — _ecco_ — we had a new Backstage Upgrade Helper! In just a few days with pretty minimal effort, we created a product that would save a lot of time for the entire Backstage community. And we had fun at the same time (happy developers make happy code 😁 ).
|
||||
|
||||
## So what is Backstage Upgrade Helper?
|
||||
|
||||
The Backstage Upgrade Helper tool enables adopters to easily upgrade their Backstage app by using the power of git to create a diff between different versions.
|
||||
|
||||
Whenever a new version of Backstage is released, the Helper scaffolds a new sample Backstage app using the `backstage-create-app` cli utility and checks all the generated files in a specific git branch. After the branch is generated, it gets compared with all the existing ones, which results in generating specific git patches stored in specific files. By selecting the version of the current Backstage release together with the version you want to upgrade to, the UI knows which patch file needs to be picked up.
|
||||
|
||||
So, now you can update your Backstage application in three steps rather than manually reading the changelogs of all the Backstage modules in reverse order.
|
||||
|
||||
### To use the Upgrade Helper, follow these simple steps
|
||||
|
||||
1. Go to the [Backstage Upgrade Helper](https://backstage.github.io/upgrade-helper) and enter your current release and the release you would like to upgrade to.
|
||||
|
||||
2. Press **Show me how to upgrade!** After that, the feature spits out the changes between the two Backstage versions in a split-screen view for easy comparison.
|
||||
|
||||
|
||||
|
||||
3. Apply the suggested changes to your source code to correctly upgrade your app to the selected Backstage version. This will let you directly migrate from the version you’re currently using to the target version and skip all the intermediate steps you would have otherwise gone through manually reading all the changelogs.
|
||||
|
||||
[Watch the Upgrade Helper demo](https://youtu.be/nYjI2j-lWEM?t=410).
|
||||
|
||||
## Open source inspires
|
||||
|
||||
Thus far, the Backstage Upgrade Helper has gotten a lot of good feedback from the community and we’re sure to see awesome contributions in the future. But all the credit behind this idea goes to the React Native community.
|
||||
|
||||
With React Native’s open source contributions, we were able to quickly solve a tough problem for the entire Backstage community. Not only did React Native’s project save us time creating a new product, but it has also saved our adopters time upgrading Backstage.
|
||||
|
||||
This is why we love working in open source. The hard work done for one community has the power to influence and inspire another community. We hope Backstage can do the same and pay it forward to other open source projects.
|
||||
|
||||
For more Backstage Upgrade Helper resources, check out the [UI code](https://github.com/backstage/upgrade-helper) and the [git patches](https://github.com/backstage/upgrade-helper-diff).
|
||||
@@ -1,68 +0,0 @@
|
||||
---
|
||||
title: Backstage Turns Two!
|
||||
author: Lee Mills, Spotify
|
||||
authorURL: https://github.com/leemills83
|
||||
authorImageURL: https://avatars1.githubusercontent.com/u/1236238?s=460&v=4
|
||||
---
|
||||
|
||||
|
||||
|
||||
**TLDR:** Backstage has turned two. Of course, this is software, so we expect things to move fast. But when you have a passionate, worldwide community building together, we’ve now seen firsthand just how fast that can be. We’re marking our second year as a community by becoming a CNCF incubating project, reaching 100 public adopters, releasing version 1.0 of the core app, and other very nice birthday gifts. Rather than a toddler finding their feet, Backstage today is beginning to look awfully grown-up for a two-year-old.
|
||||
|
||||
<!--truncate-->
|
||||
|
||||
## Out of the Sandbox and into Incubation
|
||||
|
||||
Two years ago, a small team at Spotify launched Backstage into open source during our internal Hack Week. We knew we had something special on our hands and that Backstage could potentially be the most ambitious open source project in Spotify’s history (you can listen to me wax philosophical on this topic more in [Episode 2 of the new NerdOut@Spotify podcast](https://open.spotify.com/episode/332yTwGiILGKTS7dsHCj2P?si=pX9xTzB2SgmsROdlLLr24A).)
|
||||
|
||||
When Spotify donated the project to the CNCF, we saw it as the first promising step toward making Backstage an industry standard. As the home to Kubernetes, Envoy, and so many other game-changing open technologies, the CNCF and its community has had a wide-ranging impact on the daily lives of developers everywhere. And that’s what we hoped for Backstage, even back then.
|
||||
|
||||
But we couldn't have envisioned where we’d be two years later — part of an ever-growing community of people that feel as passionate as we do about unlocking better developer experience for every engineering organization.
|
||||
|
||||
Yesterday, the CNCF announced that its [Technical Oversight Committee](https://github.com/cncf/toc) (TOC) voted to accept Backstage as a [CNCF incubating project](https://www.cncf.io/blog/2022/03/15/backstage-project-joins-the-cncf-incubator/). The move from the CNCF Sandbox to Incubation is an important step forward for the project’s technical governance.
|
||||
|
||||
It’s also recognition for all the work the Backstage open source community has done to advance and grow this project since we launched the repo on GitHub just a few weeks after that Hack Week. We still have a long way to go to becoming the standard, but moving out of the CNCF Sandbox and beginning the Incubation phase is further validation of those aspirations.
|
||||
|
||||
## What do retailers, gaming studios, banks, airlines, streamers, startups, and enterprise software makers all have in common?
|
||||
|
||||
Developers, developers, developers — that’s what all companies have in common. Developers dealing with [more complexity](https://youtu.be/85TQEpNCaU0) than they’ve ever had to deal with before. Developers who want to be able to go from idea to bug fix or feature faster.
|
||||
|
||||
Two years in, the Backstage ecosystem has grown by leaps and bounds. More than 5,000 contributors have joined the project and are submitting bugs, adding new features, and building valuable plugins that benefit the greater community. From [Expedia Group](https://backstage.spotify.com/blog/measuring-backstage-proof-of-value-at-expedia/) (adopter No.18) to Unity (adopter No.67), Backstage now has [100 publicly listed adopters](https://github.com/backstage/backstage/blob/master/ADOPTERS.md) across a variety of industries, including retail, gaming, financial services, manufacturing, and government.
|
||||
|
||||
We have companies like [Roadie](http://roadie.io) providing hosting solutions and ThoughtWorks [providing technology and consulting services](https://www.thoughtworks.com/en-us/about-us/news/2021/thoughtworks-is-collaborating-with-spotify-to-deliver-better-dev) to teams looking to stand up Backstage in their own orgs. We’re starting to see more and more job listings for Backstage developers which tells us that companies of all shapes and sizes are going all-in on Backstage and developer effectiveness.
|
||||
|
||||
Also, I’ll pause now to give a special shoutout to our early adopters. They stuck with us through all the bumps and breaking changes. But because of their early commitment, we now see instances of Backstage up and running in so many different kinds of engineering organizations. From [Zalando](https://youtu.be/6sg5uMCLxTA) to [American Airlines](https://backstage.spotify.com/blog/adopter-spotlight/american-airlines-runway/) and [Brex](https://backstage.spotify.com/blog/community-session/11-brex-backstage-upgrade-helper/), the growing pains of our earliest adopters helped pave the way for smoother adoptions for all who follow them.
|
||||
|
||||
A few more numbers that make us proud:
|
||||
|
||||
- 2,000+ project forks
|
||||
- 20,000+ commits
|
||||
- 10,000+ PRs & issues
|
||||
- 15,000+ stars on GitHub
|
||||
- 60+ open source plugins in the [Backstage Plugin Marketplace](https://backstage.io/plugins)
|
||||
|
||||
## A global community of friendly, helpful contributors
|
||||
|
||||
We open sourced Backstage in March 2020 and then almost immediately went into lockdown. When you think about this project in the context of the pandemic, it's really remarkable how much this community has been able to achieve.
|
||||
|
||||
The Backstage community is truly global with adopters and contributors from almost every continent (sorry, Antarctica!) coming together to share what they’ve worked on and demo cool stuff in our monthly Community Sessions. The repo and the Discord server truly never sleep as a growing group of dedicated Backstage experts outside Spotify support one another and offer help 24/7.
|
||||
|
||||
We asked a few contributors and maintainers to share their thoughts around this two-year milestone.
|
||||
|
||||
<iframe width="780" height="440" src="https://www.youtube.com/embed/-j-waaybcH0" frameBorder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowFullScreen></iframe>
|
||||
|
||||
Warms the heart, doesn’t it? Thanks again to all our contributors for making this possible. Seriously. We’re proud of what the community has accomplished and how we’ve accomplished it. All along, it’s your enthusiasm and warm/collaborative/positive vibes that have carried us and this project through.
|
||||
|
||||
## Version 1.0 and beyond
|
||||
|
||||
Tomorrow, we’ll be releasing version 1.0 of the Backstage core framework, including Software Catalog, Software Templates, TechDocs, and API Reference. With Backstage 1.0, the project’s core components are coming out of beta and into production with regular versioning and release cycle commitments (check back on this blog for more details!).
|
||||
|
||||
v1.0 paves the way for more adoption, a bigger community, more contributions — and with this continued growth in the ecosystem, we expect even greater innovation on the platform just on the horizon with exchange of features and plugins.
|
||||
|
||||
What comes next for Backstage is — in many ways — entirely up to you. We are looking to this community to [help us shape the next year](https://backstage.io/docs/overview/roadmap).
|
||||
|
||||
If you’re already a part of this community, thank you for your hard work and dedication. Backstage wouldn’t be where it is today without you. We’ve come a long way together, but there’s still so much to do.
|
||||
|
||||
And if you haven’t signed up yet, there’s plenty of room on this party boat! And there’s never been a better time to hop on board. As Irma ([@Irma12](https://github.com/Irma12)) said so beautifully: where else is there an opportunity to have so many people look at your code, hear you out, and help you out?
|
||||
|
||||
Take a look at how to [start contributing](https://github.com/backstage/backstage/blob/master/CONTRIBUTING.md) and [join the community](https://github.com/backstage/community)!
|
||||
@@ -1,59 +0,0 @@
|
||||
---
|
||||
# prettier-ignore
|
||||
title: "New release: Backstage 1.0"
|
||||
author: Francesco Corti, Spotify
|
||||
authorURL: https://github.com/fcorti/
|
||||
authorImageURL: https://avatars.githubusercontent.com/u/6010860?v=4
|
||||
---
|
||||
|
||||
|
||||
|
||||
_TL;DR:_ If you’ve been waiting for Backstage to come out of beta, we’re excited to announce that Backstage 1.0 is here!
|
||||
|
||||
<!--truncate-->
|
||||
|
||||
It’s been two years since Spotify [open sourced Backstage](https://backstage.io/blog/2020/03/16/announcing-backstage) so companies of all shapes and sizes — and in every industry all over the world — could build highly extensible and customized developer portals to best suit their organization’s needs and culture. Now hundreds of adopters are using Backstage as the single pane of glass for their core development, managing millions of components and technical documentation, and helping hundreds of thousands of developers be more productive and happy.
|
||||
|
||||
This milestone demonstrates Backstage’s maturity and the incredible effort from the core maintainers, contributors, and adopters. In a short time, we’ve seen a global community grow rapidly with people bringing their passion to this project and our goal of empowering developers. Because, yes, this is also your goal and your time to celebrate.
|
||||
|
||||
# So what is Backstage 1.0?
|
||||
|
||||
If you’re thinking “what is Backstage 1.0, and what does it include?” You’re not alone, so let’s get into it.
|
||||
|
||||
To start, let’s define Backstage: it’s an open platform for building developer portals, mainly defined by a set of libraries together with plugins that can be added, removed, or customized so that the final behavior of the developer portal product is what an adopter wants. For the past two years, the open source platform has been in beta. With Backstage 1.0, we're coming out of beta and into production with regular versioning and release cycle commitments. So, if your company requires production-ready software, you can now use Backstage and join [over 100 other public adopters](https://github.com/backstage/backstage/blob/master/ADOPTERS.md)!
|
||||
|
||||
Our definition of Backstage 1.0 includes:
|
||||
|
||||
- Backstage Core 1.0 libraries as the set of libraries to make the platform work
|
||||
- [Backstage Software Catalog](https://backstage.io/docs/features/software-catalog/) 1.0
|
||||
- [Backstage Software Templates](https://backstage.io/docs/features/software-templates/) 1.0
|
||||
- [Backstage TechDocs](https://backstage.io/docs/features/techdocs/) 1.0
|
||||
|
||||
Coming soon: [Backstage Search](https://backstage.io/docs/features/search/) 1.0 will be included in the near future as part of the regular releases to the Backstage platform.
|
||||
|
||||
In terms of features, the maintainers will not be shipping new stuff as part of the major release but instead:
|
||||
|
||||
- Refactoring the code packaging to better reflect the release numbering
|
||||
- Removal of deprecated services to reduce the risk of introducing breaking changes
|
||||
- Establishing clarity on the release lifecycle, numbering, and cadence as well as the support model
|
||||
- Improvements to Backstage.io documentation
|
||||
|
||||
# The road ahead
|
||||
|
||||
In terms of maturity and stability, the road ahead for Backstage is bright and busy. The goal is to bring Backstage to the next level of maturity and continue improving it, according to adopter growth, feature set, and identified use cases.
|
||||
|
||||
You can read more about Backstage’s roadmap [here](https://backstage.io/docs/overview/roadmap), but in terms of maturity and stability we would like to highlight the following:
|
||||
|
||||
- CNCF incubation: The Backstage project [recently moved from Sandbox to Incubation](https://www.cncf.io/blog/2022/03/15/backstage-project-joins-the-cncf-incubator/) phase within the [CNCF maturity levels](https://www.cncf.io/projects/#:~:text=Maturity%20levels,should%20be%20adopting%20different%20projects.).
|
||||
- Security auditing and strategy: With the CNCF’s support, the project maintainers are working on a security audit initiative to make the platform more secure and will share more details soon. The audit is part of an overall security strategy being developed this quarter.
|
||||
- Paid plugins for advanced and enterprise use cases: Last year, [Spotify announced its work on paid plugins](https://backstage.spotify.com/blog/paid-plugins-announcement/) built on top of the Backstage open source platform. This is another example of the platform’s maturity and Spotify’s continued commitment to the project, with a focus on customers and use cases requiring enterprise-focused support and plugins developed and proven by Spotify.
|
||||
|
||||
# Some links to peruse
|
||||
|
||||
If you want to know more about this first major release, check out the following links to learn more about this release effort and receive support.
|
||||
|
||||
- [Release notes](https://backstage.io/docs/releases/v1.0.0) and [Changelog](https://github.com/backstage/backstage/releases/tag/v1.0.0).
|
||||
- [Backstage official documentation](https://backstage.io/docs/) and [backstage.spotify.com](https://backstage.spotify.com/).
|
||||
- [Discord channel](https://discord.gg/backstage-687207715902193673).
|
||||
- [Backstage repository on GitHub](https://github.com/backstage/backstage).
|
||||
- [List of public adopters](https://github.com/backstage/backstage/blob/master/ADOPTERS.md).
|
||||
@@ -1,49 +0,0 @@
|
||||
---
|
||||
# prettier-ignore
|
||||
title: "Introducing the TechDocs Addon Framework"
|
||||
author: Gary Niemen, Spotify
|
||||
authorURL: https://github.com/garyniemen/
|
||||
authorImageURL: https://avatars.githubusercontent.com/u/65337273?v=4
|
||||
---
|
||||
|
||||
_This blog post is co-authored by Eric Peterson ([@iamEAP](https://github.com/iamEAP)), Spotify._
|
||||
|
||||
|
||||
|
||||
_TL;DR:_ Introducing the TechDocs Addon Framework — a way for us all to contribute and share additional features, TechDocs Addons, on top of the base docs-like-code experience.
|
||||
|
||||
<!--truncate-->
|
||||
|
||||
[TechDocs](https://backstage.io/docs/features/techdocs/) is a centralized platform for publishing, viewing, and discovering technical documentation across an entire organization. It's a solid foundation! But TechDocs doesn't solve higher order documentation needs on its own such as: How do you create and reinforce a culture of documentation? How do you build trust in the quality of technical documentation?
|
||||
|
||||
To address this need, we’re proud to introduce the [TechDocs Addon Framework](https://github.com/backstage/backstage/issues/9636) — a way for us all to contribute and share additional features, TechDocs Addons, on top of the base docs-like-code experience. Using TechDocs Addons, you can customize the TechDocs experience to address some of these higher order needs.
|
||||
|
||||
# Open source Addons from Spotify
|
||||
|
||||
We plan to open source many of the TechDocs Addons that we use at Spotify. The first Addon we open sourced is ReportIssue, which you can start using today. ReportIssue enables you to highlight text on a page and quickly raise a templated issue for that text, in your version control system (currently supports GitHub and GitLab). The following images depict this Addon in practice.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Other Addons coming soon include a Stack Overflow card to surface relevant questions and answers and an Issue Counter.
|
||||
|
||||
|
||||
|
||||
We encourage you to use Addons that we open source and contribute Addons of your own as you solve technical documentation problems arising in your company. We can’t wait to see what you come up with!
|
||||
|
||||
Here are some resources to help you get started with new TechDocs Addons:
|
||||
|
||||
- [Installing and using Addons](https://backstage.io/docs/features/techdocs/addons#installing-and-using-addons): add an existing TechDocs Addon to your Backstage App
|
||||
- [Creating an Addon](https://backstage.io/docs/features/techdocs/addons#creating-an-addon): contribute a new Addon for others to use
|
||||
- [TechDocs Addon page](https://backstage.io/docs/features/techdocs/addons): read everything you need to know about TechDocs Addons
|
||||
|
||||
# Next steps
|
||||
|
||||
At present, the TechDocs Addon Framework is focused on frontend experiences only. We know what’s available now is a solid foundation, but based on our experience developing and maintaining Addons over several years, we know there’s more to be done.
|
||||
|
||||
One such pattern is the occasional need for Addons to retrieve or compute data that is not easily accessible. Examples of these at Spotify are Last Updated and Top Contributors. Seemingly simple, these Addons require the ability to run non-trivial git commands to determine when documentation itself was last updated, and by whom.
|
||||
|
||||
|
||||
|
||||
This next step is a bit more tricky and we would like to work with you all to make it happen. Take a look at [this issue](https://github.com/backstage/backstage/issues/11110) in the GitHub repo, let us know what you think, and feel free to get involved.
|
||||
@@ -1,68 +0,0 @@
|
||||
---
|
||||
# prettier-ignore
|
||||
title: Releasing Backstage Search 1.0
|
||||
author: Emma Indal, Spotify
|
||||
authorURL: https://www.linkedin.com/in/emma-indal
|
||||
---
|
||||
|
||||
**TL;DR** If you’ve been waiting for Backstage Search to come out of beta, we’re excited to announce that [Backstage Search 1.0](https://backstage.io/docs/features/search/#backstage-search-10) is here!
|
||||
|
||||
We first released the Backstage Search Platform over a year ago. Backstage Search Platform is a search experience built for you, by you.
|
||||
|
||||
|
||||
|
||||
Backstage Search Platform makes it possible for you to search across your entire software ecosystem. With a Search platform that is customizable and extendable, you can identify your needs within your organization and set up search to solve these problems. Whether it is to search through the Software Catalog or technical documentation generated by the TechDocs plugin.
|
||||
|
||||
<!--truncate-->
|
||||
|
||||
## So what is Backstage Search 1.0?
|
||||
|
||||
Since the first release of the Backstage Search Platform, we have seen a fantastic community grow around the search plugins. To mention just a few of these contributions:
|
||||
|
||||
- More search engine modules: [Elasticsearch](https://www.npmjs.com/package/@backstage/plugin-search-backend-module-elasticsearch) originally [contributed](https://github.com/backstage/backstage/pull/6569) by Roadie and [Postgres](https://www.npmjs.com/package/@backstage/plugin-search-backend-module-pg) originally [contributed](https://github.com/backstage/backstage/pull/6682) by SDA SE
|
||||
- More components: Quick search modal, originally [contributed](https://github.com/backstage/backstage/pull/7316) by Expedia Group
|
||||
- More plugin integrations: TechDocs also [contributed](https://github.com/backstage/backstage/pull/6375) by Roadie and [Software Catalog](https://github.com/backstage/backstage/pull/4515)
|
||||
|
||||
These are just a few contributions of the countless enhancements and improvements made by contributors across the globe. With a well adopted and tested search platform we feel confident to release Backstage Search as 1.0.
|
||||
|
||||
Packages included in Backstage Search 1.0 release are:
|
||||
|
||||
**Core search packages**
|
||||
|
||||
- [@backstage/plugin-search](https://www.npmjs.com/package/@backstage/plugin-search)
|
||||
- [@backstage/plugin-search-react](https://www.npmjs.com/package/@backstage/plugin-search-react)
|
||||
- [@backstage/plugin-search-common](https://www.npmjs.com/package/@backstage/plugin-search-common)
|
||||
- [@backstage/plugin-search-backend](https://www.npmjs.com/package/@backstage/plugin-search-backend)
|
||||
- [@backstage/plugin-search-backend-node](https://www.npmjs.com/package/@backstage/plugin-search-backend-node)
|
||||
|
||||
**Modules**
|
||||
|
||||
- [@backstage/plugin-search-backend-module-elasticsearch](https://www.npmjs.com/package/@backstage/plugin-search-backend-module-elasticsearch)
|
||||
|
||||
No additional features are released as part of the major release as the maintainers of the search packages focused on the following for this release:
|
||||
|
||||
- Bug fixes and clean up of deprecations.
|
||||
- Improved error handling for missing indices.
|
||||
- Separation of AWS Elastic and Open Elastic support.
|
||||
- Refactor the packages by moving reusable components from `@backstage/plugin-search` to `@backstage/plugin-search-react`.
|
||||
- Improved documentation including tutorials for how to [Integrate Search into a plugin](https://backstage.io/docs/plugins/integrating-search-into-plugins).
|
||||
|
||||
You might have noticed that the [@backstage/plugin-search-backend-module-pg](https://www.npmjs.com/package/@backstage/plugin-search-backend-module-pg) package is not part of 1.0. That’s because that package is a community supported module, and therefore we have not included it as part of 1.0. If you are interested in pushing the Postgres engine to 1.0, feel free to reach out to us in the [#search](https://discord.com/channels/687207715902193673/770283289327566848) channel on Discord.
|
||||
|
||||
## Elasticsearch as the recommended engine for production usage
|
||||
|
||||
When the Backstage Search Platform was first released, it came with an in-memory search engine as default - Lunr. While this is a good engine to use on a smaller scale and for local development (to avoid having to set up a search engine instance separately), it also has its limitations such as:
|
||||
|
||||
- Lunr does not scale well. Horizontally scaled deployments of Backstage and/or Backstage Search backend using Lunr result in either duplicated indexing processes and indices or inconsistent index state across nodes.
|
||||
- Lunr’s filter functionality is limited, especially for [logical AND/OR operators](https://github.com/olivernn/lunr.js/issues/353).
|
||||
- Lunr has a smaller community than Elasticsearch, which could mean that adopters relying on it will have less by way of resources for iterating on and improving search.
|
||||
|
||||
Therefore, we recommend using Elasticsearch for production usage. Moving forward, the search maintainers will prioritize the Elasticsearch engine while we’ll rely on the community to maintain the Postgres engine.
|
||||
|
||||
## How to contribute
|
||||
|
||||
If you want to contribute and to further improve search, you can check out the [open issues labeled with search](https://github.com/backstage/backstage/issues?q=is%3Aissue+search+label%3Asearch+is%3Aopen) or reach out to us at the [#search](https://discord.com/channels/687207715902193673/770283289327566848) Discord channel.
|
||||
|
||||
## How to get started
|
||||
|
||||
If you haven’t adopted the Backstage Search Platform yet and feel like now is a good time. Head over to the [getting started docs](https://backstage.io/docs/features/search/getting-started).
|
||||
@@ -1,41 +0,0 @@
|
||||
---
|
||||
# prettier-ignore
|
||||
title: Backstage Security Audit & Updates
|
||||
author: Patrik Oldsberg, Spotify
|
||||
authorURL: https://github.com/Rugvip
|
||||
---
|
||||
|
||||
**TL;DR** Backstage’s security posture continues to mature! Today, we’re releasing a report from an independent security audit and the first version of the Backstage Threat Model.
|
||||
|
||||
|
||||
|
||||
As an [Incubating project](https://www.cncf.io/blog/2022/03/15/backstage-project-joins-the-cncf-incubator/) within the [Cloud Native Computing Foundation (CNCF)](https://www.cncf.io/), Backstage was fortunate enough to take advantage of a sponsored security audit. The [Open Source Technology Improvement Fund (OSTIF)](https://ostif.org/) sponsored the audit as part of its ongoing efforts to secure the open source software ecosystem, and the audit itself was performed by [X41 D-Sec](https://x41-dsec.de/). Our goal with the audit was to evaluate and improve Backstage’s security posture, focusing on the core Backstage framework and plugins.
|
||||
|
||||
<!--truncate-->
|
||||
|
||||
## Report Findings and Fixes
|
||||
|
||||
The security audit and improvements concluded earlier this month, on August 18th. The audit **findings** totalled two critical, two high, five medium, and three low severity vulnerabilities, alongside 15 side findings with no direct security impact. As of the [Backstage 1.5 release](https://backstage.io/docs/releases/v1.5.0), eight out of the 12 main findings and many of the side findings are fully remedied. If you are a few versions behind there’s no need to worry though, most fixes were included in the 1.3 release.
|
||||
|
||||
Out of the four findings that have yet to be fixed, three are related to rate limiting or internal DoS concerns. With the introduction of the Backstage Threat Model (more on that below), Backstage’s positioning states that this is outside the scope of the security concerns of Backstage. Rather, we trust internal users of Backstage to not intentionally sabotage the availability of the service. This is not to say that we will never aim to get these findings addressed, but we have pushed them to be potential future improvements as we focus our near-term efforts on improving the product in other ways.
|
||||
|
||||
The last outstanding finding is to build out the capabilities of our service-to-service auth system. This is an area where the audit identified a couple of missing pieces in our early version of the implementation. We have since closed the gap by introducing token expiration, and will continue to work on this as we open up for more complex and hardened deployment patterns through the [evolution of the backend system](https://github.com/backstage/backstage/issues/11611).
|
||||
|
||||
Another important finding was the potential for confusion and user impersonation due to most authentication providers having sign-in enabled by default. This finding reinforced our decision to switch sign-in to being disabled by default for all authentication providers, which was part of the [1.1 release](https://backstage.io/docs/releases/v1.1.0).
|
||||
|
||||
Perhaps the most important outcome of this audit is that it helped us focus our efforts to keep improving the security of Backstage. It identified priority areas in both implementation and documentation for us going forward. One particular area that was pointed out in a finding is the documentation around the security model of Backstage deployment. There have been several efforts to highlight this in documentation, but it is still not clear enough. What we’ve been lacking is documentation that is completely dedicated towards detailing the security concerns of Backstage. That is why in addition to publishing the security audit report, we are also introducing the [Backstage Threat Model](https://backstage.io/docs/overview/threat-model).
|
||||
|
||||
## Introducing the Backstage Threat Model
|
||||
|
||||
The existing Backstage documentation has many security concerns interwoven within its text, but to find them all, you need to spend a lot of time reading. We previously lacked a one-stop-shop for readers that are interested in the security model and concerns of Backstage. So, we are happy to introduce the [Backstage Threat Model](https://backstage.io/docs/overview/threat-model), which closes this gap. The Threat Model outlines key security considerations for operators, developers, and security researchers. It is a living document that will evolve and expand alongside the Backstage project.
|
||||
|
||||
The threat model document covers the trust model and roles involved in a typical Backstage setup, the responsibilities that fall on integrators of Backstage, and common configuration concerns across all Backstage projects. Beyond these three topics, it also dives deeper into a number of core features. The `auth`, `catalog`, `scaffolder`, and `techdocs` plugins are all covered separately with their individual security concerns.
|
||||
|
||||
We’d like to point out a few key parts in case you are in a rush. Be sure to familiarize yourself with the integrator's responsibility to protect the Backstage installation from unauthorized access. If you ingest organizational data into the catalog and use that to sign in users, you’ll also want to check out the first halves of the authentication and catalog sections.
|
||||
|
||||
## Links and References
|
||||
|
||||
- [Full Audit Report](assets/22-08-23/X41-Backstage-Audit-2022.pdf)
|
||||
- [Backstage Security Policy](https://github.com/backstage/backstage/blob/master/SECURITY.md)
|
||||
|
||||
On behalf of the Backstage maintainers and community: thanks to the CNCF, OSTIF, and X41 D-Sec for the opportunity to improve the project.
|
||||
@@ -1,92 +0,0 @@
|
||||
---
|
||||
# prettier-ignore
|
||||
title: FYI 📣 The Plugin Analytics API
|
||||
author: Eric Peterson, Spotify
|
||||
authorURL: https://github.com/iamEAP
|
||||
authorImageURL: https://avatars.githubusercontent.com/u/3496491?v=4
|
||||
---
|
||||
|
||||
**TL;DR** If you didn't know, now you know: the Backstage plugin analytics API is here to help you understand how developers in your organization are using Backstage.
|
||||
|
||||
|
||||
|
||||
<!--truncate-->
|
||||
|
||||
## What is the plugin analytics API?
|
||||
|
||||
The plugin analytics API is a [utility api](https://backstage.io/docs/api/utility-apis) available by default in every Backstage instance, intended to bridge the gap between the needs of Backstage integrators and plugin developers. While Backstage integrators want visibility into the plugins they’ve installed, they lack the power to instrument those plugins. And although plugin developers have the power to instrument plugins, they can’t do so without a single, vendor-agnostic way to track events. Enter: the plugin analytics API.
|
||||
|
||||
While “analytics” as a concept can be broad, the goal of the API is narrowly focused: empower those deploying Backstage to understand usage of their instance. The plugin analytics API isn’t designed to solve for observability use-cases like tracing, logging, performance monitoring, error metrics, or alerting. Rather, the API is designed to capture and quantify real user interactions, which can form the basis for metrics like daily active users, top plugins, and more.
|
||||
|
||||
## Start collecting data
|
||||
|
||||
Backstage core (and a few other plugins) are already instrumented with [key events](https://backstage.io/docs/plugins/analytics#key-events) that are ready for you to start collecting and analyzing.
|
||||
|
||||
The simplest way to get started is to use one of the [supported analytics tools](https://backstage.io/docs/plugins/analytics#supported-analytics-tools) and install its provided API implementation like you would any other utility API. For example:
|
||||
|
||||
```tsx
|
||||
// packages/app/src/apis.ts
|
||||
import {
|
||||
analyticsApiRef,
|
||||
configApiRef,
|
||||
identityApiRef,
|
||||
} from '@backstage/core-plugin-api';
|
||||
import { GoogleAnalytics } from '@backstage/plugin-analytics-module-ga';
|
||||
|
||||
export const apis: AnyApiFactory[] = [
|
||||
// Instantiate and register the GA Analytics API Implementation.
|
||||
createApiFactory({
|
||||
api: analyticsApiRef,
|
||||
deps: { configApi: configApiRef, identityApi: identityApiRef },
|
||||
factory: ({ configApi, identityApi }) =>
|
||||
GoogleAnalytics.fromConfig(configApi, {
|
||||
identityApi,
|
||||
}),
|
||||
}),
|
||||
];
|
||||
```
|
||||
|
||||
If your chosen analytics tool doesn’t have an integration yet, you can write a custom integration by [following these instructions](https://backstage.io/docs/plugins/analytics#writing-integrations). (And if you’re integrating with a publicly available analytics service, as opposed to a custom in-house system, why not [consider contributing it back to the community](https://backstage.io/docs/plugins/create-a-plugin)?)
|
||||
|
||||
## Instrument plugins
|
||||
|
||||
While some key events are already instrumented, there may be important actions in open source plugins that are un-instrumented, not to mention in your custom, InnerSource plugins. Luckily, the plugin analytics API can be leveraged by open source and InnerSource plugins all the same.
|
||||
|
||||
To capture an event, invoke the `useAnalytics()` react hook and call the function it returns when the user performs the action you wish to track (e.g. merging a pull request):
|
||||
|
||||
```tsx
|
||||
import { useAnalytics } from '@backstage/core-plugin-api';
|
||||
|
||||
const analytics = useAnalytics();
|
||||
analytics.captureEvent('merge', pullRequestName);
|
||||
```
|
||||
|
||||
Don’t worry about having to stuff additional levels of detail into just the event action and subject, you can provide extra dimensional data on the `attributes` property, as well as a primary metric on the `value` property, like this:
|
||||
|
||||
```tsx
|
||||
analytics.captureEvent('merge', pullRequestName, {
|
||||
value: pullRequestAgeInMinutes,
|
||||
attributes: {
|
||||
org: orgName,
|
||||
repo: repoName,
|
||||
},
|
||||
});
|
||||
```
|
||||
|
||||
In situations where your plugin is tracking multiple events and you want all of those events to share common dimensional data, you can use the `<AnalyticsContext>`. Every event captured in child components underneath this context automatically inherits the values you set:
|
||||
|
||||
```tsx
|
||||
import { AnalyticsContext } from '@backstage/core-plugin-api';
|
||||
|
||||
<AnalyticsContext attributes={{ vcsProvider: 'github' }}>
|
||||
{children}
|
||||
</AnalyticsContext
|
||||
```
|
||||
|
||||
In fact, Backstage core uses an `<AnalyticsContext>` to automatically decorate every event with a corresponding plugin ID and an extension name in order to facilitate plugin-level analysis.
|
||||
|
||||
While the above should be enough to get you going, don’t forget to check out [the complete guide to event capture](https://backstage.io/docs/plugins/analytics#capturing-events), which covers event naming considerations, testing, and more.
|
||||
|
||||
## Get involved
|
||||
|
||||
If you didn’t know, now you know! If you’re passionate about data and want to help push the Backstage analytics ecosystem forward, join us in the [#analytics channel on discord](https://discord.com/channels/687207715902193673/1007303347914690610), contribute [integration ideas](https://github.com/backstage/backstage/issues/new?assignees=&labels=plugin&template=plugin_template.md&title=%5BAnalytics+Module%5D+THE+ANALYTICS+TOOL+TO+INTEGRATE), or [suggest a new analytics event](https://github.com/backstage/backstage/issues/new?assignees=&labels=enhancement&template=feature_template.md&title=[Analytics%20Event]:%20THE+EVENT+TO+CAPTURE).
|
||||
@@ -1,36 +0,0 @@
|
||||
---
|
||||
title: 'ICYMI: BackstageCon & KubeCon NA 2022 Recap'
|
||||
description: 'We had a great time in Detroit! Learn more about our first dedicated conference to Backstage and KubeCon NA 2022.'
|
||||
author: Emma White, Spotify
|
||||
authorURL: https://www.linkedin.com/in/emmamckeewhite/
|
||||
---
|
||||
|
||||
## ICYMI: BackstageCon & KubeCon NA 2022 Recap
|
||||
|
||||
|
||||
|
||||
What an action-packed and memorable week for the Backstage community meeting up IRL at KubeCon North America 2022 in (unseasonably warm and sunny) Detroit. Let’s see what the community was up to:
|
||||
|
||||
### BackstageCon: A full day of nothing but Backstage
|
||||
|
||||
|
||||
|
||||
We started the week off strong, packing a ballroom for [BackstageCon](https://events.linuxfoundation.org/backstagecon-north-america/) on Monday. It was a smorgasbord of some of our active community members at the first official Backstage conference — as well as some new faces interested in learning more about Backstage! To welcome us, Roadie’s [Martina Iglesias Fernandez](https://github.com/martina-if) and Spotify’s [Suzanne Daniels](https://github.com/suuus) took center stage. Next up, we listened to three keynotes from the event’s top sponsors: Roadie’s [David Tuite](https://github.com/dtuite) enlightened us on how to 10x developer effectiveness for teams, [Dave Zolotusky](https://github.com/dzolotusky) from Spotify discussed developer happiness and [announced](https://www.linkedin.com/posts/spotify-r%26d_backstage-devex-activity-6990305201710587904-SnDQ?utm_source=share&utm_medium=member_desktop) that [Spotify Plugins for Backstage](https://backstage.spotify.com/blog/spotify-plugins-for-backstage/) are launching soon, and [Valentina Alaria](https://www.linkedin.com/in/valentinaalaria/) from VMware Tanzu talked about how to curate the Backstage experience to enable developer velocity. In between some creative snacks (lemon blueberry popcorn, anyone?) and coffee breaks, we heard from adopters including [Telus](https://backstage.spotify.com/blog/building-for-simplicity-TELUS/), [DAZN](https://backstage.spotify.com/blog/adopter-spotlight/dazn/), HP, US Bank, and more on lessons learned through their adoption journeys, we talked about different ways to leverage data within Backstage, and we discussed new ways to customize Backstage for specific adopter needs.
|
||||
|
||||
You can watch all the BackstageCon sessions, talks, and keynotes [here](https://www.youtube.com/playlist?list=PLj6h78yzYM2OKySsTuiip3BqmdYZQRnSf)!
|
||||
|
||||
### Project Meeting: Building a better Backstage together
|
||||
|
||||
|
||||
|
||||
The following day, the Backstage maintainers hosted a lively project meeting, where we engaged with a lot of folks that had been at BackstageCon the day before. Over the course of the meeting, the Backstage community talked through recommended approaches for maintaining your Software Catalog as a source of truth, sourcing internal contributors for organization’s Backstage apps, improving frontend performance in a few plugins, how Backstage maintainers work, and appreciation for the contributions from our community. You can read more detailed notes from the project meeting in the repo [here](https://github.com/backstage/community/blob/main/project-meetings/kubecon-na-2022.md).
|
||||
|
||||
### KubeCon: Demos, swag, and standing-room only
|
||||
|
||||
And last but not least: three days of [KubeCon North America](https://events.linuxfoundation.org/kubecon-cloudnativecon-north-america/)! At KubeCon, the Backstage team met and greeted so many new faces at our kiosk in the Project Pavilion. We ran demos, answered questions, and handed out lots and lots of SWAG!
|
||||
|
||||
|
||||
|
||||
Spotify’s [Francesco Corti](https://github.com/fcorti) and core maintainer [Ben Lambert](https://github.com/benjdlambert) took the stage on Wednesday to present the Backstage maintainer talk to a PACKED audience. They discussed how core features of Backstage are changing the way end-user developers interact and manage their ecosystem, and encouraged folks to create the future of developer experience with the rest of the Backstage community. If you missed it, no worries! Their talk track will be posted on the [CNCF YouTube channel](https://www.youtube.com/c/cloudnativefdn).
|
||||
|
||||
…and that’s a wrap! What an incredible week. Our growing Backstage community continues to amaze us with its dedication and enthusiasm. We can’t wait to see you all again at KubeCon Europe in The Netherlands! In fact, we’d love to see our adopters give Backstage talks next year (hint, hint). The KubeCon Europe [CFP is open](https://events.linuxfoundation.org/kubecon-cloudnativecon-europe/program/cfp/#overview) until Friday, November 18, 2022.
|
||||
@@ -1,16 +0,0 @@
|
||||
---
|
||||
title: The Linux Foundation launches its Introduction to Backstage course
|
||||
description: The new Linux Foundation course is available for free on edX and is designed to help individuals understand how to map Backstage to their organization needs
|
||||
author: Jorge Lainfiesta, Roadie
|
||||
authorURL: https://www.linkedin.com/in/jrlainfiesta/
|
||||
---
|
||||
|
||||
Backstage continues to grow in [popularity and maturity](https://roadie.io/blog/backstage-consolidating-its-role-in-the-cloud-native-ecosystem/), with industry leaders not only adopting the framework but actively participating in the community through contributions and commercial offerings. One of the most recent contributions comes from the Linux Foundation, [launching an introductory course](https://training.linuxfoundation.org/blog/23107/) aimed at DevOps engineers or professionals working on Developer Productivity or Developer Experience. The course is available for free on edX, with a paid option for the certified track.
|
||||
|
||||
[](https://www.edx.org/course/introduction-to-backstage-developer-portals-made-easy)
|
||||
|
||||
<!--truncate-->
|
||||
|
||||
The course, [Introduction to Backstage: Developer Portals Made Easy (LFS142x)](https://www.edx.org/course/introduction-to-backstage-developer-portals-made-easy), starts discussing the benefits of adopting a Developer Portal. Then, it dives into what is Backstage, its main features (Catalog, Scaffolder, TechDocs), and how to map its capabilities to your organization. At last, it provides tips on how to connect with the community to ease up your adoption journey.
|
||||
|
||||
The course author, [Jorge Lainfiesta](https://www.linkedin.com/in/jrlainfiesta/), is a Technical Marketing Manager at [Roadie](https://roadie.io). Jorge has a background in software engineering (PayPal) and digital communication (UCLA). He’s been working around Backstage since it was open sourced by Spotify and co-hosts community initiatives like the Backstage Users Unconference.
|
||||
@@ -1,79 +0,0 @@
|
||||
---
|
||||
title: Backstage Wrapped 2022
|
||||
author: Francesco Corti & Suzanne Daniels
|
||||
authorURL: https://github.com/fcorti
|
||||
---
|
||||
|
||||
|
||||
|
||||
If 2021 was the year of growth for the Backstage project and community, 2022 can be easily defined as the year of maturity. Both the project and the community continued to grow at an incredible pace and the platform is now more stable, more secure, and more powerful than ever.
|
||||
|
||||
Our community is full of people from across the globe who bring incredible engagement and positive vibes to the project. And we finally got to experience this for the first time in real life during [BackstageCon](https://www.youtube.com/playlist?list=PLj6h78yzYM2OKySsTuiip3BqmdYZQRnSf), the very first in-person conference fully dedicated to Backstage, where hundreds of enthusiasts, the maintainers, adopters, and partners joined the event confirming the great momentum and the traction in the market.
|
||||
|
||||
But before anticipating too much, let’s share some stats of this amazing 2022.
|
||||
|
||||
<!--truncate-->
|
||||
|
||||
## We grew … a lot!
|
||||
|
||||
Last year we celebrated 75 [public adopters](https://github.com/backstage/backstage/blob/master/ADOPTERS.md) and today we have over 600 adopters, confirming the interest around Backstage across all the industries, sectors, and dimensions. Companies like [Toyota North America](https://aws.amazon.com/solutions/case-studies/toyota-ecs-case-study/), Deutsche Bank, Mercedes-Benz, Procter & Gamble, Siemens, LinkedIn, and many more joined the community this year and are actively contributing in growing the product and its maturity.
|
||||
|
||||
|
||||
|
||||
Not only are our adopters growing at an exponential rate, but so too are our contributors. Our [Discord server](https://discord.gg/backstage-687207715902193673-687207715902193673) is a perfect example of the worlds of our adopters and contributors melding. On average, at any given hour of the day or night, there are more than 500 people online available to talk and provide support on any Backstage topic. Discord discussions run a full gamut of topics – from technical support questions to best practices for onboarding engineers to Backstage – basically, anything and everything an adopter may be interested to know and learn. At the very beginning of 2022, we “only” had 4k Discord members. Today, we have a growing membership of 8.2k.
|
||||
|
||||
Isn’t it what we can call a great and vibrant community of enthusiasts?
|
||||
|
||||
The growth of the ecosystem is not limited to the adopters and contributors. The ecosystem also includes big tech companies interested in growing Backstage by including it as part of their offering and integrations. Our [collaboration with VMWare](https://youtube.com/watch?v=GAzKCQO8Vt0&si=EnSIkaIECMiOmarE) is a great example of this, and [RedHat](https://developers.redhat.com/articles/2022/10/24/red-hat-joins-backstageio-community) joined the party this year – promising even faster growth in contributions and integrations for the Backstage project.
|
||||
|
||||
Before we go any further, let’s take a quick look at some more numbers, mainly coming from the [Official Github repository](https://github.com/backstage/backstage). This year…
|
||||
|
||||
- Our contributors grew from a group of 500 to 900+
|
||||
- Contributions to the project increased from 9k to 15k+
|
||||
- The number of forks shot up from 2k to 3k+
|
||||
- Backstage stars increased from 14k to almost 20k
|
||||
- And lastly, we welcomed over 550 adopters into our community.
|
||||
|
||||
All of these people driving the enormous growth and maturity of the project are represented in the chart below, which shows cumulative activities per month for Backstage:
|
||||
|
||||
|
||||
|
||||
Wow… that’s a lot of activity. We’ve generated this animation showing all of your contributions to the Backstage repository in 2022, look at this project grow:
|
||||
|
||||
<iframe width="780" height="440" src="https://www.youtube.com/embed/GoWBvHpH5Cg" frameBorder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowFullScreen></iframe>
|
||||
|
||||
## But wait… there’s more
|
||||
|
||||
The growth of the community is so exciting to see. And with all this community growth, comes growth and maturity of the product, making Backstage better able to support adopters in their developer experience challenges. The Backstage open source project has almost [100 plugins](https://backstage.io/plugins), each one amending Backstage with a tool or service to improve not only adopters’ Backstage apps, but their unique developer experiences. And almost every week we learn of a new one being contributed, which is amazing.
|
||||
|
||||
The Backstage platform itself is leaving 2022 more mature than ever, thanks to milestones such as these:
|
||||
|
||||
- [Backstage is now beyond version 1](https://backstage.io/blog/2022/03/17/backstage-1.0).
|
||||
- [Backstage had its first Security Audit ever and now can rely on a Threat Model](https://backstage.io/blog/2022/08/23/backstage-security-audit).
|
||||
- [Backstage Learn helps adopters get started more easily](https://backstage.spotify.com/learn/).
|
||||
- [Backstage reached incubating status as part of the CNCF ecosystem](https://www.cncf.io/blog/2022/03/15/backstage-project-joins-the-cncf-incubator/).
|
||||
|
||||
And like every mature project, now Backstage has also a mascot: Bowie the Beaver!
|
||||
|
||||
|
||||
|
||||
Additionally, we launched a new [Special Interest Groups (SIGs)](https://github.com/backstage/community/tree/main/sigs) initiative this year, following the lead of Kubernetes. We believe Backstage SIGs will better coordinate contributions, grow the platform cohesively with the open source community, and allow contributors to dig even deeper as a community member. At this moment in time there two SIGs in place:
|
||||
|
||||
- The [Catalog SIG](https://github.com/backstage/community/blob/main/sigs/sig-catalog/README.md), covering all aspects of the systems and components related to the Software Catalog.
|
||||
- The [Adoption SIG](https://github.com/backstage/community/blob/main/sigs/sig-adoption/README.md), covering all aspects of the adoption journey of Backstage.
|
||||
|
||||
Our plan is to open more SIGs in 2023 to engage more with the community and to keep driving towards cohesive growth for the community and project.
|
||||
|
||||
Last but not least, we mustn't overlook the first ever conference fully dedicated to Backstage: BackstageCon. What was special there? SO much. But in particular two things: seeing everyone in real life and the incredible mood and conversations between maintainers, adopters, partners and enthusiasts. It’s hard to express just how positive and amazing the vibes were in a blog, but you can read our recap [here](https://backstage.io/blog/2022/10/28/backstagecon-kubecon-2022) or watch the sessions [here](https://www.youtube.com/playlist?list=PLj6h78yzYM2OKySsTuiip3BqmdYZQRnSf). And in the meantime, here are some great numbers from the event:
|
||||
|
||||
- 250 attendees or a 100% full venue and packed room.
|
||||
- 14 sessions
|
||||
- 17 speakers
|
||||
|
||||
## Goodbye, 2022. Hello, 2023!
|
||||
|
||||
After this incredible year, thanks to everyone in the global Backstage community who contributed to the open source project in 2022. We are already working on the goals for 2023 – and as a roadmap teaser: we are very much committed to making the journey of adoption easier, faster, more valuable, and overall better. We would not be here today without our amazing community, so thank you for everything!
|
||||
|
||||
Looking forward to continuing collaborating together for an exciting 2023.
|
||||
|
||||
See you then! Happy holidays from everyone on the Backstage team at Spotify!
|
||||
@@ -1,45 +0,0 @@
|
||||
---
|
||||
title: Scaling Backstage Ingestion with Incremental Entity Providers
|
||||
author: Paul Cowan & Taras Mankovski
|
||||
authorURL: https://frontside.com/
|
||||
---
|
||||
|
||||
At the heart of [Backstage](https://backstage.io/) is the [Backstage Software Catalog](https://backstage.io/docs/features/software-catalog/), which is a data store that allows an organization to centralize and visualize its many software services and components. Backstage inspects and transforms an organization's disparate software services and parts into a centralized data store. This blog post introduces the concept of incremental entity providers, which allow Backstage to scale ingestion to even larger datasets.
|
||||
|
||||
|
||||
|
||||
<!--truncate-->
|
||||
|
||||
A common use case is for an organization to want to surface ownership and metadata about repositories. Backstage provides a mechanism for discovering and transforming repository information into a standard data structure and persisting it into the Backstage [Catalog](https://backstage.io/docs/features/software-catalog/). This process is known as ingestion, where all data is transformed into a standard Backstage data structure known as an entity. Entities in the Catalog’s data store are accessible to the Backstage App via the REST API.
|
||||
|
||||
Data is transformed into entities via what is known as the ingestion and processing loop, which can be thought of as an [extract, transform and load (ETL) pipeline](https://en.wikipedia.org/wiki/Extract,_transform,_load), where raw data such as GitHub repositories are loaded from GitHub, transformed into entities and outputted to the Catalog.
|
||||
|
||||
## Entity Providers
|
||||
|
||||
Backstage offers what are known as [entity providers](https://backstage.io/docs/features/software-catalog/life-of-an-entity) as a means for ingesting the raw data into the pipeline and transforming them into Backstage entities. For example, Backstage comes with a [GitHub Entity Provider](https://backstage.io/docs/reference/plugin-catalog-backend-module-github) that finds all catalog-info.yaml files in GitHub repositories. The processing loop transforms them into Backstage entities and subsequently persists them to the software catalog.
|
||||
|
||||
Entity providers are a relatively new abstraction and the recommended way to ingest data into the catalog. The Backstage catalog engine starts each registered entity provider, which connects to its data source (e.g., the GitHub Entity Provider connects to GitHub). The entity provider will query the external data source and convert the data into the entity format. Finally, the entity provider issues what is known as a mutation to the catalog engine. A mutation is a signal from the entity provider to the catalog engine that entities are available to be processed and stored.
|
||||
|
||||
A mutation can be either a full mutation or a delta mutation. A full mutation replaces all entities previously ingested by the entity provider with a new set of entities. The entity provider will remove all entities not found in the latest ingestion. A full mutation can be used to ingest relatively small datasets (less than 10,000 entities); however, ingesting more during a full ingestion may cause out-of-memory errors and delay the processing of entities from other entity providers. A delta mutation can surgically add and remove entities from the catalog. A delta mutation is useful when the data source provides events-based APIs like webhooks, which allows the Backstage catalog engine to ingest a small number of entities as they get added, updated and/or deleted.
|
||||
|
||||
## Incremental entity providers
|
||||
|
||||
A large organization typically deals with massive datasets. Until recently, ingesting large datasets with entity providers has been problematic because performing a full ingestion resulted in out-of-memory errors, and many data sources don’t provide webhooks or other events-based APIs. At the same time, the datasets were too large to efficiently manage through targeted delta mutations.
|
||||
|
||||
This is a problem that [DevEx team at HP](http://hp.com) faced when building their software catalog with Backstage. [Damon Kaswell](https://github.com/dekoding), Senior Application Developer on the DevEx team at HP, shared their experience at [BackstageCon 2022](https://www.youtube.com/watch?v=5qHyZntKXRU&list=PLj6h78yzYM2OKySsTuiip3BqmdYZQRnSf&index=13), detailing the problem and the solution that [Frontside](https://frontside.com/) created in collaboration with developers on HP’s DevEx team.
|
||||
|
||||
|
||||
|
||||
The solution HP and [Frontside](https://frontside.com/) arrived at was to implement an incremental entity provider. An incremental entity provider effectively performs a full mutation using a series of delta mutations combined with a mark and sweep mechanism. It paginates through the dataset, tracking entities retrieved from each page and the cursor of the next page, pausing ingestion every few seconds to give the processing loop time to process existing entities. Once it reaches the end of the dataset, it determines which entities were not ingested during this ingestion cycle and emits a delta mutation to delete unmarked entities.
|
||||
|
||||
Simply by adding a few new tables to the database schema, the incremental ingestion entity provider converts any existing entity provider into an incremental entity provider. These tables allow the incremental entity provider to be long-lived and keep track of its current location in the dataset by persisting a cursor that it uses to page through any large dataset. The larger the dataset, the more pages of data or bursts of work the incremental entity provider will ingest—but there will be no out-of-memory errors, effectively removing scalability problems.
|
||||
|
||||
The results speak for themselves. Migrating from regular entity providers to incremental entity providers reduced ingestion time by 92% – from over 4 and a half hours to just 20 minutes. Incremental entity providers eliminated the ingestion maintenance burden from being a constant problem to a non-issue. Writing reliable integration with external services can now be done in days instead of weeks.
|
||||
|
||||
## Go forth and ingest!
|
||||
|
||||
Backstage provides a robust framework for ingesting data from external sources, but HP needed to scale it beyond its design. The Backstage framework allowed [Frontside](https://frontside.com/) and HP’s developers to extend it with a plugin to support HP’s scaling requirements.
|
||||
|
||||
We're delighted to share that as of [this PR](https://github.com/backstage/backstage/pull/14356), the incremental ingestion backend is available for anyone to use with Backstage. The solution was released open source as [@backstage/plugin-catalog-backend-module-incremental-ingestion](https://github.com/backstage/backstage/tree/master/plugins/catalog-backend-module-incremental-ingestion#backstageplugin-catalog-backend-module-incremental-ingestion) and contains a package for creating incremental entity providers. The plugin's [repository README](https://github.com/backstage/backstage/tree/master/plugins/catalog-backend-module-incremental-ingestion) has detailed configuration and usage outlined.
|
||||
|
||||
The incremental ingestion entity provider is an excellent addition to the Backstage stack. Battle-tested on large datasets, the incremental entity provider is a significant step forward in smoothing the path to successful ingestion at scale.
|
||||
@@ -1,60 +0,0 @@
|
||||
---
|
||||
title: What’s Ahead in 2023?
|
||||
author: Lee Mills
|
||||
authorURL: https://github.com/leemills83
|
||||
---
|
||||
|
||||
# What’s Ahead in 2023?
|
||||
|
||||
|
||||
|
||||
Okay, everyone. Time to move on from all the 2022 reflections, Top 10 lists, and Wrapped(s), and turn our gaze in the other direction — towards 2023. As the Backstage team moves into the new year, we find ourselves asking those perennial questions: How can we continue to grow and enhance the Backstage community? How can we improve the experience for those adopting Backstage? How can we give the best support to Backstage contributors?
|
||||
|
||||
<!--truncate-->
|
||||
|
||||
Well, we don’t have all the answers, but we do have some. So we wanted to share more on three ongoing initiatives aimed at moving the needle forward for these three distinct, yet interrelated, questions.
|
||||
|
||||
- Grow your influence by climbing the contribution ladder
|
||||
- Come join our SIGs (and push for new ones)
|
||||
- Work with us to drive a better experience for Backstage adopters
|
||||
|
||||
# Climb the contribution ladder
|
||||
|
||||
Truth be told, we’ve been wanting to grow the maintainer team for some time, and have had multiple requests from contributors and contributing organizations wanting to become maintainers. But, so far, we just haven’t managed to get anything off the ground. What we see is that becoming a maintainer is too hard and the current ownership model doesn’t work. In short, we need to update Backstage governance.
|
||||
|
||||
To address this, we are proposing (RFC links below) the following three initiatives:
|
||||
|
||||
- Introduce more steps in between first-time contributor and maintainer in the form of a contributor ladder (loosely based on the [CNCF Project Template](https://github.com/cncf/project-template/blob/main/CONTRIBUTOR_LADDER.md)). The ladder might look as follows: Contributor, Org Member, Reviewer, Maintainer, Project Maintainer.
|
||||
- Change the ownership model, for example, divide the project up into several project areas, each covering particular parts of the project.
|
||||
- Introduce a new process for large contributions in the form of Backstage Enhancement Proposals (BEPs).
|
||||
|
||||
Read more and join the already rich discussion in [RFC: Updated Backstage Governance](https://github.com/backstage/backstage/issues/15317) and [RFC: Backstage Enhancement Proposals](https://github.com/backstage/backstage/issues/15318). The RFC will be open until 13/02/2023.
|
||||
|
||||
# Come join our SIGs (and push for new ones)
|
||||
|
||||
As many of you know, SIG stands for Special Interest Group. The purpose of a SIG is to bring together maintainers and interested contributors within a certain specialist area to discuss, debate, spread knowledge, brainstorm - and drive the overall project forward. They’re also a lot of fun!
|
||||
|
||||
We currently have two SIGs up and running:
|
||||
|
||||
- [Catalog](https://github.com/backstage/community/tree/main/sigs/sig-catalog?utm_campaign=Newsletters%20Sent&utm_medium=email&_hsmi=241130993&_hsenc=p2ANqtz-9fx-nTmQga2j12NqzZaL-lYPq-xQjDoXcWKe_JUoa2RGlK65R9j0CIygfYILr0tGEQSvRVN9xzhiJ6LmVxBthKnStfSA&utm_content=241130993&utm_source=hs_email) started up last June and covers all aspects of the systems and components related to the Software Catalog. The group runs every second Tuesday between 16:00 and 17:00 CET. Just show up or hop into [#catalog](https://discord.com/channels/687207715902193673/923144214580191282) (Discord), if you want to talk to us first. Here are the [notes from our sessions so far](https://docs.google.com/document/d/1xg57CDfX2R5jTGbbWANzifm2szEb664kuTwfEEvKgZU/edit#heading=h.iw0hjv6xfb9e).
|
||||
- [Adoption](https://github.com/backstage/community/tree/main/sigs/sig-adoption?utm_campaign=Newsletters%20Sent&utm_medium=email&_hsmi=241130993&_hsenc=p2ANqtz-9CAxtT8JSeJZPh41o3ZnDBi0VBFpbL6fEqXInr9HHOFhU3JAo8HekKg1JzE5rhGP5zOaHcsYDd1YxJWNHw-eSk5mLWkA&utm_content=241130993&utm_source=hs_email) kicked off in December and covers all aspects of the Backstage adoption journey including documentation and tutorials. In the first two meetups, we discussed adoption challenges based on user persona, collecting data about those challenges, and bootstrapping the Catalog to improve metadata quality for adopters. This one runs every second Thursday between 16:00 and 17:00 CET. Again just show up or, if you want to talk to us first, you can do so in [#adoption](https://discord.com/channels/687207715902193673/1045031039061479536) (Discord). Here are the [notes from our sessions](https://docs.google.com/document/d/1zeYSzXYgh897bxPQmwy2btOwCFlEjlUDLf00riySLRc/edit?_hsmi=241130993&_hsenc=p2ANqtz-_nPuE5hW4fnbhJ5-uK8r5HisSTU7rkslKirvqu0g-vdynbitPVYF2AVLAatos2dLoxb2Bgx_g4LBgH02kXoq7_Acd43Q#heading=h.iw0hjv6xfb9e) so far.
|
||||
|
||||
So that’s SIGs. Get involved and join the ones we have up and running. And/or feel free to propose new ones.
|
||||
|
||||
# Help drive a better experience for all adopters
|
||||
|
||||
Throughout all stages of adopting Backstage in an organization — initial discovery, evaluation and POC, and scaling to the wider org — we have identified opportunities where we want to make the journey for Backstage adopters faster and smoother.
|
||||
|
||||
We’ll go step-by-step, but initial plans are to:
|
||||
|
||||
- Make it easier to install, customize, and maintain Backstage
|
||||
- Provide Golden Paths for adoption
|
||||
- Improve the experience and the content on [backstage.io](https://backstage.io/docs/overview/what-is-backstage)
|
||||
|
||||
As we move forward, we’d love you to be part of it. Here are some ways that you can contribute to this initiative:
|
||||
|
||||
- Simply give us feedback. [Tell us about your adoption journey](https://spotify.co1.qualtrics.com/jfe/form/SV_cuxhYPB6oQDu7gW).
|
||||
- Contribute to the pages and documentation on [backstage.io](https://backstage.io/docs/overview/what-is-backstage)
|
||||
- Pay it forward by making code contributions even during your adoption journey (if you are on one)
|
||||
- Join the [Adoption](https://github.com/backstage/community/tree/main/sigs/sig-adoption?utm_campaign=Newsletters%20Sent&utm_medium=email&_hsmi=241130993&_hsenc=p2ANqtz-9CAxtT8JSeJZPh41o3ZnDBi0VBFpbL6fEqXInr9HHOFhU3JAo8HekKg1JzE5rhGP5zOaHcsYDd1YxJWNHw-eSk5mLWkA&utm_content=241130993&utm_source=hs_email) SIG
|
||||
- Chat with us on [#adoption](https://discord.com/channels/687207715902193673/1045031039061479536) (Discord)
|
||||
@@ -1,83 +0,0 @@
|
||||
---
|
||||
title: Backstage Backend System Alpha
|
||||
author: Patrik Oldsberg
|
||||
authorURL: https://github.com/Rugvip
|
||||
authorImageURL: https://avatars.githubusercontent.com/u/4984472?v=4
|
||||
---
|
||||
|
||||
|
||||
|
||||
For the past year, the Backstage maintainer team has been spending time to give the [old Backstage backend system](https://backstage.io/docs/plugins/backend-plugin) a much needed revamp. Our goal was not to build something completely new from scratch, but rather to solidify the existing foundations that have grown organically. We wanted to make plugin installation a lot simpler, while maintaining and even improving the ways in which you can customize your backend setups.
|
||||
|
||||
We’re happy to announce that the [v1.11](https://backstage.io/docs/releases/v1.11.0) release includes the public alpha of the [new Backstage backend system](https://backstage.io/docs/backend-system/)! The system has already been available to use for some time, as some of you have already found, but this alpha release marks the point where we are finally ready to encourage widespread adoption by plugin builders. We still don’t recommend that you use this new system in your production setups just yet, more on that later.
|
||||
|
||||
<!--truncate-->
|
||||
|
||||
## History of the Backstage backend system
|
||||
|
||||
The backend system that we all use today has grown very organically based on all the needs that have been discovered along the journey of the Backstage Open Source project. We started out with a very flexible system that was essentially just a collection of recommended patterns for plugins, along with a couple of common interfaces and utilities. This was largely due to the fact that before it was open sourced, the Backstage backend services at Spotify were all built on top of internal frameworks and practices that we couldn’t bring with us. Back in 2020, we didn’t have a lot of knowledge about what a good backend system for Backstage would look like, so we started off with a highly flexible foundation that would evolve organically over time.
|
||||
|
||||
As Backstage grew across all dimensions of adopter count, community size, code size, and capability, we saw the need to take a step back and reevaluate how Backstage backend plugins are built. About one year ago, the maintainers sat down and started to sketch what a new backend system could look like.
|
||||
|
||||
## Designing the New System
|
||||
|
||||
When we set out on this project, we had a few primary goals. First, we intended to introduce as few new concepts as possible. Our existing system already had a lot of different patterns, and ideally we wanted to only give those patterns names and make them part of the framework. Second, we wanted to keep the backend system recognizable to those familiar with the frontend system. The list of goals goes on, we had a lot of reasons to build this new system, these are a few more important ones:
|
||||
|
||||
- Make it easier to create and maintain backend installations.
|
||||
- Align how plugins provide points of customization and how those customizations are installed.
|
||||
- Make it much easier to maintain plugins, in particular keeping the API stable.
|
||||
- Simplify the process of splitting plugins out into separate deployments with shared environments.
|
||||
- Improve the local development and testing experience.
|
||||
|
||||
Prioritizing simplicity is often a guiding principle that we use for designs that span multiple ownership roles. We decide on which parts of the system that we think are the most important to have as simple as possible, or, viewed from the opposite end, where in the system we put necessary complexity. In this case, we optimized for keeping the backend setup as simple as possible, followed by modules and plugins, then libraries, and lastly the framework itself. What this guidance means in practice is that when there is complexity that needs to be added to implement a certain feature, we place as much of it as possible within the framework itself, then libraries, plugins and modules, and if absolutely needed, the backend setup.
|
||||
|
||||
To get the Backstage backend system to where we are today, we went through three major stages, starting with some very early high level experimentation. If you’re a fan of Git archaeology, you can see some of our early ideas in [our experiments branch](https://github.com/backstage/backstage/commit/fd3e6b67fef25a04789779700db4c37047d59d1b), as well as the [separate repository](https://github.com/backstage/backend-system-exploration) that we used to explore different ideas together with [Roadie](https://roadie.io/). The output of this work was all presented in an [RFC](https://github.com/backstage/backstage/issues/11611) to gather feedback.
|
||||
|
||||
A few months later as the RFC settled, we resumed work and followed up with an initial implementation. At this point there were still a lot of details in the design to figure out, especially as we started looking at how our existing plugins and services fit into this new system. We identified a lot of aspects that we inevitably didn’t consider in the initial design, and started exploring technical solutions to those problems. There was a lot of zooming in and out, both implementing details and then stepping back and looking at how that affects the broader system and where to go next. This ended up being the most time consuming stage, and we spent several months iterating on this.
|
||||
|
||||
We wrapped up this work just before KubeCon NA 2022, with the full system implemented. The state of the system at this point was presented in our talk on the topic, which you can see just below. Except for a few API tweaks, this is what the system still looks like today.
|
||||
|
||||
<iframe width="780" height="440" src="https://www.youtube.com/embed/ZXF7uxrEBVY" frameBorder="0" allow="accelerometer; autoplay; encrypted-media; gyroscope; picture-in-picture" allowFullScreen></iframe>
|
||||
|
||||
<br/>
|
||||
|
||||
The final stage was all about polish, which we picked up at the beginning of this year. By leaving a bit of space between the main implementation, or phase two, and the polish phase, phase three, it was much easier to properly scrutinize our past solutions. We forget a lot of the low level reasoning for changes, and it is easier to step back and reconsider parts of the system. For example, we found that our initial design of the `createServiceFactory` function was unnecessarily complex, and could be made much simpler for most usages. In addition to reviewing all the APIs, we also wrote more documentation to help users, ensured that the local development and testing experience was solid, and double checked that there was a smooth migration path from the old system.
|
||||
|
||||
## Architecture
|
||||
|
||||
Now that you’ve learned about the journey of designing the new system, let’s review the new architecture. This blog includes a brief introduction to the architecture of the new system. If you want to dive deeper, check out our [architecture documentation](https://backstage.io/docs/backend-system/architecture/).
|
||||
|
||||
The backend system has five major building blocks:
|
||||
|
||||
- Backend instances act as dependency injection containers and are the unit of deployment in which you install plugins and modules that you want to use.
|
||||
- Plugins implement the actual features and main business logic, for example the service catalog.
|
||||
- Services provide shared utilities for plugins to use, for example logging, database access, and serving HTTP. Services are provided by the backend and can be customized in each backend instance.
|
||||
- Extension Points serve as an optional API surface for plugins to provide deeper customization, such as installing custom processors in the catalog. It is up to each plugin to define their own extension points.
|
||||
- Modules extend individual plugins with additional features by interacting with the extension points that the plugins expose. A module might for example implement a single entity provider for the catalog.
|
||||
|
||||
|
||||
|
||||
## Benefits of the New System
|
||||
|
||||
This new system reduced the size of a typical backend installation from hundreds of lines of code to just about two dozen, more than an order of magnitude. This reduction comes from shifting complexity away from the backend installation and into the plugins, services, and the backend system itself. Not only does this make a typical backend setup much easier to maintain, but it also makes it much easier to build plugins and modules, and leaves fewer patterns to be unnecessarily invented.
|
||||
|
||||
As part of this shift, we’ve moved many concepts from being coding patterns to being features built into the framework. This will allow us to further evolve the backend system in much more interesting ways, and still bring along the entire Backstage plugin ecosystem. It also helps align Backstage plugins around a couple of extensibility patterns, rather than each plugin having their own bespoke patterns for how extensions are installed.
|
||||
|
||||
## Alpha, what does it mean?
|
||||
|
||||
With the release of the backend system into alpha, we are confident enough in the design of the system that we encourage plugin owners to add support for the new system in their plugins. This means following the [plugin migration guide](https://backstage.io/docs/backend-system/building-plugins-and-modules/migrating) and exporting a plugin instance. Do not remove support for the old system yet – keep your existing `createRouter` export intact.
|
||||
|
||||
While we encourage migration of plugins, we do not yet recommend migrating your backend installations to the new system. We want to create space to gather and address feedback from the plugin migration experience, and to make changes if necessary.
|
||||
|
||||
If you are worried about the upcoming backend migration, you can [take a peek](https://backstage.io/docs/backend-system/building-backends/migrating#migrating-the-index-file) at our `legacyPlugin` helper. It allows you to forklift over all existing plugin setups to the new backend system, and then migrate plugins one by one.
|
||||
|
||||
## Next Steps
|
||||
|
||||
During the next release we will keep working on migrating the core plugins, as well as addressing any feedback that we receive. We don’t want to rush a stable release though, and won’t encourage broad adoption until we’re confident that we won’t have to follow it up with immediate breaking changes. Yet, we are excited about where we are today, and are looking forward to the future stable release!
|
||||
|
||||
Useful Links:
|
||||
|
||||
- [Architecture Docs](https://backstage.io/docs/backend-system/architecture/)
|
||||
- [Building Plugins](https://backstage.io/docs/backend-system/building-plugins-and-modules/)
|
||||
- [Core Services](https://backstage.io/docs/backend-system/core-services/)
|
||||
- [#backend-system](https://discord.com/channels/687207715902193673/1034089724664610938) channel in Discord
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 94 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 72 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 77 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 108 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 74 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 1.2 MiB |
Binary file not shown.
|
Before Width: | Height: | Size: 1.1 MiB |
Binary file not shown.
|
Before Width: | Height: | Size: 381 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 211 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 238 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 104 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 92 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 12 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 1.2 MiB |
Binary file not shown.
|
Before Width: | Height: | Size: 193 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 202 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 184 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 361 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 217 KiB |
Binary file not shown.
Binary file not shown.
|
Before Width: | Height: | Size: 223 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 455 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 369 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 82 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 1.3 MiB |
Binary file not shown.
|
Before Width: | Height: | Size: 119 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 1.1 MiB |
Binary file not shown.
|
Before Width: | Height: | Size: 426 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 52 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 82 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 44 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 490 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 40 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 10 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 147 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 1.6 MiB |
Binary file not shown.
|
Before Width: | Height: | Size: 34 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 1.2 MiB |
Binary file not shown.
|
Before Width: | Height: | Size: 125 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 359 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 102 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 147 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 19 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 18 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 23 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 22 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 14 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 14 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 795 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 214 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 266 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 314 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 61 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 97 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 562 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 1.8 MiB |
Binary file not shown.
|
Before Width: | Height: | Size: 131 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 498 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 87 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 1.3 MiB |
Binary file not shown.
|
Before Width: | Height: | Size: 116 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 260 KiB |
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user