diff --git a/docs/FAQ.md b/docs/FAQ.md
index d230e682a4..4b5df3ace0 100644
--- a/docs/FAQ.md
+++ b/docs/FAQ.md
@@ -3,7 +3,7 @@ id: FAQ
title: FAQ
---
-## Product FAQ:
+## Product FAQ
### Can we call Backstage something different? So that it fits our company better?
@@ -67,7 +67,7 @@ valuable as you grow.
Yes! The Backstage UI is built using Material-UI. With the theming capabilities
of Material-UI, you are able to adapt the interface to your brand guidelines.
-## Technical FAQ:
+## Technical FAQ
### Why Material-UI?
diff --git a/docs/README.md b/docs/README.md
index 55e178b691..c63a12b589 100644
--- a/docs/README.md
+++ b/docs/README.md
@@ -1,105 +1,3 @@
-# Documentation structure
+# Documentation
-**Note!** This documentation structure is very much work in progress. If (when,
-really 😆) you find broken links or missing content, please create an issue or,
-better yet, a pull request.
-
-# Plugins
-
-- Overview
- - [What is Backstage?](overview/what-is-backstage.md)
- - [Backstage architecture](overview/architecture-overview.md)
- - [Architecture and terminology](overview/architecture-terminology.md)
- - [Roadmap](overview/roadmap.md)
- - [Vision](overview/vision.md)
- - [Strategies for adopting](overview/adopting.md)
-- Getting started
- - [Running Backstage locally](getting-started/index.md)
- - [Installation](getting-started/installation.md)
- - [Local development](getting-started/development-environment.md)
- - [Demo deployment](https://backstage-demo.roadie.io)
- - Production deployments
- - [Create an App](getting-started/create-an-app.md)
- - App configuration
- - [Configuring App with plugins](getting-started/configure-app-with-plugins.md)
- - [Customize the look-and-feel of your App](getting-started/app-custom-theme.md)
- - Deployment scenarios
- - [Kubernetes](getting-started/deployment-k8s.md)
- - [Other](getting-started/deployment-other.md)
-- Features
- - Software Catalog
- - [Overview](features/software-catalog/index.md)
- - [System model](features/software-catalog/system-model.md)
- - [YAML File Format](features/software-catalog/descriptor-format.md)
- - [Extending the model](features/software-catalog/extending-the-model.md)
- - [External integrations](features/software-catalog/external-integrations.md)
- - [API](features/software-catalog/api.md)
- - Software creation templates
- - [Overview](features/software-templates/index.md)
- - [Adding templates](features/software-templates/adding-templates.md)
- - Extending the Scaffolder:
- - [Overview](features/software-templates/extending/index.md)
- - [Create your own Templater](features/software-templates/extending/create-your-own-templater.md)
- - [Create your own Publisher](features/software-templates/extending/create-your-own-publisher.md)
- - [Create your own Preparer](features/software-templates/extending/create-your-own-preparer.md)
- - Docs-like-code
- - [Overview](features/techdocs/README.md)
- - [Getting Started](features/techdocs/getting-started.md)
- - [Concepts](features/techdocs/concepts.md)
- - [Creating and Publishing Documentation](features/techdocs/creating-and-publishing.md)
- - [FAQ](features/techdocs/FAQ.md)
-- Plugins
- - [Overview](plugins/index.md)
- - [Existing plugins](plugins/existing-plugins.md)
- - [Creating a new plugin](plugins/create-a-plugin.md)
- - [Developing a plugin](plugins/plugin-development.md)
- - [Structure of a plugin](plugins/structure-of-a-plugin.md)
- - Backends and APIs
- - [Proxying](plugins/proxying.md)
- - [Backstage backend plugin](plugins/backend-plugin.md)
- - [Call existing API](plugins/call-existing-api.md)
- - Testing
- - [Overview](plugins/testing.md)
- - Publishing
- - [Open source and NPM](plugins/publishing.md)
- - [Private/internal (non-open source)](plugins/publish-private.md)
-- Configuration
- - [Overview](conf/index.md)
- - [Reading Configuration](conf/reading.md)
- - [Writing Configuration](conf/writing.md)
- - [Defining Configuration](conf/defining.md)
-- Authentication and identity
- - [Overview](auth/index.md)
- - [Add auth provider](auth/add-auth-provider.md)
- - [Auth backend](auth/auth-backend.md)
- - [OAuth](auth/oauth.md)
- - [Glossary](auth/glossary.md)
-- Designing for Backstage
- - [Backstage Design Language System (DLS)](dls/design.md)
- - [Storybook -- reusable UI components](http://backstage.io/storybook)
- - [Contributing to Storybook](dls/contributing-to-storybook.md)
- - [Figma resources](dls/figma.md)
-- API references
- - TypeScript API
- - [Utility APIs](api/utility-apis.md)
- - [Utility API References](reference/utility-apis/README.md)
- - [createPlugin](reference/createPlugin.md)
- - [createPlugin-feature-flags](reference/createPlugin-feature-flags.md)
- - [createPlugin-router](reference/createPlugin-router.md)
- - Backend APIs
- - [Backend](api/backend.md)
-- Tutorials
- - [Overview](tutorials/index.md)
-- Architecture Decision Records (ADRs)
- - [Overview](architecture-decisions/index.md)
- - [ADR001 - Architecture Decision Record (ADR) log](architecture-decisions/adr001-add-adr-log.md)
- - [ADR002 - Default Software Catalog File Format](architecture-decisions/adr002-default-catalog-file-format.md)
- - [ADR003 - Avoid Default Exports and Prefer Named Exports](architecture-decisions/adr003-avoid-default-exports.md)
- - [ADR004 - Module Export Structure](architecture-decisions/adr004-module-export-structure.md)
- - [ADR005 - Catalog Core Entities](architecture-decisions/adr005-catalog-core-entities.md)
- - [ADR006 - Avoid React.FC and React.SFC](architecture-decisions/adr006-avoid-react-fc.md)
- - [ADR007 - Use MSW for Mocking Network Requests](architecture-decisions/adr007-use-msw-to-mock-service-requests.md)
- - [ADR008 - Default Catalog File Name](architecture-decisions/adr008-default-catalog-file-name.md)
-- [Contribute](../CONTRIBUTING.md)
-- [Support](overview/support.md)
-- [FAQ](FAQ.md)
+The Backstage documentation is available at https://backstage.io/docs
diff --git a/docs/architecture-decisions/index.md b/docs/architecture-decisions/index.md
index b02e8deabb..91d2c668d7 100644
--- a/docs/architecture-decisions/index.md
+++ b/docs/architecture-decisions/index.md
@@ -4,8 +4,6 @@ title: Architecture Decision Records (ADR)
sidebar_label: Overview
---
-#
-
The substantial architecture decisions made in the Backstage project lives here.
For more information about ADRs, when to write them, and why, please see
[this blog post](https://engineering.atspotify.com/2020/04/14/when-should-i-write-an-architecture-decision-record/).
@@ -25,7 +23,10 @@ Records should be stored under the `architecture-decisions` directory.
- Submit a pull request
- Address and integrate feedback from the community
- Eventually, assign a number
-- Add the full path of the ADR to the [`mkdocs.yml`](/mkdocs.yml)
+- Add the path of the ADR to the microsite sidebar in
+ [`sidebars.json`](https://github.com/spotify/backstage/blob/master/microsite/sidebars.json)
+- Add the path of the ADR to the
+ [`mkdocs.yml`](https://github.com/spotify/backstage/blob/master/mkdocs.yml)
- Merge the pull request
## Superseding an ADR
diff --git a/docs/getting-started/create-app_output.png b/docs/assets/getting-started/create-app_output.png
similarity index 100%
rename from docs/getting-started/create-app_output.png
rename to docs/assets/getting-started/create-app_output.png
diff --git a/docs/getting-started/create-plugin_output.png b/docs/assets/getting-started/create-plugin_output.png
similarity index 100%
rename from docs/getting-started/create-plugin_output.png
rename to docs/assets/getting-started/create-plugin_output.png
diff --git a/docs/features/software-catalog/bsc-edit.png b/docs/assets/software-catalog/bsc-edit.png
similarity index 100%
rename from docs/features/software-catalog/bsc-edit.png
rename to docs/assets/software-catalog/bsc-edit.png
diff --git a/docs/features/software-catalog/bsc-extend.png b/docs/assets/software-catalog/bsc-extend.png
similarity index 100%
rename from docs/features/software-catalog/bsc-extend.png
rename to docs/assets/software-catalog/bsc-extend.png
diff --git a/docs/features/software-catalog/bsc-register-1.png b/docs/assets/software-catalog/bsc-register-1.png
similarity index 100%
rename from docs/features/software-catalog/bsc-register-1.png
rename to docs/assets/software-catalog/bsc-register-1.png
diff --git a/docs/features/software-catalog/bsc-register-2.png b/docs/assets/software-catalog/bsc-register-2.png
similarity index 100%
rename from docs/features/software-catalog/bsc-register-2.png
rename to docs/assets/software-catalog/bsc-register-2.png
diff --git a/docs/features/software-catalog/bsc-search.png b/docs/assets/software-catalog/bsc-search.png
similarity index 100%
rename from docs/features/software-catalog/bsc-search.png
rename to docs/assets/software-catalog/bsc-search.png
diff --git a/docs/features/software-catalog/bsc-starred.png b/docs/assets/software-catalog/bsc-starred.png
similarity index 100%
rename from docs/features/software-catalog/bsc-starred.png
rename to docs/assets/software-catalog/bsc-starred.png
diff --git a/docs/features/software-catalog/software-model-core-entities.png b/docs/assets/software-catalog/software-model-core-entities.png
similarity index 100%
rename from docs/features/software-catalog/software-model-core-entities.png
rename to docs/assets/software-catalog/software-model-core-entities.png
diff --git a/docs/auth/auth-backend-classes.md b/docs/auth/auth-backend-classes.md
index 42ee48c5e0..9034a3d054 100644
--- a/docs/auth/auth-backend-classes.md
+++ b/docs/auth/auth-backend-classes.md
@@ -1,4 +1,7 @@
-# Authentication Backend Classes Layout and Description
+---
+id: auth-backend-classes
+title: Auth backend classes
+---
## How Does Authentication Work?
diff --git a/docs/auth/oauth.md b/docs/auth/oauth.md
index 6e6dc4da80..b7013a310d 100644
--- a/docs/auth/oauth.md
+++ b/docs/auth/oauth.md
@@ -104,6 +104,8 @@ request an access token.
The following diagram visualizes the flow described in the previous section.
+
+
-
-
diff --git a/docs/features/software-catalog/extending-the-model.md b/docs/features/software-catalog/extending-the-model.md
index ce5ea03b26..8b621f2e44 100644
--- a/docs/features/software-catalog/extending-the-model.md
+++ b/docs/features/software-catalog/extending-the-model.md
@@ -12,7 +12,7 @@ Backstage natively supports tracking of the following component
- Documentation
- Other
-
+
Since these types are likely not the only kind of software you will want to
track in Backstage, it is possible to
@@ -31,9 +31,10 @@ catalog.
It might be tempting to put software that doesn't fit into any of the existing
types into Other. There are a few reasons why we advice against this; firstly,
we have found that it is preferred to match the conceptual model that your
-engineers have when describing your sofware. Secondly, Backstage helps your
-engineers manage their software by integrating the infratrucure tooling through
-plugins. Different plugins are used for managing different types of components.
+engineers have when describing your software. Secondly, Backstage helps your
+engineers manage their software by integrating the infrastructure tooling
+through plugins. Different plugins are used for managing different types of
+components.
For example, the
[Lighthouse plugin](https://github.com/spotify/backstage/tree/master/plugins/lighthouse)
diff --git a/docs/features/software-catalog/index.md b/docs/features/software-catalog/index.md
index fe107d1f59..db8c183390 100644
--- a/docs/features/software-catalog/index.md
+++ b/docs/features/software-catalog/index.md
@@ -1,6 +1,7 @@
---
id: software-catalog-overview
title: Backstage Service Catalog (alpha)
+sidebar_label: Backstage Service Catalog
---
## What is a Service Catalog?
@@ -54,18 +55,18 @@ There are 3 ways to add components to the catalog:
Users can register new components by going to `/create` and clicking the
**REGISTER EXISTING COMPONENT** button:
-
+
Backstage expects the full URL to the YAML in your source control. Example:
-```
+```bash
https://github.com/spotify/backstage/blob/master/packages/catalog-model/examples/artist-lookup-component.yaml
```
_More examples can be found
[here](https://github.com/spotify/backstage/tree/master/packages/catalog-model/examples)._
-
+
It is important to note that any kind of software can be registered in
Backstage. Even if the software is not maintained by your company (SaaS
@@ -83,7 +84,7 @@ registered in the catalog.
Teams owning the components are responsible for maintaining the metadata about
them, and do so using their normal Git workflow.
-
+
Once the change has been merged, Backstage will automatically show the updated
metadata in the service catalog after a short while.
@@ -92,25 +93,25 @@ metadata in the service catalog after a short while.
By default the service catalog shows components owned by the team of the logged
in user. But you can also switch to _All_ to see all the components across your
-companie's software ecosystem. Basic inline _search_ and _column filtering_
-makes it easy to browse a big set of components.
+company's software ecosystem. Basic inline _search_ and _column filtering_ makes
+it easy to browse a big set of components.
-
+
## Starring components
For easy and quick access to components you visit frequently, Backstage supports
_starring_ of components:
-
+
## Integrated tooling through plugins
-The service catalog is a great way to organise the infrastructure tools you use
+The service catalog is a great way to organize the infrastructure tools you use
to manage the software. 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
+infrastructure UIs (and incurring additional cognitive overhead each time they
+make a context switch), most of these tools can be organized around the entities
in the catalog.
diff --git a/docs/features/software-catalog/system-model.md b/docs/features/software-catalog/system-model.md
index 435fe05b48..4436f60fc2 100644
--- a/docs/features/software-catalog/system-model.md
+++ b/docs/features/software-catalog/system-model.md
@@ -16,11 +16,13 @@ We model software in the Backstage catalogue using these three core entities
(further explained below):
- **Components** are individual pieces of software
+
- **APIs** are the boundaries between different components
+
- **Resources** are physical or virtual infrastructure needed to operate a
component
-
+
### Component
@@ -29,22 +31,22 @@ backend service or data pipeline (list not exhaustive). A component can be
tracked in source control, or use some existing open source or commercial
software.
-A component can implement APIs for other components to consume. In turn it
-might depend on APIs implemented by other components, or resources that are
-attached to it at runtime.
+A component can implement APIs for other components to consume. In turn it might
+depend on APIs implemented by other components, or resources that are attached
+to it at runtime.
### API
APIs form an important (maybe the most important) abstraction that allows large
software ecosystems to scale. Thus, APIs are a first class citizen in the
-Backstage model and the primary way to discover existing functionality in
-the ecosystem.
+Backstage model and the primary way to discover existing functionality in the
+ecosystem.
APIs are implemented by components and form boundaries between components. They
-might be defined using an RPC IDL (eg Protobuf, GraphQL, ...), a data schema
-(eg Avro, TFRecord, ...), or as code interfaces. In any case, APIs exposed by
-components need to be in a known machine-readable format so we can
-build further tooling and analysis on top.
+might be defined using an RPC IDL (eg Protobuf, GraphQL, ...), a data schema (eg
+Avro, TFRecord, ...), or as code interfaces. In any case, APIs exposed by
+components need to be in a known machine-readable format so we can build further
+tooling and analysis on top.
APIs have a visibility: they are either public (making them available for any
other component to consume), restricted (only available to a whitelisted set of
@@ -62,12 +64,13 @@ footprint, and create tooling around them.
## Ecosystem Modeling
-A large catalogue of components, APIs and resources can be highly granular
-and hard to understand as a whole. It might thus be convenient to further
-categorize these entities using the following (optional) concepts:
-* **Systems** are a collection of entities that cooperate to perform some
- function
-* **Domains** relate entities and systems to part of the business
+A large catalogue of components, APIs and resources can be highly granular and
+hard to understand as a whole. It might thus be convenient to further categorize
+these entities using the following (optional) concepts:
+
+- **Systems** are a collection of entities that cooperate to perform some
+ function
+- **Domains** relate entities and systems to part of the business
### System
@@ -82,15 +85,16 @@ exposes one or several public APIs. The main benefit of modelling a system is
that it hides its resources and private APIs between the components for any
consumers. This means that as the owner, you can evolve the implementation, in
terms of components and resources, without your consumers being able to notice.
-Typically, a system will consist of at most a handful of components (see
-Domain for a grouping of systems).
+Typically, a system will consist of at most a handful of components (see Domain
+for a grouping of systems).
-For example, a playlist management system might encapsulate a backend service
-to update playlists, a backend service to query them, and a database to store
-them. It could expose an RPC API, a daily snapshots dataset, and an event
-stream of playlist updates.
+For example, a playlist management system might encapsulate a backend service to
+update playlists, a backend service to query them, and a database to store them.
+It could expose an RPC API, a daily snapshots dataset, and an event stream of
+playlist updates.
### Domain
+
While systems are the basic level of encapsulation for related entities, it is
often useful to group a collection of systems that share terminology, domain
models, metrics, KPIs, business purpose, or documentation, i.e. they form a
diff --git a/docs/getting-started/development-environment.md b/docs/getting-started/development-environment.md
index 6a3a2cc7a2..421ce6d2c5 100644
--- a/docs/getting-started/development-environment.md
+++ b/docs/getting-started/development-environment.md
@@ -85,7 +85,3 @@ yarn create-plugin # Create a new plugin
> See
> [package.json](https://github.com/spotify/backstage/blob/master/package.json)
> for other yarn commands/options.
-
-[Next Step - Create a Backstage plugin](../plugins/create-a-plugin.md)
-
-[Back to Docs](../README.md)
diff --git a/docs/overview/background.md b/docs/overview/background.md
new file mode 100644
index 0000000000..ef226653fb
--- /dev/null
+++ b/docs/overview/background.md
@@ -0,0 +1,30 @@
+---
+id: background
+title: The Spotify Story
+---
+
+Backstage was born out of necessity at Spotify. We found that as we grew, our
+infrastructure was becoming more fragmented, our engineers less productive.
+
+Instead of building and testing code, teams were spending more time looking for
+the right information just to get started. “Where’s the API for that service
+we’re all supposed to be using?” “What version of that framework is everyone
+on?” “This service isn’t responding, who owns it?” “I can’t find documentation
+for anything!”
+
+Context switching and cognitive overload were dragging engineers down, day by
+day. We needed to make it easier for our engineers to do their work without
+having to become an expert in every aspect of infrastructure tooling.
+
+Our idea was to centralize and simplify end-to-end software development with an
+abstraction layer that sits on top of all of our infrastructure and developer
+tooling. That’s Backstage.
+
+It’s a developer portal powered by a centralized service catalog — with a plugin
+architecture that makes it endlessly extensible and customizable.
+
+Manage all your services, software, tooling, and testing in Backstage. Start
+building a new microservice using an automated template in Backstage. Create,
+maintain, and find the documentation for all that software in Backstage.
+
+One place for everything. Accessible to everyone.
diff --git a/docs/plugins/create-a-plugin.md b/docs/plugins/create-a-plugin.md
index 0ca83b076c..4bcc4da387 100644
--- a/docs/plugins/create-a-plugin.md
+++ b/docs/plugins/create-a-plugin.md
@@ -15,20 +15,16 @@ dependencies, then run the following on your command line (invoking the
yarn create-plugin
```
-
- 
-
+
This will create a new Backstage Plugin based on the ID that was provided. It
will be built and added to the Backstage App automatically.
-_If `yarn start` is already running you should be able to see the default page
-for your new plugin directly by navigating to
-`http://localhost:3000/my-plugin`._
+> If `yarn start` is already running you should be able to see the default page
+> for your new plugin directly by navigating to
+> `http://localhost:3000/my-plugin`.
-
- 
-
+
You can also serve the plugin in isolation by running `yarn start` in the plugin
directory. Or by using the yarn workspace command, for example:
@@ -40,7 +36,3 @@ yarn workspace @backstage/plugin-welcome start # Also supports --check
This method of serving the plugin provides quicker iteration speed and a faster
startup and hot reloads. It is only meant for local development, and the setup
for it can be found inside the plugin's `dev/` directory.
-
-[Next Step - Structure of a plugin](structure-of-a-plugin.md)
-
-[Back to Getting Started](../README.md)
diff --git a/docs/plugins/plugin-development.md b/docs/plugins/plugin-development.md
index b5c3240de0..faf3c6ddbd 100644
--- a/docs/plugins/plugin-development.md
+++ b/docs/plugins/plugin-development.md
@@ -1,6 +1,6 @@
---
id: plugin-development
-title: Plugin Development in Backstage
+title: Plugin Development
---
Backstage plugins provide features to a Backstage App.
@@ -10,28 +10,12 @@ type of content. Plugins all use a common set of platform APIs and reusable UI
components. Plugins can fetch data from external sources using the regular
browser APIs or by depending on external modules to do the work.
-
-
## Developing guidelines
- Consider writing plugins in `TypeScript`.
- Plan the directory structure of your plugin so that it becomes easy to manage.
-- Prefer using the Backstage components, otherwise go with
- [Material-UI](https://material-ui.com/).
+- Prefer using the [Backstage components](https://backstage.io/storybook),
+ otherwise go with [Material-UI](https://material-ui.com/).
- Check out the shared Backstage APIs before building a new one.
## Plugin concepts / API
diff --git a/docs/reference/createPlugin-router.md b/docs/reference/createPlugin-router.md
index ebefa13bb0..361b485df9 100644
--- a/docs/reference/createPlugin-router.md
+++ b/docs/reference/createPlugin-router.md
@@ -37,5 +37,3 @@ const myPluginRouteRef = createRouteRef({
title: 'My Plugin',
});
```
-
-[Back to References](../README.md)
diff --git a/docs/tutorials/index.md b/docs/tutorials/index.md
deleted file mode 100644
index b5780875b2..0000000000
--- a/docs/tutorials/index.md
+++ /dev/null
@@ -1,6 +0,0 @@
----
-id: index
-title: Overview
----
-
-## Coming soon!
diff --git a/docs/journey.md b/docs/tutorials/journey.md
similarity index 94%
rename from docs/journey.md
rename to docs/tutorials/journey.md
index e38130afb7..3c399c53ba 100644
--- a/docs/journey.md
+++ b/docs/tutorials/journey.md
@@ -1,12 +1,15 @@
-# Purpose
+---
+id: journey
+title: Future developer journey
+---
-This RFC describes a possible journey of a future Backstage plugin developer as
-they build a plugin that touches many different aspects of a Backstage. The
-story invents many new things that are not part of Backstage today, but are
-things that I'm suggesting we should add as long term or north star goals. The
-idea is to discuss what parts of the story makes sense to aim for, and what we'd
-want to do differently or not at all. The "chapters" are numbered to make it a
-bit easier to comment on parts of the story.
+> This document describes a possible journey of a **_future_** Backstage plugin
+> developer as they build a plugin that touches many different aspects of a
+> Backstage. The story invents many new things that are not part of Backstage
+> today, but are things that I'm suggesting we should add as long term or north
+> star goals. The idea is to discuss what parts of the story makes sense to aim
+> for, and what we'd want to do differently or not at all. The "chapters" are
+> numbered to make it a bit easier to comment on parts of the story.
# The Protagonist
diff --git a/microsite/i18n/en.json b/microsite/i18n/en.json
index 96c874f496..9d83dfcef9 100644
--- a/microsite/i18n/en.json
+++ b/microsite/i18n/en.json
@@ -51,7 +51,7 @@
"title": "Adding authentication providers"
},
"auth/auth-backend-classes": {
- "title": "auth/auth-backend-classes"
+ "title": "Auth backend classes"
},
"auth/auth-backend": {
"title": "Auth backend"
@@ -103,7 +103,8 @@
"title": "External integrations"
},
"features/software-catalog/software-catalog-overview": {
- "title": "Backstage Service Catalog (alpha)"
+ "title": "Backstage Service Catalog (alpha)",
+ "sidebar_label": "Backstage Service Catalog"
},
"features/software-catalog/installation": {
"title": "features/software-catalog/installation"
@@ -174,9 +175,6 @@
"getting-started/installation": {
"title": "Installation"
},
- "journey": {
- "title": "journey"
- },
"overview/adopting": {
"title": "Strategies for adopting"
},
@@ -186,6 +184,9 @@
"overview/architecture-terminology": {
"title": "Architecture terminology"
},
+ "overview/background": {
+ "title": "The Spotify Story"
+ },
"overview/roadmap": {
"title": "Project roadmap"
},
@@ -214,7 +215,7 @@
"title": "Intro to plugins"
},
"plugins/plugin-development": {
- "title": "Plugin Development in Backstage"
+ "title": "Plugin Development"
},
"plugins/proxying": {
"title": "Proxying"
@@ -285,8 +286,8 @@
"reference/utility-apis/StorageApi": {
"title": "reference/utility-apis/StorageApi"
},
- "tutorials/index": {
- "title": "Overview"
+ "tutorials/journey": {
+ "title": "Future developer journey"
}
},
"links": {
@@ -294,7 +295,6 @@
"Docs": "Docs",
"Blog": "Blog",
"Demos": "Demos",
- "The Spotify story": "The Spotify story",
"Newsletter": "Newsletter"
},
"categories": {
diff --git a/microsite/pages/en/background.js b/microsite/pages/en/background.js
deleted file mode 100644
index c5bf9bee94..0000000000
--- a/microsite/pages/en/background.js
+++ /dev/null
@@ -1,122 +0,0 @@
-/**
- * Copyright (c) 2017-present, Facebook, Inc.
- *
- * This source code is licensed under the MIT license found in the
- * LICENSE file in the root directory of this source tree.
- */
-
-const React = require('react');
-const Components = require(`${process.cwd()}/core/Components.js`);
-const Block = Components.Block;
-const Breakpoint = Components.Breakpoint;
-
-const Background = props => {
- const { config: siteConfig } = props;
- const { baseUrl } = siteConfig;
- return (
-
-
-
- The Spotify Story
-
-
- Backstage was born out of necessity at Spotify. We found that as
- we grew, our infrastructure was becoming more fragmented, our
- engineers less productive.{' '}
-
-
-
- Instead of building and testing code, teams were spending more
- time looking for the right information just to get started.
- “Where’s the API for that service we’re all supposed to be using?”
- “What version of that framework is everyone on?” “This service
- isn’t responding, who owns it?” “I can’t find documentation for
- anything!”{' '}
-
-
-
-
-
-
- One place for everything. Accessible to everyone.
-
-
-
- }
- >
-
- Context switching and cognitive overload were dragging engineers
- down, day by day. We needed to make it easier for our engineers to
- do their work without having to become an expert in every aspect
- of infrastructure tooling.
-
-
-
- Our idea was to centralize and simplify end-to-end software
- development with an abstraction layer that sits on top of all of
- our infrastructure and developer tooling. That’s Backstage.
-
-
-
- It’s a developer portal powered by a centralized service catalog —
- with a plugin architecture that makes it endlessly extensible and
- customizable.
-
-
-
- Manage all your services, software, tooling, and testing in
- Backstage. Start building a new microservice using an automated
- template in Backstage. Create, maintain, and find the
- documentation for all that software in Backstage.{' '}
-
-
-
- One place for everything. Accessible to everyone.
-
-
-
- Explore Features
-
-
- }
- >
-
-
-
-
-
-
-
-
- One place for everything. Accessible to everyone.
-
-
- Explore Features
-
-
-
- }
- >
-
-
-