diff --git a/.eslintignore b/.eslintignore
index dcf11353ec..2f59b98bca 100644
--- a/.eslintignore
+++ b/.eslintignore
@@ -5,3 +5,4 @@
**/build/**
**/.git/**
**/public/**
+**/microsite/**
diff --git a/.github/ISSUE_TEMPLATE/feature_template.md b/.github/ISSUE_TEMPLATE/feature_template.md
index 012b8d7a06..d70622bf52 100644
--- a/.github/ISSUE_TEMPLATE/feature_template.md
+++ b/.github/ISSUE_TEMPLATE/feature_template.md
@@ -1,7 +1,7 @@
---
name: 'Feature Request'
about: 'Suggest new features and changes'
-labels: help wanted
+labels: enhancement
---
diff --git a/.github/workflows/chromatic-storybook-test.yml b/.github/workflows/chromatic-storybook-test.yml
index e38b494a73..0bcaf400d0 100644
--- a/.github/workflows/chromatic-storybook-test.yml
+++ b/.github/workflows/chromatic-storybook-test.yml
@@ -14,7 +14,37 @@ jobs:
- uses: actions/checkout@v2
with:
fetch-depth: 0 # Required to retrieve git history
- - run: yarn install && yarn build-storybook
+
+ # Beginning of yarn setup, keep in sync between all workflows, see ci.yml
+ - name: use node.js ${{ matrix.node-version }}
+ uses: actions/setup-node@v1
+ with:
+ node-version: ${{ matrix.node-version }}
+ registry-url: https://registry.npmjs.org/ # Needed for auth
+ - name: cache all node_modules
+ id: cache-modules
+ uses: actions/cache@v2
+ with:
+ path: '**/node_modules'
+ key: ${{ runner.os }}-node_modules-${{ hashFiles('yarn.lock', '**/package.json') }}
+ - name: find location of global yarn cache
+ id: yarn-cache
+ if: steps.cache-modules.outputs.cache-hit != 'true'
+ run: echo "::set-output name=dir::$(yarn cache dir)"
+ - name: cache global yarn cache
+ uses: actions/cache@v2
+ if: steps.cache-modules.outputs.cache-hit != 'true'
+ with:
+ path: ${{ steps.yarn-cache.outputs.dir }}
+ key: ${{ runner.os }}-yarn-${{ hashFiles('yarn.lock') }}
+ restore-keys: |
+ ${{ runner.os }}-yarn-
+ - name: yarn install
+ run: yarn install --frozen-lockfile
+ # End of yarn setup
+
+ - run: yarn build-storybook
+
- uses: chromaui/action@v1
with:
token: ${{ secrets.GITHUB_TOKEN }}
diff --git a/.github/workflows/frontend.yml b/.github/workflows/ci.yml
similarity index 60%
rename from .github/workflows/frontend.yml
rename to .github/workflows/ci.yml
index 0137e4b9dc..492b008431 100644
--- a/.github/workflows/frontend.yml
+++ b/.github/workflows/ci.yml
@@ -1,10 +1,11 @@
-name: Frontend CI
+name: CI
on:
pull_request:
-
+ paths-ignore:
+ - 'microsite/**'
jobs:
- build:
+ verify:
runs-on: ubuntu-latest
strategy:
@@ -19,33 +20,54 @@ jobs:
- uses: actions/checkout@v2
- name: fetch branch master
run: git fetch origin master
- - name: find location of global yarn cache
- id: yarn-cache
- run: echo "::set-output name=dir::$(yarn cache dir)"
- - name: cache global yarn cache
- uses: actions/cache@v2
- with:
- path: ${{ steps.yarn-cache.outputs.dir }}
- key: ${{ runner.os }}-yarn-${{ hashFiles('**/yarn.lock') }}
- restore-keys: |
- ${{ runner.os }}-yarn-
- - name: cache node_modules
- uses: actions/cache@v2
- with:
- path: node_modules
- key: ${{ runner.os }}-modules-${{ hashFiles('yarn.lock') }}
+
+ # Beginning of yarn setup, keep in sync between all workflows.
+ # TODO(Rugvip): move this to composite action once all features we use are supported
- name: use node.js ${{ matrix.node-version }}
uses: actions/setup-node@v1
with:
node-version: ${{ matrix.node-version }}
+ registry-url: https://registry.npmjs.org/ # Needed for auth
+
+ # Cache every node_modules folder inside the monorepo
+ - name: cache all node_modules
+ id: cache-modules
+ uses: actions/cache@v2
+ with:
+ path: '**/node_modules'
+ # We use both yarn.lock and package.json as cache keys to ensure that
+ # changes to local monorepo packages bust the cache.
+ key: ${{ runner.os }}-node_modules-${{ hashFiles('yarn.lock', '**/package.json') }}
+
+ # If we get a cache hit for node_modules, there's no need to bring in the global
+ # yarn cache or run yarn install, as all dependencies will be installed already.
+
+ - name: find location of global yarn cache
+ id: yarn-cache
+ if: steps.cache-modules.outputs.cache-hit != 'true'
+ run: echo "::set-output name=dir::$(yarn cache dir)"
+
+ - name: cache global yarn cache
+ uses: actions/cache@v2
+ if: steps.cache-modules.outputs.cache-hit != 'true'
+ with:
+ path: ${{ steps.yarn-cache.outputs.dir }}
+ key: ${{ runner.os }}-yarn-${{ hashFiles('yarn.lock') }}
+ restore-keys: |
+ ${{ runner.os }}-yarn-
+
+ - name: yarn install
+ if: steps.cache-modules.outputs.cache-hit != 'true'
+ run: yarn install --frozen-lockfile
+ # End of yarn setup
- name: check for yarn.lock changes
id: yarn-lock
run: git diff --quiet origin/master HEAD -- yarn.lock
continue-on-error: true
- - name: yarn install
- run: yarn install --frozen-lockfile
+ - name: verify doc links
+ run: node docs/verify-links.js
- name: lint
run: yarn lerna -- run lint --since origin/master
@@ -55,8 +77,7 @@ jobs:
- name: build changed packages
if: ${{ steps.yarn-lock.outcome == 'success' }}
- # Need to build all dependencies as well to be able to run tests later
- run: yarn lerna -- run build --since origin/master --include-dependencies
+ run: yarn lerna -- run build --since origin/master
- name: build all packages
if: ${{ steps.yarn-lock.outcome == 'failure' }}
@@ -75,6 +96,3 @@ jobs:
- name: verify plugin template
run: yarn lerna -- run diff -- --check
-
- - name: verify storybook
- run: yarn workspace storybook build-storybook
diff --git a/.github/workflows/cli-win.yml b/.github/workflows/e2e-win.yml
similarity index 66%
rename from .github/workflows/cli-win.yml
rename to .github/workflows/e2e-win.yml
index 4e7a186282..5ebf67bc9a 100644
--- a/.github/workflows/cli-win.yml
+++ b/.github/workflows/e2e-win.yml
@@ -1,12 +1,13 @@
-name: CLI Test Windows
+name: E2E Test Windows
-# Building on windows is really slow, so this workflow is separate from cli.yml and only builds on changes
+# Building on windows is really slow, so this workflow is separate from e2e.yml and only builds on changes
# to the cli itself. They're more likely to introduce issues on windows, compared to changes to core and yarn.lock.
on:
pull_request:
paths:
- - '.github/workflows/cli-win.yml'
+ - '.github/workflows/e2e-win.yml'
- 'packages/cli/**'
+ - 'packages/e2e/**'
- 'packages/create-app/**'
jobs:
@@ -25,6 +26,13 @@ jobs:
name: Node ${{ matrix.node-version }} on ${{ matrix.os }}
steps:
- uses: actions/checkout@v2
+
+ # Beginning of yarn setup, keep in sync between all workflows, see ci.yml
+ - name: use node.js ${{ matrix.node-version }}
+ uses: actions/setup-node@v1
+ with:
+ node-version: ${{ matrix.node-version }}
+ registry-url: https://registry.npmjs.org/ # Needed for auth
- name: find location of global yarn cache
id: yarn-cache
run: echo "::set-output name=dir::$(yarn cache dir)"
@@ -32,16 +40,15 @@ jobs:
uses: actions/cache@v2
with:
path: ${{ steps.yarn-cache.outputs.dir }}
- key: ${{ runner.os }}-yarn-${{ hashFiles('**/yarn.lock') }}
+ key: ${{ runner.os }}-yarn-${{ hashFiles('yarn.lock') }}
restore-keys: |
${{ runner.os }}-yarn-
- - name: use node.js ${{ matrix.node-version }}
- uses: actions/setup-node@v1
- with:
- node-version: ${{ matrix.node-version }}
- name: yarn install
run: yarn install --frozen-lockfile
+ # End of yarn setup
+
- run: yarn tsc
- - run: yarn build
- - name: verify app and plugin creation
- run: node ${{ github.workspace }}/packages/cli/e2e-test/cli-e2e-test.js
+ - name: yarn build
+ run: yarn build --ignore example-app --ignore example-backend --ignore @techdocs/cli --ignore backstage-microsite
+ - name: run E2E test
+ run: yarn workspace e2e-test start
diff --git a/.github/workflows/cli.yml b/.github/workflows/e2e.yml
similarity index 64%
rename from .github/workflows/cli.yml
rename to .github/workflows/e2e.yml
index 6e4fdad214..401fe7297a 100644
--- a/.github/workflows/cli.yml
+++ b/.github/workflows/e2e.yml
@@ -1,14 +1,9 @@
-name: CLI Test
+name: E2E Test Linux
on:
pull_request:
- paths:
- - '.github/workflows/cli.yml'
- - 'packages/cli/**'
- - 'packages/create-app/**'
- - 'packages/core/**'
- - 'packages/core-api/**'
- - 'yarn.lock'
+ paths-ignore:
+ - 'microsite/**'
jobs:
build:
@@ -38,30 +33,44 @@ jobs:
name: Node ${{ matrix.node-version }} on ${{ matrix.os }}
steps:
- uses: actions/checkout@v2
- - name: find location of global yarn cache
- id: yarn-cache
- run: echo "::set-output name=dir::$(yarn cache dir)"
- - name: cache global yarn cache
- uses: actions/cache@v2
- with:
- path: ${{ steps.yarn-cache.outputs.dir }}
- key: ${{ runner.os }}-yarn-${{ hashFiles('**/yarn.lock') }}
- restore-keys: |
- ${{ runner.os }}-yarn-
+
+ # Beginning of yarn setup, keep in sync between all workflows, see ci.yml
- name: use node.js ${{ matrix.node-version }}
uses: actions/setup-node@v1
with:
node-version: ${{ matrix.node-version }}
+ registry-url: https://registry.npmjs.org/ # Needed for auth
+ - name: cache all node_modules
+ id: cache-modules
+ uses: actions/cache@v2
+ with:
+ path: '**/node_modules'
+ key: ${{ runner.os }}-node_modules-${{ hashFiles('yarn.lock', '**/package.json') }}
+ - name: find location of global yarn cache
+ id: yarn-cache
+ if: steps.cache-modules.outputs.cache-hit != 'true'
+ run: echo "::set-output name=dir::$(yarn cache dir)"
+ - name: cache global yarn cache
+ uses: actions/cache@v2
+ if: steps.cache-modules.outputs.cache-hit != 'true'
+ with:
+ path: ${{ steps.yarn-cache.outputs.dir }}
+ key: ${{ runner.os }}-yarn-${{ hashFiles('yarn.lock') }}
+ restore-keys: |
+ ${{ runner.os }}-yarn-
- name: yarn install
run: yarn install --frozen-lockfile
+ # End of yarn setup
+
- run: yarn tsc
- - run: yarn build
- - name: verify app and plugin creation
+ - name: yarn build
+ run: yarn build --ignore example-app --ignore example-backend --ignore @techdocs/cli --ignore backstage-microsite
+ - name: run E2E test
+ run: |
+ sudo sysctl fs.inotify.max_user_watches=524288
+ yarn workspace e2e-test start
env:
POSTGRES_HOST: localhost
POSTGRES_PORT: ${{ job.services.postgres.ports[5432] }}
POSTGRES_USER: postgres
POSTGRES_PASSWORD: postgres
- run: |
- sudo sysctl fs.inotify.max_user_watches=524288
- node ${{ github.workspace }}/packages/cli/e2e-test/cli-e2e-test.js
diff --git a/.github/workflows/master-win.yml b/.github/workflows/master-win.yml
new file mode 100644
index 0000000000..296a7511bc
--- /dev/null
+++ b/.github/workflows/master-win.yml
@@ -0,0 +1,45 @@
+name: Master Build Windows
+
+on:
+ push:
+ branches: [master]
+
+jobs:
+ build:
+ runs-on: windows-latest
+
+ strategy:
+ matrix:
+ node-version: [12.x]
+
+ env:
+ CI: true
+ NODE_OPTIONS: --max-old-space-size=4096
+
+ steps:
+ - uses: actions/checkout@v2
+
+ # Beginning of yarn setup, keep in sync between all workflows, see ci.yml
+ - name: use node.js ${{ matrix.node-version }}
+ uses: actions/setup-node@v1
+ with:
+ node-version: ${{ matrix.node-version }}
+ registry-url: https://registry.npmjs.org/ # Needed for auth
+ - name: find location of global yarn cache
+ id: yarn-cache
+ run: echo "::set-output name=dir::$(yarn cache dir)"
+ - name: cache global yarn cache
+ uses: actions/cache@v2
+ with:
+ path: ${{ steps.yarn-cache.outputs.dir }}
+ key: ${{ runner.os }}-yarn-${{ hashFiles('yarn.lock') }}
+ restore-keys: |
+ ${{ runner.os }}-yarn-
+ - name: yarn install
+ run: yarn install --frozen-lockfile
+ # End of yarn setup
+
+
+# Tests are broken on Windows, disabled for now
+ # - name: test
+ # run: yarn lerna -- run test
diff --git a/.github/workflows/master.yml b/.github/workflows/master.yml
index 3ef0c1fee3..354838037e 100644
--- a/.github/workflows/master.yml
+++ b/.github/workflows/master.yml
@@ -1,4 +1,4 @@
-name: Master Build
+name: Main Master Build
on:
push:
@@ -18,29 +18,34 @@ jobs:
steps:
- uses: actions/checkout@v2
- - name: find location of global yarn cache
- id: yarn-cache
- run: echo "::set-output name=dir::$(yarn cache dir)"
- - name: cache global yarn cache
- uses: actions/cache@v2
- with:
- path: ${{ steps.yarn-cache.outputs.dir }}
- key: ${{ runner.os }}-yarn-${{ hashFiles('**/yarn.lock') }}
- restore-keys: |
- ${{ runner.os }}-yarn-
- - name: cache node_modules
- uses: actions/cache@v2
- with:
- path: node_modules
- key: ${{ runner.os }}-modules-${{ hashFiles('yarn.lock') }}
+
+ # Beginning of yarn setup, keep in sync between all workflows, see ci.yml
- name: use node.js ${{ matrix.node-version }}
uses: actions/setup-node@v1
with:
node-version: ${{ matrix.node-version }}
registry-url: https://registry.npmjs.org/ # Needed for auth
-
+ - name: cache all node_modules
+ id: cache-modules
+ uses: actions/cache@v2
+ with:
+ path: '**/node_modules'
+ key: ${{ runner.os }}-node_modules-${{ hashFiles('yarn.lock', '**/package.json') }}
+ - name: find location of global yarn cache
+ id: yarn-cache
+ if: steps.cache-modules.outputs.cache-hit != 'true'
+ run: echo "::set-output name=dir::$(yarn cache dir)"
+ - name: cache global yarn cache
+ uses: actions/cache@v2
+ if: steps.cache-modules.outputs.cache-hit != 'true'
+ with:
+ path: ${{ steps.yarn-cache.outputs.dir }}
+ key: ${{ runner.os }}-yarn-${{ hashFiles('yarn.lock') }}
+ restore-keys: |
+ ${{ runner.os }}-yarn-
- name: yarn install
run: yarn install --frozen-lockfile
+ # End of yarn setup
- name: lint
run: yarn lerna -- run lint
@@ -69,3 +74,11 @@ jobs:
GITHUB_TOKEN: "${{ secrets.GITHUB_TOKEN }}"
package_root: "packages/core"
tag_prefix: "v"
+
+ - name: Discord notification
+ if: ${{ failure() }}
+ uses: Ilshidur/action-discord@0.2.0
+ env:
+ DISCORD_WEBHOOK: ${{ secrets.DISCORD_WEBHOOK }}
+ with:
+ args: 'Master build failed https://github.com/{{GITHUB_REPOSITORY}}/actions/runs/{{GITHUB_RUN_ID}}'
diff --git a/.github/workflows/storybook-deploy.yml b/.github/workflows/microsite-build-check.yml
similarity index 55%
rename from .github/workflows/storybook-deploy.yml
rename to .github/workflows/microsite-build-check.yml
index 33ffba5ccd..dc86ca2630 100644
--- a/.github/workflows/storybook-deploy.yml
+++ b/.github/workflows/microsite-build-check.yml
@@ -1,16 +1,14 @@
-name: Deploy Storybook
+name: Build microsite
on:
- push:
- branches:
- - master
+ pull_request:
paths:
- - '.github/workflows/storybook-deploy.yml'
- - 'packages/storybook/**'
- - 'packages/core/src/**'
+ - '.github/workflows/microsite-build-check.yml'
+ - 'microsite/**'
+ - 'docs/**'
jobs:
- deploy-storybook:
+ build-microsite:
runs-on: ubuntu-latest
strategy:
@@ -23,34 +21,34 @@ jobs:
steps:
- uses: actions/checkout@v2
- - name: find location of global yarn cache
- id: yarn-cache
- run: echo "::set-output name=dir::$(yarn cache dir)"
- - name: cache global yarn cache
- uses: actions/cache@v2
- with:
- path: ${{ steps.yarn-cache.outputs.dir }}
- key: ${{ runner.os }}-yarn-${{ hashFiles('**/yarn.lock') }}
- restore-keys: |
- ${{ runner.os }}-yarn-
- - name: cache node_modules
- uses: actions/cache@v2
- with:
- path: node_modules
- key: ${{ runner.os }}-modules-${{ hashFiles('yarn.lock') }}
+ # Beginning of yarn setup, keep in sync between all workflows, see ci.yml
- name: use node.js ${{ matrix.node-version }}
uses: actions/setup-node@v1
with:
node-version: ${{ matrix.node-version }}
registry-url: https://registry.npmjs.org/ # Needed for auth
+ - name: cache all node_modules
+ id: cache-modules
+ uses: actions/cache@v2
+ with:
+ path: '**/node_modules'
+ key: ${{ runner.os }}-node_modules-${{ hashFiles('yarn.lock', '**/package.json') }}
+ - name: find location of global yarn cache
+ id: yarn-cache
+ if: steps.cache-modules.outputs.cache-hit != 'true'
+ run: echo "::set-output name=dir::$(yarn cache dir)"
+ - name: cache global yarn cache
+ uses: actions/cache@v2
+ if: steps.cache-modules.outputs.cache-hit != 'true'
+ with:
+ path: ${{ steps.yarn-cache.outputs.dir }}
+ key: ${{ runner.os }}-yarn-${{ hashFiles('yarn.lock') }}
+ restore-keys: |
+ ${{ runner.os }}-yarn-
- name: yarn install
run: yarn install --frozen-lockfile
- - name: build storybook
- run: yarn workspace storybook build-storybook
- - name: deploy storybook to gh-pages
- uses: JamesIves/github-pages-deploy-action@3.4.2
- with:
- GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
- BRANCH: gh-pages
- FOLDER: packages/storybook/dist
+ # End of yarn setup
+
+ - name: build microsite
+ run: yarn workspace backstage-microsite build
diff --git a/.github/workflows/microsite-with-storybook-deploy.yml b/.github/workflows/microsite-with-storybook-deploy.yml
new file mode 100644
index 0000000000..2c8b8af40c
--- /dev/null
+++ b/.github/workflows/microsite-with-storybook-deploy.yml
@@ -0,0 +1,74 @@
+name: Deploy Microsite and Storybook
+
+on:
+ push:
+ branches:
+ - master
+ paths:
+ - '.github/workflows/microsite-with-storybook-deploy.yml'
+ - 'packages/storybook/**'
+ - 'packages/core/src/**'
+ - 'microsite/**'
+ - 'docs/**'
+
+jobs:
+ deploy-microsite-and-storybook:
+ runs-on: ubuntu-latest
+
+ strategy:
+ matrix:
+ node-version: [12.x]
+
+ env:
+ CI: true
+ NODE_OPTIONS: --max-old-space-size=4096
+
+ steps:
+ - uses: actions/checkout@v2
+
+ # Beginning of yarn setup, keep in sync between all workflows, see ci.yml
+ - name: use node.js ${{ matrix.node-version }}
+ uses: actions/setup-node@v1
+ with:
+ node-version: ${{ matrix.node-version }}
+ registry-url: https://registry.npmjs.org/ # Needed for auth
+ - name: cache all node_modules
+ id: cache-modules
+ uses: actions/cache@v2
+ with:
+ path: '**/node_modules'
+ key: ${{ runner.os }}-node_modules-${{ hashFiles('yarn.lock', '**/package.json') }}
+ - name: find location of global yarn cache
+ id: yarn-cache
+ if: steps.cache-modules.outputs.cache-hit != 'true'
+ run: echo "::set-output name=dir::$(yarn cache dir)"
+ - name: cache global yarn cache
+ uses: actions/cache@v2
+ if: steps.cache-modules.outputs.cache-hit != 'true'
+ with:
+ path: ${{ steps.yarn-cache.outputs.dir }}
+ key: ${{ runner.os }}-yarn-${{ hashFiles('yarn.lock') }}
+ restore-keys: |
+ ${{ runner.os }}-yarn-
+ - name: yarn install
+ run: yarn install --frozen-lockfile
+ # End of yarn setup
+
+ - name: build microsite
+ run: yarn workspace backstage-microsite build
+
+ - name: build storybook
+ run: yarn workspace storybook build-storybook
+
+ - name: move storybook dist into microsite
+ run: mv packages/storybook/dist/ microsite/build/backstage/storybook
+
+ - name: Check the build output
+ run: ls microsite/build/backstage && ls microsite/build/backstage/storybook
+
+ - name: Deploy both microsite and storybook to gh-pages
+ uses: JamesIves/github-pages-deploy-action@3.4.2
+ with:
+ GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
+ BRANCH: gh-pages
+ FOLDER: microsite/build/backstage
diff --git a/.gitignore b/.gitignore
index 9884edf96e..aee80f4c10 100644
--- a/.gitignore
+++ b/.gitignore
@@ -90,6 +90,10 @@ typings/
.nuxt
dist
+# Microsite build output
+microsite/build
+microsite/i18n
+
# Gatsby files
.cache/
# Comment in the public line in if your project uses Gatsby and not Next.js
diff --git a/ADOPTERS.md b/ADOPTERS.md
index 7a96198529..0ba3e3196b 100644
--- a/ADOPTERS.md
+++ b/ADOPTERS.md
@@ -1,13 +1,15 @@
-| Organization | Contact | Description of Use |
-| --------------------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------------------------------------------ |
-| [Spotify](https://www.spotify.com) | [@stefanalund](https://github.com/stefanalund) | Main interface towards all of Spotify's infrastructure and technical documentation. |
-| [bol.com](https://www.bol.com) | [@RoyJacobs](https://github.com/RoyJacobs) | Initial work being done to unify platform tooling. |
-| [DFDS](https://www.dfds.com) | [@carlsendk](https://github.com/carlsendk) | V2 self-service platform. |
-| [Roadie](https://roadie.io) | [@dtuite](https://github.com/dtuite) | Hosted, managed Backstage with easy set-up |
-| [Roku](https://www.roku.com) | [@timurista](https://github.com/timurista) | Initial work on Cloud engineering service platform. |
-| [SDA SE](https://sda.se) | [@Fox32](https://github.com/Fox32) | Central place for developing and sharing services in our insurance ecosystem. |
-| [H-E-B](https://www.heb.com) | [@german-j-rodriguez](https://github.com/german-j-rodriguez) | Initial work on Engineering Portal service platform. |
-| [American Airlines](https://www.aa.com) | [@paulpach](https://github.com/paulpach) | Central place for developers to develop and maintain applications |
-| [Kiwi.com](https://kiwi.com) | [@aexvir](https://github.com/aexvir) | Replacing the frontend of [The Zoo](https://github.com/kiwicom/the-zoo), their service registry. |
-| [Voi](https://www.voiscooters.com/) | [@K-Phoen](https://github.com/K-Phoen) | Developer portal, main gateway to our infrastructure, documentation and internal tooling. |
-| [Talkdesk](https://www.talkdesk.com) | [@jaime-talkdesk](https://github.com/jaime-talkdesk) | Initial work for Engineering Portal and Self Provisioning to R&D |
+| Organization | Contact | Description of Use |
+| -------------------------------------------- | ------------------------------------------------------------ | ------------------------------------------------------------------------------------------------ |
+| [Spotify](https://www.spotify.com) | [@stefanalund](https://github.com/stefanalund) | Main interface towards all of Spotify's infrastructure and technical documentation. |
+| [bol.com](https://www.bol.com) | [@RoyJacobs](https://github.com/RoyJacobs) | Initial work being done to unify platform tooling. |
+| [DFDS](https://www.dfds.com) | [@carlsendk](https://github.com/carlsendk) | V2 self-service platform. |
+| [Roadie](https://roadie.io) | [@dtuite](https://github.com/dtuite) | Hosted, managed Backstage with easy set-up |
+| [Roku](https://www.roku.com) | [@timurista](https://github.com/timurista) | Initial work on Cloud engineering service platform. |
+| [SDA SE](https://sda.se) | [@Fox32](https://github.com/Fox32) | Central place for developing and sharing services in our insurance ecosystem. |
+| [H-E-B](https://www.heb.com) | [@german-j-rodriguez](https://github.com/german-j-rodriguez) | Initial work on Engineering Portal service platform. |
+| [American Airlines](https://www.aa.com) | [@paulpach](https://github.com/paulpach) | Central place for developers to develop and maintain applications |
+| [Kiwi.com](https://kiwi.com) | [@aexvir](https://github.com/aexvir) | Replacing the frontend of [The Zoo](https://github.com/kiwicom/the-zoo), their service registry. |
+| [Voi](https://www.voiscooters.com/) | [@K-Phoen](https://github.com/K-Phoen) | Developer portal, main gateway to our infrastructure, documentation and internal tooling. |
+| [Talkdesk](https://www.talkdesk.com) | [@jaime-talkdesk](https://github.com/jaime-talkdesk) | Initial work for Engineering Portal and Self Provisioning to R&D |
+| [Wealthsimple](https://www.wealthsimple.com) | [@andrewthauer](https://github.com/andrewthauer) | Developer portal, service catalog, documentation and tooling |
+| [Grab](https://www.grab.com) | [@althafh](https://github.com/althafh) | Initial work as a unified interface for all of Grab's internal tooling |
diff --git a/CHANGELOG.md b/CHANGELOG.md
index 8c67eae825..20ae9a414d 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -8,6 +8,33 @@ If you encounter issues while upgrading to a newer version, don't hesitate to re
> Collect changes for the next release below
+- The backend plugin
+ [service builder](https://github.com/spotify/backstage/blob/master/packages/backend-common/src/service/lib/ServiceBuilderImpl.ts)
+ no longer adds `express.json()` automatically to all routes. While convenient
+ in a lot of cases, it also led to problems where for example the proxy
+ middleware could hang because the body had already been altered and could not
+ be streamed. Also, plugins that rather wanted to handle e.g. form encoded data
+ still had to cater to that manually. We therefore decided to let plugins add
+ `express.json()` themselves if they happen to deal with JSON data.
+
+## v0.1.1-alpha.20
+
+- Includes https://github.com/spotify/backstage/pull/2097 to resolve issues with create-plugin command.
+
+## v0.1.1-alpha.19
+
+### @backstage/create-app
+
+- Many plugins have been added to the catalog and will for now be required to be added to separate apps as well. This will be solved as [#1536](https://github.com/spotify/backstage/issues/1536) gets sorted out, but for now you may need to install some plugins just to get pages to work.
+
+### @backstage/catalog-backend
+
+- Added the possibility to add static locations via `app-config.yaml`. This changed the signature of `new LocationReaders(logger)` inside `packages/backend/src/plugins/catalog.ts` to `new LocationReaders({config, logger})`. [#1890](https://github.com/spotify/backstage/pull/1890)
+
+### @backstage/theme
+
+- Changed the type signature of the palette, removing `sidebar: string` and adding `navigation: { background: string; indicator: string}`. [#1880](https://github.com/spotify/backstage/pull/1880)
+
## v0.1.1-alpha.18
### @backstage/catalog-backend
diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md
index cf7622d692..853332f74d 100644
--- a/CONTRIBUTING.md
+++ b/CONTRIBUTING.md
@@ -1,4 +1,4 @@
-# Contributing
+# Contributing to Backstage
Our vision for Backstage is for it to become the trusted standard toolbox (read: UX 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.
@@ -28,7 +28,7 @@ What kind of plugins should/could be created? Some inspiration from the 120+ plu
## Suggesting a plugin
-If you start developing a plugin that you aim to release as open source, we suggest that you create a new [new Issue](https://github.com/spotify/backstage/issues/new?template=plugin_template.md). This helps the community know what plugins are in development.
+If you start developing a plugin that you aim to release as open source, we suggest that you create a new [new Issue](https://github.com/spotify/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.
You can also use this process if you have an idea for a good plugin but you hope that someone else will pick up the work.
@@ -38,7 +38,7 @@ The current documentation is very limited. Help us make the `/docs` folder come
## Contribute to Storybook
-We think the best way to ensure different plugins provide a consistent experience is through a solid set of reusable UI/UX components. Backstage uses [Storybook](http://storybook.backstage.io).
+We think the best way to ensure different plugins provide a consistent experience is through a solid set of reusable UI/UX components. Backstage uses [Storybook](http://backstage.io/storybook).
Either help us [create new components](https://github.com/spotify/backstage/labels/help%20wanted) or improve stories for the existing ones (look for files with `*.stories.tsx`).
@@ -60,7 +60,35 @@ Have you started using Backstage? Adding your company to [ADOPTERS](ADOPTERS.md)
# Get Started!
-So...feel ready to jump in? Let's do this. Head over to the [Getting Started guide](https://github.com/spotify/backstage#getting-started) 👏🏻💯
+So...feel ready to jump in? Let's do this. 👏🏻💯
+
+To run a Backstage app, you will need to have the following installed:
+
+- [git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)
+- [NodeJS](https://nodejs.org/en/download/) - Active LTS Release, currently v12
+- [yarn](https://classic.yarnpkg.com/en/docs/install)
+
+After cloning this repo, open a terminal window and start the example app using the following commands from the project root:
+
+```bash
+yarn install # Install dependencies
+
+yarn start # Start dev server, use --check to enable linting and type-checks
+```
+
+The final `yarn start` command should open a local instance of Backstage in your browser, otherwise open one of the URLs printed in the terminal.
+
+Depending on the work you're doing, you often also want to run the example backend. Start the backend in a separate terminal session using the following:
+
+```bash
+cd packages/backend
+
+yarn start
+
+yarn lerna run mock-data # Populate the backend with mock data
+```
+
+And that's it! You are good to go 👍
If you need help, just jump into our [Discord chatroom](https://discord.gg/MUpMjP2).
diff --git a/README.md b/README.md
index d401650a66..4009864edc 100644
--- a/README.md
+++ b/README.md
@@ -1,4 +1,4 @@
-
+
# [Backstage](https://backstage.io)
@@ -10,101 +10,69 @@
## What is Backstage?
-[Backstage](https://backstage.io/) is an open platform for building developer portals. It’s based on the developer portal we’ve been using internally at Spotify for over four years. Backstage can be as simple as a services catalog or as powerful as the UX layer for your entire tech infrastructure.
+[Backstage](https://backstage.io/) is an open platform for building developer portals. Powered by a centralized service catalog, Backstage restores order to your microservices and infrastructure. So your product teams can ship high-quality code quickly — without compromising autonomy.
-For more information go to [backstage.io](https://backstage.io) or join our [Discord chatroom](https://discord.gg/EBHEGzX).
-
-### Features
-
-- Create and manage all of your organization’s software and microservices in one place.
-- Services catalog keeps track of all software and its ownership.
-- Visualizations provide information about your backend services and tooling, and help you monitor them.
-- A unified method for managing microservices offers both visibility and control.
-- Preset templates allow engineers to quickly create microservices in a standardized way ([coming soon](https://github.com/spotify/backstage/milestone/11)).
-- Centralized, full-featured technical documentation with integrated tooling that makes it easy for developers to set up, publish, and maintain alongside their code ([coming soon](https://github.com/spotify/backstage/milestone/15)).
-
-### Benefits
-
-- For _engineering managers_, it allows you to maintain standards and best practices across the organization, and can help you manage your whole tech ecosystem, from migrations to test certification.
-- For _end users_ (developers), it makes it fast and simple to build software components in a standardized way, and it provides a central place to manage all projects and documentation.
-- For _platform engineers_, it enables extensibility and scalability by letting you easily integrate new tools and services (via plugins), as well as extending the functionality of existing ones.
-- For _everyone_, it’s a single, consistent experience that ties all your infrastructure tooling, resources, standards, owners, contributors, and administrators together in one place.
-
-## Backstage Service Catalog (alpha)
-
-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](https://github.com/spotify/backstage/blob/master/docs/architecture-decisions/adr002-default-catalog-file-format.md#format) stored together with the code, which are then harvested and visualized in Backstage.
+Backstage unifies all your infrastructure tooling, services, and documentation to create a streamlined development environment from end to end.

-We have also 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.
+Out of the box, Backstage includes:
+
+- [Backstage Service Catalog](https://backstage.io/docs/features/software-catalog/software-catalog-overview) for managing all your software (microservices, libraries, data pipelines, websites, ML models, etc.)
+- [Backstage Software Templates](https://backstage.io/docs/features/software-templates/software-templates-index) for quickly spinning up new projects and standardizing your tooling with your organization’s best practices
+- [Backstage TechDocs](https://backstage.io/docs/features/techdocs/techdocs-overview) for making it easy to create, maintain, find, and use technical documentation, using a "docs like code" approach
+- Plus, a growing ecosystem of [open source plugins](https://github.com/spotify/backstage/tree/master/plugins) that further expand Backstage’s customizability and functionality
+
+For more information go to [backstage.io](https://backstage.io) or join our [Discord chatroom](https://discord.gg/EBHEGzX).
## Project roadmap
-We created Backstage about 4 years ago. While our internal version of Backstage has had the benefit of time to mature and evolve, the first iteration of our open source version is still nascent. We are envisioning three phases of the project and we have already begun work on various aspects of these phases:
+A detailed project roadmap, including already delivered milestones, is available [here](https://backstage.io/docs/overview/roadmap).
-- 🐣 **Phase 1:** Extensible frontend platform (Done ✅) - 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](http://storybook.backstage.io) help ensure a consistent experience between tools.
+## Getting Started
-- 🐢 **Phase 2:** Service Catalog ([alpha released](https://backstage.io/blog/2020/06/22/backstage-service-catalog-alpha)) - 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. Developers can get a uniform overview of all their software and related resources, regardless of how and where they are running, as well as an easy way to onboard and manage those resources.
+There are two different ways to get started with Backstage, either by creating a standalone app, or by cloning this repo. Which method you use depends on what you're planning to do.
-- 🐇 **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.
+Creating a standalone instance makes it simpler to customize the application for your needs whilst staying up to date with the project. You will also depend on `@backstage` packages from NPM, making the project much smaller. This is the recommended approach if you want to kick the tyres of Backstage or setup your own instance.
-Check out our [Milestones](https://github.com/spotify/backstage/milestones) and open [RFCs](https://github.com/spotify/backstage/labels/rfc) how they relate to the three Phases outlined above.
+On the other hand, if you want to contribute plugins or to the project in general, it's easier to fork and clone this project. That will let you stay up to date with the latest changes, and gives you an easier path to make Pull Requests towards this repo.
-Our vision for Backstage is for it to become the trusted standard toolbox (read: UX 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 me directly: [alund@spotify.com](mailto:alund@spotify.com).
+### Creating a Standalone App
-## Overview
+Backstage provides the `@backstage/create-app` package to scaffold standalone instances of Backstage. You will need to have
+[NodeJS](https://nodejs.org/en/download/) Active LTS Release installed
+(currently v12), and [yarn](https://classic.yarnpkg.com/en/docs/install). You will also need to have [Docker](https://docs.docker.com/engine/install/) installed to use some features like Software Templates and TechDocs.
-The Backstage platform consists of a number of different components:
-
-- **app** - Main web application that users interact with. It's built up by a number of different _Plugins_. This repo contains an example implementation of an app (located in `packages/app`) and you can easily get started with your own app by [creating one](docs/getting-started/create-an-app.md).
-- [**plugins**](https://github.com/spotify/backstage/tree/master/plugins) - Each plugin is treated as a self-contained web app and can include almost any type of content. Plugins all use a common set of platform API's and reusable UI components. Plugins can fetch data either from the _backend_ or through any RESTful API exposed through the _proxy_.
-- [**service catalog**](https://github.com/spotify/backstage/tree/master/packages/backend) - Service that holds the model of your software ecosystem, including organisational information and what team owns what software. The backend also has a Plugin model for extending its graph.
-- [**proxy**](https://github.com/spotify/backstage/tree/master/plugins/proxy-backend) - Terminates HTTPS and exposes any RESTful API to Plugins.
-- **identity** - A backend service that holds your organisation's metadata.
-
-## Getting started
-
-To run a Backstage app, you will need to have the following installed:
-
-- [git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)
-- [NodeJS](https://nodejs.org/en/download/) - Active LTS Release, currently v12
-- [yarn](https://classic.yarnpkg.com/en/docs/install)
-
-After cloning this repo, open a terminal window and start the example app using the following commands from the project root:
+Using `npx` you can then run the following to create an app in a chosen subdirectory of your current working directory:
```bash
-yarn install # Install dependencies
-
-yarn start # Start dev server, use --check to enable linting and type-checks
+npx @backstage/create-app
```
-The final `yarn start` command should open a local instance of Backstage in your browser, otherwise open one of the URLs printed in the terminal.
+You will be taken through a wizard to create your app, and the output should look something like this. You can read more about this process [here](https://backstage.io/docs/getting-started/create-an-app)
-And that's it! You are good to go 👍
+### Contributing to Backstage
-### Next step
+You can read more in our [CONTRIBUTING.md](./CONTRIBUTING.md#get-started) guide, which can help you get setup with a Backstage development environment.
-Take a look at the [Getting Started](docs/getting-started/index.md) guide to learn how to set up Backstage, and how to develop on the platform.
+### Next steps
+
+Take a look at the [Getting Started](https://backstage.io/docs/getting-started/index) guide to learn how to set up Backstage, and how to develop on the platform.
## Documentation
-- [Main documentation](docs/README.md)
-- [Service Catalog](docs/features/software-catalog/index.md)
-- [Create a Backstage App](docs/getting-started/create-an-app.md)
-- [Architecture](docs/overview/architecture-terminology.md) ([Decisions](docs/architecture-decisions/index.md))
-- [Designing for Backstage](docs/dls/design.md)
-- [Storybook - UI components](http://storybook.backstage.io)
-
-## Contributing
-
-We would love your help in building Backstage! See [CONTRIBUTING](CONTRIBUTING.md) for more information.
+- [Main documentation](https://backstage.io/docs)
+- [Service Catalog](https://backstage.io/docs/features/software-catalog/software-catalog-overview)
+- [Architecture](https://backstage.io/docs/overview/architecture-terminology) ([Decisions](https://backstage.io/docs/architecture-decisions/adrs-overview))
+- [Designing for Backstage](https://backstage.io/docs/dls/design)
+- [Storybook - UI components](https://backstage.io/storybook)
## Community
- [Discord chatroom](https://discord.gg/MUpMjP2) - Get support or discuss the project
- [Good First Issues](https://github.com/spotify/backstage/contribute) - Start here if you want to contribute
- [RFCs](https://github.com/spotify/backstage/labels/rfc) - Help shape the technical direction
-- [FAQ](docs/FAQ.md) - Frequently Asked Questions
+- [FAQ](https://backstage.io/docs/FAQ) - Frequently Asked Questions
- [Code of Conduct](CODE_OF_CONDUCT.md) - This is how we roll
- [Adopters](ADOPTERS.md) - Companies already using Backstage
- [Blog](https://backstage.io/blog/) - Announcements and updates
diff --git a/app-config.yaml b/app-config.yaml
index d6c745a6c2..7eb6023f61 100644
--- a/app-config.yaml
+++ b/app-config.yaml
@@ -4,18 +4,25 @@ app:
backend:
baseUrl: http://localhost:7000
- listen: 0.0.0.0:7000
+ listen:
+ port: 7000
cors:
origin: http://localhost:3000
methods: [GET, POST, PUT, DELETE]
credentials: true
+ database:
+ client: sqlite3
+ connection: ':memory:'
+# See README.md in the proxy-backend plugin for information on the configuration format
proxy:
- '/circleci/api':
- target: 'https://circleci.com/api/v1.1'
- changeOrigin: true
- pathRewrite:
- '^/proxy/circleci/api/': '/'
+ '/circleci/api': https://circleci.com/api/v1.1
+ '/jenkins/api':
+ target: http://localhost:8080
+ headers:
+ Authorization:
+ $secret:
+ env: JENKINS_BASIC_AUTH_HEADER
organization:
name: Spotify
@@ -26,12 +33,70 @@ techdocs:
sentry:
organization: spotify
+rollbar:
+ organization: spotify
+ accountToken:
+ $secret:
+ env: ROLLBAR_ACCOUNT_TOKEN
+
+newrelic:
+ api:
+ baseUrl: 'https://api.newrelic.com/v2'
+ key: NEW_RELIC_REST_API_KEY
+
+lighthouse:
+ baseUrl: http://localhost:3003
+
+catalog:
+ rules:
+ - allow: [Component, API, Group, Template, Location]
+ processors:
+ githubApi:
+ privateToken:
+ $secret:
+ env: GITHUB_PRIVATE_TOKEN
+ bitbucketApi:
+ username:
+ $secret:
+ env: BITBUCKET_USERNAME
+ appPassword:
+ $secret:
+ env: BITBUCKET_APP_PASSWORD
+ gitlabApi:
+ privateToken:
+ $secret:
+ env: GITLAB_PRIVATE_TOKEN
+ azureApi:
+ privateToken:
+ $secret:
+ env: AZURE_PRIVATE_TOKEN
+ exampleEntityLocations:
+ github:
+ - https://github.com/spotify/backstage/blob/master/packages/catalog-model/examples/artist-lookup-component.yaml
+ - https://github.com/spotify/backstage/blob/master/packages/catalog-model/examples/playback-order-component.yaml
+ - https://github.com/spotify/backstage/blob/master/packages/catalog-model/examples/podcast-api-component.yaml
+ - https://github.com/spotify/backstage/blob/master/packages/catalog-model/examples/queue-proxy-component.yaml
+ - https://github.com/spotify/backstage/blob/master/packages/catalog-model/examples/searcher-component.yaml
+ - https://github.com/spotify/backstage/blob/master/packages/catalog-model/examples/playback-lib-component.yaml
+ - https://github.com/spotify/backstage/blob/master/packages/catalog-model/examples/www-artist-component.yaml
+ - https://github.com/spotify/backstage/blob/master/packages/catalog-model/examples/shuffle-api-component.yaml
+ - https://github.com/spotify/backstage/blob/master/plugins/scaffolder-backend/sample-templates/react-ssr-template/template.yaml
+ - https://github.com/spotify/backstage/blob/master/plugins/scaffolder-backend/sample-templates/springboot-grpc-template/template.yaml
+ - https://github.com/spotify/backstage/blob/master/plugins/scaffolder-backend/sample-templates/create-react-app/template.yaml
+ - https://github.com/spotify/cookiecutter-golang/blob/master/template.yaml
+ - https://github.com/spotify/backstage/blob/master/plugins/scaffolder-backend/sample-templates/docs-template/template.yaml
+ - https://github.com/spotify/backstage/blob/master/packages/catalog-model/examples/hello-world-api.yaml
+ - https://github.com/spotify/backstage/blob/master/packages/catalog-model/examples/streetlights-api.yaml
+
auth:
providers:
google:
development:
+<<<<<<< HEAD
appOrigin: 'http://localhost:3000/'
secure: false
+=======
+>>>>>>> master
clientId:
$secret:
env: AUTH_GOOGLE_CLIENT_ID
@@ -40,8 +105,11 @@ auth:
env: AUTH_GOOGLE_CLIENT_SECRET
github:
development:
+<<<<<<< HEAD
appOrigin: 'http://localhost:3000/'
secure: false
+=======
+>>>>>>> master
clientId:
$secret:
env: AUTH_GITHUB_CLIENT_ID
@@ -53,8 +121,11 @@ auth:
env: AUTH_GITHUB_ENTERPRISE_INSTANCE_URL
gitlab:
development:
+<<<<<<< HEAD
appOrigin: 'http://localhost:3000/'
secure: false
+=======
+>>>>>>> master
clientId:
$secret:
env: AUTH_GITLAB_CLIENT_ID
@@ -65,6 +136,7 @@ auth:
$secret:
env: GITLAB_BASE_URL
saml:
+<<<<<<< HEAD
development:
entryPoint: 'http://localhost:7001/'
issuer: 'passport-saml'
@@ -72,6 +144,12 @@ auth:
development:
appOrigin: 'http://localhost:3000/'
secure: false
+=======
+ entryPoint: "http://localhost:7001/"
+ issuer: "passport-saml"
+ okta:
+ development:
+>>>>>>> master
clientId:
$secret:
env: AUTH_OKTA_CLIENT_ID
@@ -83,17 +161,42 @@ auth:
env: AUTH_OKTA_AUDIENCE
oauth2:
development:
+<<<<<<< HEAD
appOrigin: 'http://localhost:3000/'
secure: false
+=======
+>>>>>>> master
clientId:
$secret:
env: AUTH_OAUTH2_CLIENT_ID
clientSecret:
$secret:
env: AUTH_OAUTH2_CLIENT_SECRET
- authorizationURL:
+ authorizationUrl:
$secret:
env: AUTH_OAUTH2_AUTH_URL
- tokenURL:
+ tokenUrl:
$secret:
env: AUTH_OAUTH2_TOKEN_URL
+ auth0:
+ development:
+ clientId:
+ $secret:
+ env: AUTH_AUTH0_CLIENT_ID
+ clientSecret:
+ $secret:
+ env: AUTH_AUTH0_CLIENT_SECRET
+ domain:
+ $secret:
+ env: AUTH_AUTH0_DOMAIN
+ microsoft:
+ development:
+ clientId:
+ $secret:
+ env: AUTH_MICROSOFT_CLIENT_ID
+ clientSecret:
+ $secret:
+ env: AUTH_MICROSOFT_CLIENT_SECRET
+ tenantId:
+ $secret:
+ env: AUTH_MICROSOFT_TENANT_ID
diff --git a/catalog-info.yaml b/catalog-info.yaml
index 86b67f95cd..4221ee6dc6 100644
--- a/catalog-info.yaml
+++ b/catalog-info.yaml
@@ -7,6 +7,7 @@ metadata:
annotations:
github.com/project-slug: spotify/backstage
backstage.io/github-actions-id: spotify/backstage
+ backstage.io/techdocs-ref: github:https://github.com/spotify/backstage.git
spec:
type: library
owner: Spotify
diff --git a/docs/FAQ.md b/docs/FAQ.md
index 7d568a840e..4b5df3ace0 100644
--- a/docs/FAQ.md
+++ b/docs/FAQ.md
@@ -1,6 +1,9 @@
-# FAQ
+---
+id: FAQ
+title: FAQ
+---
-## Product FAQ:
+## Product FAQ
### Can we call Backstage something different? So that it fits our company better?
@@ -14,8 +17,7 @@ brand.
No, but it can be! Backstage is designed to be a developer portal for all your
infrastructure tooling, services, and documentation. So, it's not a monitoring
platform — but that doesn't mean you can't integrate a monitoring tool into
-Backstage by writing
-[a plugin](/docs/FAQ.md#what-is-a-plugin-in-backstage).
+Backstage by writing [a plugin](#what-is-a-plugin-in-backstage).
### How is Backstage licensed?
@@ -36,12 +38,11 @@ more, read our blog post,
Yes, we've already started releasing open source versions of some of the plugins
we use here, and we'll continue to do so.
-[Plugins](/docs/FAQ.md#what-is-a-plugin-in-backstage) are the
-building blocks of functionality in Backstage. We have over 120 plugins inside
-Spotify — many of those are specialized for our use, so will remain internal and
-proprietary to us. But we estimate that about a third of our existing plugins
-make good open source candidates. (And we'll probably end up writing some brand
-new ones, too.)
+[Plugins](#what-is-a-plugin-in-backstage) are the building blocks of
+functionality in Backstage. We have over 120 plugins inside Spotify — many of
+those are specialized for our use, so will remain internal and proprietary to
+us. But we estimate that about a third of our existing plugins make good open
+source candidates. (And we'll probably end up writing some brand new ones, too.)
### What's the roadmap for Backstage?
@@ -66,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?
@@ -91,21 +92,31 @@ Node.js and GraphQL.
### What is the end-to-end user flow? The happy path story.
There are three main user profiles for Backstage: the integrator, the
-contributor, and the software engineer.
+contributor, and the software engineer.
-The **integrator** hosts the Backstage app and configures which plugins are available to use in the app.
+The **integrator** hosts the Backstage app and configures which plugins are
+available to use in the app.
The **contributor** adds functionality to the app by writing plugins.
-The **software engineer** uses the app's functionality and interacts with its plugins.
+The **software engineer** uses the app's functionality and interacts with its
+plugins.
### What is a "plugin" in Backstage?
-Plugins are what provide the feature functionality in Backstage. They are used to integrate different systems into Backstage's frontend, so that the developer gets a consistent UX, no matter what tool or service is being accessed on the other side.
+Plugins are what provide the feature functionality in Backstage. They are used
+to integrate different systems into Backstage's frontend, so that the developer
+gets a consistent UX, no matter what tool or service is being accessed on the
+other side.
-Each plugin is treated as a self-contained web app and can include almost any type of content. Plugins all use a common set of platform APIs and reusable UI components. Plugins can fetch data either from the backend or an API exposed through the proxy.
+Each plugin is treated as a self-contained web app and can include almost any
+type of content. Plugins all use a common set of platform APIs and reusable UI
+components. Plugins can fetch data either from the backend or an API exposed
+through the proxy.
-Learn more about [the different components](https://github.com/spotify/backstage#overview) that make up Backstage.
+Learn more about
+[the different components](https://github.com/spotify/backstage#overview) that
+make up Backstage.
### Do I have to write plugins in TypeScript?
@@ -127,7 +138,15 @@ can browse and search for all available plugins.
### Which plugin is used the most at Spotify?
-By far, our most-used plugin is our TechDocs plugin, which we use for creating technical documentation. Our philosophy at Spotify is to treat "docs like code", where you write documentation using the same workflow as you write your code. This makes it easier to create, find, and update documentation. We hope to release [the open source version](https://github.com/spotify/backstage/issues/687) in the future. (See also: "[Will Spotify's internal plugins be open sourced, too?](/docs/FAQ.md#will-spotifys-internal-plugins-be-open-sourced-too)" above)
+By far, our most-used plugin is our TechDocs plugin, which we use for creating
+technical documentation. Our philosophy at Spotify is to treat "docs like code",
+where you write documentation using the same workflow as you write your code.
+This makes it easier to create, find, and update documentation. We hope to
+release
+[the open source version](https://github.com/spotify/backstage/issues/687) in
+the future. (See also:
+"[Will Spotify's internal plugins be open sourced, too?](#will-spotifys-internal-plugins-be-open-sourced-too)"
+above)
### Are you planning to have plugins baked into the repo? Or should they be developed in separate repos?
@@ -135,10 +154,10 @@ Contributors can add open source plugins to the plugins directory in
[this monorepo](https://github.com/spotify/backstage). Integrators can then
configure which open source plugins are available to use in their instance of
the app. Open source plugins are downloaded as npm packages published in the
-open source repository. While we encourage using the open source model, we
-know there are cases where contributors might want to experiment internally or
-keep their plugins closed source. Contributors writing closed source plugins
-should develop them in the plugins directory in their own Backstage repository.
+open source repository. While we encourage using the open source model, we know
+there are cases where contributors might want to experiment internally or keep
+their plugins closed source. Contributors writing closed source plugins should
+develop them in the plugins directory in their own Backstage repository.
Integrators also configure closed source plugins locally from the monorepo.
### Any plans for integrating with other repository managers, such as GitLab or Bitbucket?
@@ -149,7 +168,8 @@ stage. Hosting this project on GitHub does not exclude integrations with
alternatives, such as
[GitLab](https://github.com/spotify/backstage/issues?q=is%3Aissue+is%3Aopen+GitLab)
or Bitbucket. We believe that in time there will be plugins that will provide
-functionality for these tools as well. Hopefully, contributed by the community! Also note, implementations of Backstage can be hosted wherever you feel suits
+functionality for these tools as well. Hopefully, contributed by the community!
+Also note, implementations of Backstage can be hosted wherever you feel suits
your needs best.
### Who maintains Backstage?
@@ -165,8 +185,8 @@ maintains Backstage in your own environment.
### Does Spotify provide a managed version of Backstage?
-No, this is not a service offering. We build the piece of software, and
-someone in your infrastructure team is responsible for
+No, this is not a service offering. We build the piece of software, and someone
+in your infrastructure team is responsible for
[deploying](https://github.com/spotify/backstage/blob/master/DEPLOYMENT.md) and
maintaining it.
@@ -186,16 +206,16 @@ Please report sensitive security issues via Spotify's
No. Backstage does not collect any telemetry from any third party using the
platform. Spotify, and the open source community, does have access to
[GitHub Insights](https://github.com/features/insights), which contains
-information such as contributors, commits, traffic, and dependencies.
-Backstage is an open platform, but you are in control of your own data. You
-control who has access to any data you provide to your version of Backstage and
-who that data is shared with.
+information such as contributors, commits, traffic, and dependencies. Backstage
+is an open platform, but you are in control of your own data. You control who
+has access to any data you provide to your version of Backstage and who that
+data is shared with.
### Can Backstage be used to build something other than a developer portal?
-Yes. The core frontend framework could be used for building any large-scale
-web application where (1) multiple teams are building separate parts of the app,
-and (2) you want the overall experience to be consistent. That being said, in
+Yes. The core frontend framework could be used for building any large-scale web
+application where (1) multiple teams are building separate parts of the app, and
+(2) you want the overall experience to be consistent. That being said, in
[Phase 2](https://github.com/spotify/backstage#project-roadmap) of the project
we will add features that are needed for developer portals and systems for
managing software ecosystems. Our ambition will be to keep Backstage modular.
diff --git a/docs/README.md b/docs/README.md
index 2bda6a5aaa..c63a12b589 100644
--- a/docs/README.md
+++ b/docs/README.md
@@ -1,106 +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.
-
-- 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)
- - 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)
- - [Populating the catalog](features/software-catalog/populating.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)
- - [Reading Documentation](features/techdocs/reading-documentation.md)
- - [Writing Documentation](features/techdocs/writing-documentation.md)
- - [Publishing Documentation](features/techdocs/publishing-documentation.md)
- - [Contributing](features/techdocs/contributing.md)
- - [Debugging](features/techdocs/debugging.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://storybook.backstage.io)
- - [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/api/backend.md b/docs/api/backend.md
index e69de29bb2..bc44b8350c 100644
--- a/docs/api/backend.md
+++ b/docs/api/backend.md
@@ -0,0 +1,6 @@
+---
+id: backend
+title: Backend
+---
+
+## TODO
diff --git a/docs/api/utility-apis.md b/docs/api/utility-apis.md
index f87db15e7e..b4c2fd161e 100644
--- a/docs/api/utility-apis.md
+++ b/docs/api/utility-apis.md
@@ -1,4 +1,7 @@
-# Utility APIs
+---
+id: utility-apis
+title: Utility APIs
+---
## Introduction
@@ -68,18 +71,23 @@ import {
AlertApiForwarder,
ErrorApiForwarder,
ErrorAlerter,
+ ConfigApi
} from '@backstage/core';
-const builder = ApiRegistry.builder();
-// The alert API is a self-contained implementation that shows alerts to the user.
-const alertApi = builder.add(alertApiRef, new AlertApiForwarder());
+const apis = (config: ConfigApi) => {
+ const builder = ApiRegistry.builder();
-// The error API uses the alert API to send error notifications to the user.
-builder.add(errorApiRef, new ErrorAlerter(alertApi, new ErrorApiForwarder()));
+ // The alert API is a self-contained implementation that shows alerts to the user.
+ const alertApi = builder.add(alertApiRef, new AlertApiForwarder());
+
+ // The error API uses the alert API to send error notifications to the user.
+ builder.add(errorApiRef, new ErrorAlerter(alertApi, new ErrorApiForwarder()));
+ return builder.build();
+}
const app = createApp({
- apis: apiBuilder.build(),
+ apis,
// ... other config
});
```
@@ -153,7 +161,7 @@ The figure below shows the relationship between
fooApiRef.
-
+
The current method for connecting Utility API providers and consumers is via the
diff --git a/docs/architecture-decisions/adr001-add-adr-log.md b/docs/architecture-decisions/adr001-add-adr-log.md
index e6ab39aea4..8a484fa264 100644
--- a/docs/architecture-decisions/adr001-add-adr-log.md
+++ b/docs/architecture-decisions/adr001-add-adr-log.md
@@ -1,4 +1,8 @@
-# ADR001: Architecture Decision Record (ADR) log
+---
+id: adrs-adr001
+title: ADR001: Architecture Decision Record (ADR) log
+sidebar_label: ADR001
+---
| Created | Status |
| ---------- | ------ |
diff --git a/docs/architecture-decisions/adr002-default-catalog-file-format.md b/docs/architecture-decisions/adr002-default-catalog-file-format.md
index 00c8b0947d..c1cb719bf5 100644
--- a/docs/architecture-decisions/adr002-default-catalog-file-format.md
+++ b/docs/architecture-decisions/adr002-default-catalog-file-format.md
@@ -1,4 +1,8 @@
-# ADR002: Default Software Catalog File Format
+---
+id: adrs-adr002
+title: ADR002: Default Software Catalog File Format
+sidebar_label: ADR002
+---
| Created | Status |
| ---------- | ------ |
diff --git a/docs/architecture-decisions/adr003-avoid-default-exports.md b/docs/architecture-decisions/adr003-avoid-default-exports.md
index 7becebaa4b..7a8df28f49 100644
--- a/docs/architecture-decisions/adr003-avoid-default-exports.md
+++ b/docs/architecture-decisions/adr003-avoid-default-exports.md
@@ -1,4 +1,8 @@
-# ADR003: Avoid Default Exports and Prefer Named Exports
+---
+id: adrs-adr003
+title: ADR003: Avoid Default Exports and Prefer Named Exports
+sidebar_label: ADR003
+---
| Created | Status |
| ---------- | ------ |
diff --git a/docs/architecture-decisions/adr004-module-export-structure.md b/docs/architecture-decisions/adr004-module-export-structure.md
index 54132773c9..077f8c35d1 100644
--- a/docs/architecture-decisions/adr004-module-export-structure.md
+++ b/docs/architecture-decisions/adr004-module-export-structure.md
@@ -1,4 +1,8 @@
-# ADR004: Module Export Structure
+---
+id: adrs-adr004
+title: ADR004: Module Export Structure
+sidebar_label: ADR004
+---
| Created | Status |
| ---------- | ------ |
diff --git a/docs/architecture-decisions/adr005-catalog-core-entities.md b/docs/architecture-decisions/adr005-catalog-core-entities.md
index d607dc62fb..8f39acd1cf 100644
--- a/docs/architecture-decisions/adr005-catalog-core-entities.md
+++ b/docs/architecture-decisions/adr005-catalog-core-entities.md
@@ -1,4 +1,8 @@
-# ADR005: Catalog Core Entities
+---
+id: adrs-adr005
+title: ADR005: Catalog Core Entities
+sidebar_label: ADR005
+---
| Created | Status |
| ---------- | ------ |
@@ -18,7 +22,7 @@ Backstage should eventually support the following core entities:
- **Resources** are physical or virtual infrastructure needed to operate a
component
-
+
For now, we'll start by only implementing support for the Component entity in
the Backstage catalog. This can later be extended to APIs, Resources and other
diff --git a/docs/architecture-decisions/adr006-avoid-react-fc.md b/docs/architecture-decisions/adr006-avoid-react-fc.md
index 21e6d5b637..e48fceb562 100644
--- a/docs/architecture-decisions/adr006-avoid-react-fc.md
+++ b/docs/architecture-decisions/adr006-avoid-react-fc.md
@@ -1,4 +1,8 @@
-# ADR006: Avoid React.FC and React.SFC
+---
+id: adrs-adr006
+title: ADR006: Avoid React.FC and React.SFC
+sidebar_label: ADR006
+---
## Context
diff --git a/docs/architecture-decisions/adr007-use-msw-to-mock-service-requests.md b/docs/architecture-decisions/adr007-use-msw-to-mock-service-requests.md
index bdb221cea3..773f08be30 100644
--- a/docs/architecture-decisions/adr007-use-msw-to-mock-service-requests.md
+++ b/docs/architecture-decisions/adr007-use-msw-to-mock-service-requests.md
@@ -1,4 +1,8 @@
-# ADR007: Use MSW to mock http requests
+---
+id: adrs-adr007
+title: ADR007: Use MSW to mock http requests
+sidebar_label: ADR007
+---
## Context
diff --git a/docs/architecture-decisions/adr008-default-catalog-file-name.md b/docs/architecture-decisions/adr008-default-catalog-file-name.md
index 23910f634f..979ea4de33 100644
--- a/docs/architecture-decisions/adr008-default-catalog-file-name.md
+++ b/docs/architecture-decisions/adr008-default-catalog-file-name.md
@@ -1,4 +1,8 @@
-# ADR008: Default Catalog File Name
+---
+id: adrs-adr008
+title: ADR008: Default Catalog File Name
+sidebar_label: ADR008
+---
## Background
diff --git a/docs/architecture-decisions/index.md b/docs/architecture-decisions/index.md
index 7762a9c827..91d2c668d7 100644
--- a/docs/architecture-decisions/index.md
+++ b/docs/architecture-decisions/index.md
@@ -1,4 +1,8 @@
-# Architecture Decision Records (ADR)
+---
+id: adrs-overview
+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
@@ -19,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/architecture-decisions/catalog-core-entities.png b/docs/assets/architecture-decisions/catalog-core-entities.png
similarity index 100%
rename from docs/architecture-decisions/catalog-core-entities.png
rename to docs/assets/architecture-decisions/catalog-core-entities.png
diff --git a/docs/overview/architecture-overview/backstage-typical-architecture.png b/docs/assets/architecture-overview/backstage-typical-architecture.png
similarity index 100%
rename from docs/overview/architecture-overview/backstage-typical-architecture.png
rename to docs/assets/architecture-overview/backstage-typical-architecture.png
diff --git a/docs/overview/architecture-overview/circle-ci-plugin-architecture.png b/docs/assets/architecture-overview/circle-ci-plugin-architecture.png
similarity index 100%
rename from docs/overview/architecture-overview/circle-ci-plugin-architecture.png
rename to docs/assets/architecture-overview/circle-ci-plugin-architecture.png
diff --git a/docs/overview/architecture-overview/circle-ci.png b/docs/assets/architecture-overview/circle-ci.png
similarity index 100%
rename from docs/overview/architecture-overview/circle-ci.png
rename to docs/assets/architecture-overview/circle-ci.png
diff --git a/docs/overview/architecture-overview/containerised.png b/docs/assets/architecture-overview/containerised.png
similarity index 100%
rename from docs/overview/architecture-overview/containerised.png
rename to docs/assets/architecture-overview/containerised.png
diff --git a/docs/overview/architecture-overview/core-vs-plugin-components-highlighted.png b/docs/assets/architecture-overview/core-vs-plugin-components-highlighted.png
similarity index 100%
rename from docs/overview/architecture-overview/core-vs-plugin-components-highlighted.png
rename to docs/assets/architecture-overview/core-vs-plugin-components-highlighted.png
diff --git a/docs/overview/architecture-overview/lighthouse-plugin-architecture.png b/docs/assets/architecture-overview/lighthouse-plugin-architecture.png
similarity index 100%
rename from docs/overview/architecture-overview/lighthouse-plugin-architecture.png
rename to docs/assets/architecture-overview/lighthouse-plugin-architecture.png
diff --git a/docs/overview/architecture-overview/lighthouse-plugin.png b/docs/assets/architecture-overview/lighthouse-plugin.png
similarity index 100%
rename from docs/overview/architecture-overview/lighthouse-plugin.png
rename to docs/assets/architecture-overview/lighthouse-plugin.png
diff --git a/docs/overview/architecture-overview/tech-radar-plugin-architecture.png b/docs/assets/architecture-overview/tech-radar-plugin-architecture.png
similarity index 100%
rename from docs/overview/architecture-overview/tech-radar-plugin-architecture.png
rename to docs/assets/architecture-overview/tech-radar-plugin-architecture.png
diff --git a/docs/overview/architecture-overview/tech-radar-plugin.png b/docs/assets/architecture-overview/tech-radar-plugin.png
similarity index 100%
rename from docs/overview/architecture-overview/tech-radar-plugin.png
rename to docs/assets/architecture-overview/tech-radar-plugin.png
diff --git a/docs/contributorheader.png b/docs/assets/contributorheader.png
similarity index 100%
rename from docs/contributorheader.png
rename to docs/assets/contributorheader.png
diff --git a/docs/dls/DLS.png b/docs/assets/dls/DLS.png
similarity index 100%
rename from docs/dls/DLS.png
rename to docs/assets/dls/DLS.png
diff --git a/docs/assets/dls/designheader-updated.png b/docs/assets/dls/designheader-updated.png
new file mode 100644
index 0000000000..56c5a56abb
Binary files /dev/null and b/docs/assets/dls/designheader-updated.png differ
diff --git a/docs/dls/designheader.png b/docs/assets/dls/designheader.png
similarity index 100%
rename from docs/dls/designheader.png
rename to docs/assets/dls/designheader.png
diff --git a/docs/dls/running-storybook.png b/docs/assets/dls/running-storybook.png
similarity index 100%
rename from docs/dls/running-storybook.png
rename to docs/assets/dls/running-storybook.png
diff --git a/docs/dls/storybook-page.png b/docs/assets/dls/storybook-page.png
similarity index 100%
rename from docs/dls/storybook-page.png
rename to docs/assets/dls/storybook-page.png
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/headline.png b/docs/assets/headline.png
similarity index 100%
rename from docs/headline.png
rename to docs/assets/headline.png
diff --git a/docs/plugins/my-plugin_screenshot.png b/docs/assets/my-plugin_screenshot.png
similarity index 100%
rename from docs/plugins/my-plugin_screenshot.png
rename to docs/assets/my-plugin_screenshot.png
diff --git a/docs/assets/pop.png b/docs/assets/pop.png
new file mode 100644
index 0000000000..441126f33c
Binary files /dev/null and b/docs/assets/pop.png differ
diff --git a/docs/assets/software-catalog/bsc-edit.png b/docs/assets/software-catalog/bsc-edit.png
new file mode 100644
index 0000000000..d1ac1f52e5
Binary files /dev/null and b/docs/assets/software-catalog/bsc-edit.png differ
diff --git a/docs/assets/software-catalog/bsc-extend.png b/docs/assets/software-catalog/bsc-extend.png
new file mode 100644
index 0000000000..54d660ea70
Binary files /dev/null and b/docs/assets/software-catalog/bsc-extend.png differ
diff --git a/docs/assets/software-catalog/bsc-register-1.png b/docs/assets/software-catalog/bsc-register-1.png
new file mode 100644
index 0000000000..117b2ea8ea
Binary files /dev/null and b/docs/assets/software-catalog/bsc-register-1.png differ
diff --git a/docs/assets/software-catalog/bsc-register-2.png b/docs/assets/software-catalog/bsc-register-2.png
new file mode 100644
index 0000000000..fd1ea7b998
Binary files /dev/null and b/docs/assets/software-catalog/bsc-register-2.png differ
diff --git a/docs/assets/software-catalog/bsc-search.png b/docs/assets/software-catalog/bsc-search.png
new file mode 100644
index 0000000000..8e417cb076
Binary files /dev/null and b/docs/assets/software-catalog/bsc-search.png differ
diff --git a/docs/assets/software-catalog/bsc-starred.png b/docs/assets/software-catalog/bsc-starred.png
new file mode 100644
index 0000000000..27db19c842
Binary files /dev/null and b/docs/assets/software-catalog/bsc-starred.png differ
diff --git a/docs/features/software-catalog/service-catalog-home.png b/docs/assets/software-catalog/service-catalog-home.png
similarity index 100%
rename from docs/features/software-catalog/service-catalog-home.png
rename to docs/assets/software-catalog/service-catalog-home.png
diff --git a/docs/assets/software-catalog/software-model-core-entities.png b/docs/assets/software-catalog/software-model-core-entities.png
new file mode 100644
index 0000000000..b718b7527c
Binary files /dev/null and b/docs/assets/software-catalog/software-model-core-entities.png differ
diff --git a/docs/features/software-templates/assets/added-to-the-catalog-list.png b/docs/assets/software-templates/added-to-the-catalog-list.png
similarity index 100%
rename from docs/features/software-templates/assets/added-to-the-catalog-list.png
rename to docs/assets/software-templates/added-to-the-catalog-list.png
diff --git a/docs/features/software-templates/assets/complete.png b/docs/assets/software-templates/complete.png
similarity index 100%
rename from docs/features/software-templates/assets/complete.png
rename to docs/assets/software-templates/complete.png
diff --git a/docs/features/software-templates/assets/create.png b/docs/assets/software-templates/create.png
similarity index 100%
rename from docs/features/software-templates/assets/create.png
rename to docs/assets/software-templates/create.png
diff --git a/docs/features/software-templates/assets/failed.png b/docs/assets/software-templates/failed.png
similarity index 100%
rename from docs/features/software-templates/assets/failed.png
rename to docs/assets/software-templates/failed.png
diff --git a/docs/features/software-templates/assets/go-to-catalog.png b/docs/assets/software-templates/go-to-catalog.png
similarity index 100%
rename from docs/features/software-templates/assets/go-to-catalog.png
rename to docs/assets/software-templates/go-to-catalog.png
diff --git a/docs/features/software-templates/assets/running.png b/docs/assets/software-templates/running.png
similarity index 100%
rename from docs/features/software-templates/assets/running.png
rename to docs/assets/software-templates/running.png
diff --git a/docs/features/software-templates/assets/template-picked-2.png b/docs/assets/software-templates/template-picked-2.png
similarity index 100%
rename from docs/features/software-templates/assets/template-picked-2.png
rename to docs/assets/software-templates/template-picked-2.png
diff --git a/docs/features/software-templates/assets/template-picked.png b/docs/assets/software-templates/template-picked.png
similarity index 100%
rename from docs/features/software-templates/assets/template-picked.png
rename to docs/assets/software-templates/template-picked.png
diff --git a/docs/assets/techdocs/documentation-template.png b/docs/assets/techdocs/documentation-template.png
new file mode 100644
index 0000000000..1f44ad27c6
Binary files /dev/null and b/docs/assets/techdocs/documentation-template.png differ
diff --git a/docs/assets/techdocs/techdocs_big_picture.png b/docs/assets/techdocs/techdocs_big_picture.png
new file mode 100644
index 0000000000..ffe437180f
Binary files /dev/null and b/docs/assets/techdocs/techdocs_big_picture.png differ
diff --git a/docs/api/utility-apis-fig1.svg b/docs/assets/utility-apis-fig1.svg
similarity index 100%
rename from docs/api/utility-apis-fig1.svg
rename to docs/assets/utility-apis-fig1.svg
diff --git a/docs/auth/add-auth-provider.md b/docs/auth/add-auth-provider.md
index 33f1d335a0..7e4f5c8e2f 100644
--- a/docs/auth/add-auth-provider.md
+++ b/docs/auth/add-auth-provider.md
@@ -1,4 +1,7 @@
-# Adding authentication providers
+---
+id: add-auth-provider
+title: Adding authentication providers
+---
## Passport
@@ -45,22 +48,35 @@ provider class which implements a handler for the chosen framework.
#### Adding an OAuth based provider
If we're adding an `OAuth` based provider we would implement the
-[OAuthProviderHandlers](#OAuthProviderHandlers) interface.
+[OAuthProviderHandlers](#OAuthProviderHandlers) interface. By implementing this
+interface we can use the `OAuthProvider` class provided by `lib/oauth`, meaning
+we don't need to implement the full
+[AuthProviderRouteHandlers](#AuthProviderRouteHandlers) interface that providers
+otherwise need to implement.
-The provider class takes the provider's configuration as a class parameter. It
-also imports the `Strategy` from the passport package.
+The provider class takes the provider's options as a class parameter. It also
+imports the `Strategy` from the passport package.
```ts
import { Strategy as ProviderAStrategy } from 'passport-provider-a';
+export type ProviderAProviderOptions = OAuthProviderOptions & {
+ // extra options here
+}
+
export class ProviderAAuthProvider implements OAuthProviderHandlers {
- private readonly providerConfig: AuthProviderConfig;
private readonly _strategy: ProviderAStrategy;
- constructor(providerConfig: AuthProviderConfig) {
- this.providerConfig = providerConfig;
+ constructor(options: ProviderAProviderOptions) {
this._strategy = new ProviderAStrategy(
- { ...providerConfig.options },
+ {
+ clientID: options.clientId,
+ clientSecret: options.clientSecret,
+ callbackURL: options.callbackUrl,
+ passReqToCallback: false as true,
+ response_type: 'code',
+ /// ... etc
+ }
verifyFunction, // See the "Verify Callback" section
);
}
@@ -79,14 +95,18 @@ An non-`OAuth` based provider could implement
[AuthProviderRouteHandlers](#AuthProviderRouteHandlers) instead.
```ts
+type ProviderAOptions = {
+ // ...
+};
+
export class ProviderAAuthProvider implements AuthProviderRouteHandlers {
- private readonly providerConfig: AuthProviderConfig;
private readonly _strategy: ProviderAStrategy;
- constructor(providerConfig: AuthProviderConfig) {
- this.providerConfig = providerConfig;
+ constructor(options: ProviderAOptions) {
this._strategy = new ProviderAStrategy(
- { ...providerConfig.options },
+ {
+ // ...
+ },
verifyFunction, // See the "Verify Callback" section
);
}
@@ -98,31 +118,61 @@ export class ProviderAAuthProvider implements AuthProviderRouteHandlers {
}
```
-#### Create method
+#### Factory function
-Each provider exports a create method that creates the provider instance,
-optionally extending a supported authorization framework. This method exists to
-allow for flexibility if additional frameworks are supported in the future.
+Each provider exports a factory function that instantiates the provider. The
+factory should implement [AuthProviderFactory](#AuthProviderFactory), which
+passes in a object with utilities for configuration, logging, token issuing,
+etc. The factory should return an implementation of
+[AuthProviderRouteHandlers](#AuthProviderRouteHandlers).
-Implementing OAuth by returning an instance of `OAuthProvider` based of the
-provider's class:
+The factory is what decides the mapping from
+[static configuration](../conf/index.md) to the creation of auth providers. For
+example, OAuth providers use `OAuthEnvironmentHandler` to allow for multiple
+different configurations, one for each environment, which looks like this;
```ts
-export function createProviderAProvider(config: AuthProviderConfig) {
- const provider = new ProviderAAuthProvider(config);
- const oauthProvider = new OAuthProvider(provider, config.provider, true);
- return oauthProvider;
-}
+export const createOktaProvider: AuthProviderFactory = ({
+ globalConfig,
+ config,
+ tokenIssuer,
+}) =>
+ OAuthEnvironmentHandler.mapConfig(config, envConfig => {
+ // read options from config
+ const clientId = envConfig.getString('clientId');
+ const clientSecret = envConfig.getString('clientSecret');
+
+ // instantiate our OAuthProviderHandlers implementation
+ const provider = new OktaAuthProvider({
+ audience,
+ clientId,
+ clientSecret,
+ callbackUrl,
+ });
+
+ // Wrap the OAuthProviderHandlers with OAuthProvider, which implements AuthProviderRouteHandlers
+ return OAuthProvider.fromConfig(globalConfig, provider, {
+ disableRefresh: false,
+ providerId,
+ tokenIssuer,
+ });
+ });
```
-Not extending with OAuth, the main difference here is that the create method is
-returning a instance of the class without adding the OAuth authorization
-framework to it.
+The purpose of the different environments is to allow for a single auth-backend
+to serve as the authentication service for multiple different frontend
+environments, such as local development, staging, and production.
+
+The factory function for other providers can be a lot simpler, as they might not
+have configuration for each environment. Looking something like this:
```ts
-export function createProviderAProvider(config: AuthProviderConfig) {
- return new ProviderAAuthProvider(config);
-}
+export const createProviderAProvider: AuthProviderFactory = ({ config }) => {
+ const a = config.getString('a');
+ const b = config.getString('b');
+
+ return new ProviderAAuthProvider({ a, b });
+};
```
#### Verify Callback
@@ -141,7 +191,7 @@ export function createProviderAProvider(config: AuthProviderConfig) {
> http://www.passportjs.org/docs/configure/
**`plugins/auth-backend/src/providers/providerA/index.ts`** is simply
-re-exporting the create method to be used for hooking the provider up to the
+re-exporting the factory function to be used for hooking the provider up to the
backend.
```ts
@@ -150,26 +200,14 @@ export { createProviderAProvider } from './provider';
### Hook it up to the backend
-**`plugins/auth-backend/src/providers/config.ts`** The provider needs to be
-configured properly so you need to add it to the list of configured providers,
-all of which implement [AuthProviderConfig](#AuthProviderConfig):
-
-```ts
-export const providers = [
- {
- provider: 'providerA', # used as an identifier
- options: { ... }, # consult the provider documentation for which options you should provide
- disableRefresh: true # if the provider lacks refresh tokens
- },
-```
-
**`plugins/auth-backend/src/providers/factories.ts`** When the `auth-backend`
starts it sets up routing for all the available providers by calling
-`createAuthProviderRouter` on each provider. You need to import the create
-method from the provider and add it to the factory:
+`createAuthProviderRouter` on each provider. You need to import the factory
+function from the provider and add it to the factory:
```ts
import { createProviderAProvider } from './providerA';
+
const factories: { [providerId: string]: AuthProviderFactory } = {
providerA: createProviderAProvider,
};
@@ -200,10 +238,21 @@ web browser and you should be able to trigger the authorization flow.
```ts
export interface OAuthProviderHandlers {
- start(req: express.Request, options: any): Promise;
- handler(req: express.Request): Promise;
- refresh?(refreshToken: string, scope: string): Promise;
- logout?(): Promise;
+ start(
+ req: express.Request,
+ options: Record,
+ ): Promise;
+ handler(
+ req: express.Request,
+ ): Promise<{
+ response: AuthResponse;
+ refreshToken?: string;
+ }>;
+ refresh?(
+ refreshToken: string,
+ scope: string,
+ ): Promise>;
+ logout?(): Promise;
}
```
@@ -218,12 +267,17 @@ export interface AuthProviderRouteHandlers {
}
```
-##### AuthProviderConfig
+##### AuthProviderFactory
```ts
-export type AuthProviderConfig = {
- provider: string;
- options: any;
- disableRefresh?: boolean;
+export type AuthProviderFactoryOptions = {
+ globalConfig: AuthProviderConfig;
+ config: Config;
+ logger: Logger;
+ tokenIssuer: TokenIssuer;
};
+
+export type AuthProviderFactory = (
+ options: AuthProviderFactoryOptions,
+) => AuthProviderRouteHandlers;
```
diff --git a/docs/auth/auth-backend-classes.md b/docs/auth/auth-backend-classes.md
new file mode 100644
index 0000000000..0147c66dd9
--- /dev/null
+++ b/docs/auth/auth-backend-classes.md
@@ -0,0 +1,132 @@
+---
+id: auth-backend-classes
+title: Auth backend classes
+---
+
+## How Does Authentication Work?
+
+The Backstage application can use various authentication providers for
+authentication. A provider has to implement an `AuthProviderRouteHandlers`
+interface for handling authentication. This interface consists of four methods.
+Each of these methods is hosted at an endpoint `/auth/[provider]/method`, where
+`method` performs a certain operation as follows:
+
+```
+ /auth/[provider]/start -> start
+ /auth/[provider]/handler/frame -> frameHandler
+ /auth/[provider]/refresh -> refresh
+ /auth/[provider]/logout -> logout
+```
+
+For more information on how these methods are used and for which purpose, refer
+to the documentation [here](oauth.md).
+
+For details on the parameters, input and output conditions for each method,
+refer to the type documentation under
+`plugins/auth-backend/src/providers/types.ts`.
+
+There are currently two different classes for two authentication mechanisms that
+implement this interface: an `OAuthAdapter` for [OAuth](https://oauth.net/2/)
+based mechanisms and a `SAMLAuthProvider` for
+[SAML](http://docs.oasis-open.org/security/saml/Post2.0/sstc-saml-tech-overview-2.0.html)
+based mechanisms.
+
+### OAuth mechanisms
+
+Currently OAuth is assumed to be the de facto authentication mechanism for
+Backstage based applications.
+
+Backstage comes with a "batteries-included" set of supported commonly used OAuth
+providers: Okta, Github, Google, Gitlab, and a generic OAuth2 provider.
+
+All of these use the authorization flow of OAuth2 to implement authentication.
+
+If your authentication provider is any of the above mentioned (except generic
+OAuth2) providers, you can configure them by setting the right variables in
+`app-config.yaml` under the `auth` section.
+
+### Configuration
+
+Each authentication provider (except SAML) needs five parameters: an OAuth
+client ID, a client secret, an authorization endpoint and a token endpoint, and
+an app origin. The app origin is the URL at which the frontend of the
+application is hosted, and it is read from the `app.baseUrl` config. This is
+required because the application opens a popup window to perform the
+authentication, and once the flow is completed, the popup window sends a
+`postMessage` to the frontend application to indicate the result of the
+operation. Also this URL is used to verify that authentication requests are
+coming from only this endpoint.
+
+These values are configured via the `app-config.yaml` present in the root of
+your app folder.
+
+```
+auth:
+ providers:
+ google:
+ development:
+ clientId:
+ $secret:
+ env: AUTH_GOOGLE_CLIENT_ID
+ clientSecret:
+ $secret:
+ env: AUTH_GOOGLE_CLIENT_SECRET
+ github:
+ development:
+ clientId:
+ $secret:
+ env: AUTH_GITHUB_CLIENT_ID
+ clientSecret:
+ $secret:
+ env: AUTH_GITHUB_CLIENT_SECRET
+ enterpriseInstanceUrl:
+ $secret:
+ env: AUTH_GITHUB_ENTERPRISE_INSTANCE_URL
+ gitlab:
+ development:
+ clientId:
+ $secret:
+ ...
+```
+
+## Technical Notes
+
+### OAuthEnvironmentHandler
+
+The concept of an "env" is core to the way the auth backend works. It uses an
+`env` query parameter to identify the environment in which the application is
+running (`development`, `staging`, `production`, etc). Each runtime can support
+multiple environments at the same time and the right handler for each request is
+identified and dispatched to based on the `env` parameter. All
+`AuthProviderRouteHandlers` are wrapped within an `OAuthEnvironmentHandler`.
+
+To instantiate multiple OAuth providers for different environments, use
+`OAuthEnvironmentHandler.mapConfig`. It's a helper to iterate over a
+configuration object that is a map of environment to configurations. See one of
+the existing OAuth providers for an example of how it is used.
+
+Given the following configuration:
+
+```yaml
+development:
+ clientId: abc
+ clientSecret: secret
+production:
+ clientId: xyz
+ clientSecret: supersecret
+```
+
+The `OAuthEnvironmentHandler.mapConfig(config, envConfig => ...)` call will
+split the `config` by the top level `development` and `production` keys, and
+pass on each block as `envConfig`.
+
+For a list of currently available providers, look in the `factories` module
+located in `plugins/auth-backend/src/providers/factories.ts`
+
+### OAuth2 provider
+
+The `oauth2` provider abstracts a generic **OAuth2 + OIDC** based authentication
+provider. What this means is that after the application has been given
+permission by the user, the `authorization code` will be exchanged for an
+`access_token`, a `refresh_token` and an `id_token`. This `id_token` is used to
+obtain an email id of the user, which is then used for creating the session.
diff --git a/docs/auth/auth-backend.md b/docs/auth/auth-backend.md
index e69de29bb2..579d2e2cda 100644
--- a/docs/auth/auth-backend.md
+++ b/docs/auth/auth-backend.md
@@ -0,0 +1,6 @@
+---
+id: auth-backend
+title: Auth backend
+---
+
+## TODO
diff --git a/docs/auth/glossary.md b/docs/auth/glossary.md
index 6408587273..607326b3a5 100644
--- a/docs/auth/glossary.md
+++ b/docs/auth/glossary.md
@@ -1,4 +1,7 @@
-# Glossary
+---
+id: glossary
+title: Glossary
+---
- **Popup** - A separate browser window opened on top of the previous one.
- **OAuth** - More specifically OAuth 2.0, a standard protocol for
diff --git a/docs/auth/index.md b/docs/auth/index.md
index 6f9af17cba..b885db0820 100644
--- a/docs/auth/index.md
+++ b/docs/auth/index.md
@@ -1,4 +1,7 @@
-# User Authentication and Authorization in Backstage
+---
+id: index
+title: User Authentication and Authorization in Backstage
+---
## Summary
diff --git a/docs/auth/oauth.md b/docs/auth/oauth.md
index d348dd2f93..b7013a310d 100644
--- a/docs/auth/oauth.md
+++ b/docs/auth/oauth.md
@@ -1,4 +1,7 @@
-# OAuth and OpenID Connect
+---
+id: oauth
+title: OAuth and OpenID Connect
+---
This section describes how Backstage allows plugins to request OAuth Access
Tokens and OpenID Connect ID Tokens on behalf of the user, to be used for auth
@@ -101,6 +104,8 @@ request an access token.
The following diagram visualizes the flow described in the previous section.
+
+
-
-
diff --git a/docs/conf/defining.md b/docs/conf/defining.md
index 0b15108f43..b28d6b8362 100644
--- a/docs/conf/defining.md
+++ b/docs/conf/defining.md
@@ -1,4 +1,7 @@
-# Defining Configuration for your Plugin
+---
+id: defining
+title: Defining Configuration for your Plugin
+---
There is currently no tooling support or helpers for defining plugin
configuration. But it's on the roadmap.
diff --git a/docs/conf/index.md b/docs/conf/index.md
index af1635d627..bc1d7e8e1f 100644
--- a/docs/conf/index.md
+++ b/docs/conf/index.md
@@ -1,4 +1,7 @@
-# Static Configuration in Backstage
+---
+id: index
+title: Static Configuration in Backstage
+---
## Summary
diff --git a/docs/conf/reading.md b/docs/conf/reading.md
index 9979f0360e..76d1f7f6ea 100644
--- a/docs/conf/reading.md
+++ b/docs/conf/reading.md
@@ -1,4 +1,7 @@
-# Reading Backstage Configuration
+---
+id: reading
+title: Reading Backstage Configuration
+---
## Config API
@@ -98,7 +101,7 @@ A good pattern for reading optional configuration values is to use the `??`
operator. For example:
```ts
-const title = config.getString('my-plugin.title') ?? 'My Plugin';
+const title = config.getOptionalString('my-plugin.title') ?? 'My Plugin';
```
To read required configuration, simply use the methods without `Optional`, for
diff --git a/docs/conf/writing.md b/docs/conf/writing.md
index 8ab397846d..da2a10a86d 100644
--- a/docs/conf/writing.md
+++ b/docs/conf/writing.md
@@ -1,4 +1,7 @@
-# Writing Backstage Configuration Files
+---
+id: writing
+title: Writing Backstage Configuration Files
+---
## File Format
diff --git a/docs/dls/contributing-to-storybook.md b/docs/dls/contributing-to-storybook.md
index 7dbe72f6d3..f0c2201a98 100644
--- a/docs/dls/contributing-to-storybook.md
+++ b/docs/dls/contributing-to-storybook.md
@@ -1,4 +1,10 @@
-# Contributing to Storybook
+---
+id: contributing-to-storybook
+title: Contributing to Storybook
+---
+
+You find our storybook at
+[http://backstage.io/storybook](http://backstage.io/storybook)
## Creating a new Story
@@ -26,7 +32,7 @@ core
Go to `packages/storybook`, run `yarn install` and install the dependencies,
then run the following on your command line: `yarn start`
-
+
_You should see a log like the image above._
@@ -34,4 +40,4 @@ If everything worked out, your server will be running on **port 6006**, go to
your browser and navigate to `http://localhost:6006/`. You should be able to
navigate and see the Storybook page.
-
+
diff --git a/docs/dls/design.md b/docs/dls/design.md
index e3816bd2e5..23ba84024a 100644
--- a/docs/dls/design.md
+++ b/docs/dls/design.md
@@ -1,4 +1,9 @@
-
+---
+id: design
+title: Design
+---
+
+
Much like Backstage Open Source, this is a _living_ document! We'll keep this
updated as we evolve our practices!
@@ -60,7 +65,7 @@ that is shaped by user experience and user interface decisions made by our
Backstage Design Team. Also note, we encourage you to take the core experience
we’ve crafted and add custom theming to better represent your organization!
-
+
## ✅ Our Priorities
@@ -106,18 +111,17 @@ picked up by our team as something to be added to our design system.
## ✏️ Resources
-**[Storybook](http://storybook.backstage.io/)** - where you can view our
+**[Storybook](http://backstage.io/storybook)** - where you can view our
components. If you’d like to help build up our design system, you can also add
components we’ve designed to the Storybook as well.
+**[Figma](https://www.figma.com/@backstage)** - we're stoked to be using Figma
+Community to share our design assets. You can duplicate our UI Kit
+and design your own plugin for Backstage.
+
**[Discord](https://discord.gg/EBHEGzX)** - all design questions should be
directed to the _#design_ channel.
-**Documentation**
-
-- Patterns (stay tuned)
-- Figma files/libraries (stay tuned)
-
## 🔮 Future
### Contributions from designers
diff --git a/docs/dls/figma.md b/docs/dls/figma.md
index 8fe6ea8d0f..14de2f5980 100644
--- a/docs/dls/figma.md
+++ b/docs/dls/figma.md
@@ -1 +1,7 @@
-We have a [Figma component library](https://www.figma.com/@backstage) that you can use to build your own plugins for Backstage.
+---
+id: figma
+title: Figma
+---
+
+We have a [Figma component library](https://www.figma.com/@backstage) that you
+can use to build your own plugins for Backstage.
diff --git a/docs/features/software-catalog/api.md b/docs/features/software-catalog/api.md
index e69de29bb2..332c1e505b 100644
--- a/docs/features/software-catalog/api.md
+++ b/docs/features/software-catalog/api.md
@@ -0,0 +1,6 @@
+---
+id: software-catalog-api
+title: API
+---
+
+## TODO
diff --git a/docs/features/software-catalog/configuration.md b/docs/features/software-catalog/configuration.md
new file mode 100644
index 0000000000..be6314e494
--- /dev/null
+++ b/docs/features/software-catalog/configuration.md
@@ -0,0 +1,58 @@
+---
+id: software-catalog-configuration
+title: Catalog Configuration
+---
+
+## Static Location Configuration
+
+To enable declarative catalog setups, it is possible to add locations to the
+catalog via [static configuration](../../conf/index.md). Locations are added to
+the catalog under the `catalog.locations` key, for example:
+
+```yaml
+catalog:
+ locations:
+ - type: github
+ target: https://github.com/spotify/backstage/blob/master/packages/catalog-model/examples/artist-lookup-component.yaml
+```
+
+The locations added through static configuration can not be removed through the
+catalog locations API. To remove the locations, you have to remove them from the
+configuration.
+
+## Catalog Rules
+
+By default the catalog will only allow ingestion of entities with the kind
+`Component`, `API` and `Location`. In order to allow entities of other kinds to
+be added, you need to add rules to the catalog. Rules are added either in a
+separate `catalog.rules` key, or added to statically configured locations.
+
+For example, given the following configuration:
+
+```yaml
+catalog:
+ rules:
+ - allow: [Component, API, Location, Template]
+
+ locations:
+ - type: github
+ target: https://github.com/org/example/blob/master/org-data.yaml
+ rules:
+ - allow: [Group]
+```
+
+We are able to add entities of kind `Component`, `API`, `Location`, or
+`Template` from any location, and `Group` entities from the `org-data.yaml`,
+which will also be read as statically configured location.
+
+Note that if the `catalog.rules` key is present it will replace the default
+value, meaning that you need to add rules for the default kinds if you want
+those to still be allowed.
+
+The following configuration will reject any kind of entities from being added to
+the catalog:
+
+```yaml
+catalog:
+ rules: []
+```
diff --git a/docs/features/software-catalog/descriptor-format.md b/docs/features/software-catalog/descriptor-format.md
index 68cee2352c..78dfcf365c 100644
--- a/docs/features/software-catalog/descriptor-format.md
+++ b/docs/features/software-catalog/descriptor-format.md
@@ -1,4 +1,8 @@
-# Descriptor Format of Catalog Entities
+---
+id: descriptor-format
+title: Descriptor Format of Catalog Entities
+sidebar_label: YAML File Format
+---
This section describes the default data shape and semantics of catalog entities.
@@ -14,6 +18,8 @@ humans. However, the structure and semantics is the same in both cases.
- [Common to All Kinds: The Envelope](#common-to-all-kinds-the-envelope)
- [Common to All Kinds: The Metadata](#common-to-all-kinds-the-metadata)
- [Kind: Component](#kind-component)
+- [Kind: Template](#kind-template)
+- [Kind: API](#kind-api)
## Overall Shape Of An Entity
@@ -36,6 +42,7 @@ software catalog API.
"labels": {
"system": "public-websites"
},
+ "tags": ["java"],
"name": "artist-web",
"uid": "2152f463-549d-4d8d-a94d-ce2b7676c6e2"
},
@@ -60,6 +67,8 @@ metadata:
annotations:
example.com/service-discovery: artistweb
circleci.com/project-slug: gh/example-org/artist-website
+ tags:
+ - java
spec:
type: website
lifecycle: production
@@ -80,7 +89,7 @@ The root envelope object has the following structure.
### `apiVersion` and `kind` [required]
The `kind` is the high level entity type being described.
-[ADR005](/docs/architecture-decisions/adr005-catalog-core-entities.md) describes
+[ADR005](../../architecture-decisions/adr005-catalog-core-entities.md) describes
a number of core kinds that plugins can know of and understand, but an
organization using Backstage is free to also add entities of other kinds to the
catalog.
@@ -226,6 +235,20 @@ The `backstage.io/` prefix is reserved for use by Backstage core components.
Values can be of any length, but are limited to being strings.
+### `tags` [optional]
+
+A list of single-valued strings, for example to classify catalog entities in
+various ways. This is different to the labels in metadata, as labels are
+key-value pairs.
+
+The values are user defined, for example the programming language used for the
+component, like `java` or `go`.
+
+This field is optional, and currently has no special semantics.
+
+Each tag must be sequences of `[a-zA-Z0-9]` separated by `-`, at most 63
+characters in total.
+
## Kind: Component
Describes the following entity kind:
@@ -252,6 +275,8 @@ spec:
type: website
lifecycle: production
owner: artist-relations@example.com
+ implementsApis:
+ - artist-api
```
In addition to the [common envelope metadata](#common-to-all-kinds-the-metadata)
@@ -312,14 +337,22 @@ Apart from being a string, the software catalog leaves the format of this field
open to implementers to choose. Most commonly, it is set to the ID or email of a
group of people in an organizational structure.
+### `spec.implementsApis` [optional]
+
+Links APIs that are implemented by the component, e.g. `artist-api`. This field
+is optional.
+
+The software catalog expects a list of one or more strings that references the
+names of other entities of the `kind` `API`.
+
## Kind: Template
Describes the following entity kind:
-| Field | Value |
-| -------------------- | ----------------------- |
-| `apiVersion` | `backstage.io/v1alpha1` |
-| `Kind: Templatekind` | `Template` |
+| Field | Value |
+| ------------ | ----------------------- |
+| `apiVersion` | `backstage.io/v1alpha1` |
+| `kind` | `Template` |
A Template describes a skeleton for use with the Scaffolder. It is used for
describing what templating library is supported, and also for documenting the
@@ -337,8 +370,8 @@ metadata:
description:
Next.js application skeleton for creating isomorphic web applications.
tags:
- - Recommended
- - React
+ - recommended
+ - react
spec:
owner: web@example.com
templater: cookiecutter
@@ -422,3 +455,76 @@ specify relative to the `template.yaml` definition.
This is also particularly useful when you have multiple template definitions in
the same repository but only a single `template.yaml` registered in backstage.
+
+## Kind: API
+
+Describes the following entity kind:
+
+| Field | Value |
+| ------------ | ----------------------- |
+| `apiVersion` | `backstage.io/v1alpha1` |
+| `kind` | `API` |
+
+An API describes an interface that can be exposed by a component. The API can be
+defined in different formats, like [OpenAPI](https://swagger.io/specification/),
+[AsyncAPI](https://www.asyncapi.com/docs/specifications/latest/),
+[gRPC](https://developers.google.com/protocol-buffers), or other formats.
+
+Descriptor files for this kind may look as follows.
+
+```yaml
+apiVersion: backstage.io/v1alpha1
+kind: API
+metadata:
+ name: artist-api
+ description: Retrieve artist details
+spec:
+ type: openapi
+ definition: |
+ openapi: "3.0.0"
+ info:
+ version: 1.0.0
+ title: Artist API
+ license:
+ name: MIT
+ servers:
+ - url: http://artist.spotify.net/v1
+ paths:
+ /artists:
+ get:
+ summary: List all artists
+ ...
+```
+
+In addition to the [common envelope metadata](#common-to-all-kinds-the-metadata)
+shape, this kind has the following structure.
+
+### `apiVersion` and `kind` [required]
+
+Exactly equal to `backstage.io/v1alpha1` and `API`, respectively.
+
+### `spec.type` [required]
+
+The type of the API definition as a string, e.g. `openapi`. This field is
+required.
+
+The software catalog accepts any type value, but an organisation should take
+great care to establish a proper taxonomy for these. Tools including Backstage
+itself may read this field and behave differently depending on its value. For
+example, an OpenAPI type API may be displayed using an OpenAPI viewer tooling in
+the Backstage interface.
+
+The current set of well-known and common values for this field is:
+
+- `openapi` - An API definition in YAML or JSON format based on the
+ [OpenAPI](https://swagger.io/specification/) version 2 or version 3 spec.
+- `asyncapi` - An API definition based on the
+ [AsyncAPI](https://www.asyncapi.com/docs/specifications/latest/) spec.
+- `grpc` - An API definition based on
+ [Protocol Buffers](https://developers.google.com/protocol-buffers) to use with
+ [gRPC](https://grpc.io/).
+
+### `spec.definition` [required]
+
+The definition of the API, based on the format defined by `spec.type`. This
+field is required.
diff --git a/docs/features/software-catalog/extending-the-model.md b/docs/features/software-catalog/extending-the-model.md
index e69de29bb2..8b621f2e44 100644
--- a/docs/features/software-catalog/extending-the-model.md
+++ b/docs/features/software-catalog/extending-the-model.md
@@ -0,0 +1,42 @@
+---
+id: extending-the-model
+title: Extending the model
+---
+
+Backstage natively supports tracking of the following component
+[`type`](descriptor-format.md)'s:
+
+- Services
+- Websites
+- Libraries
+- Documentation
+- Other
+
+
+
+Since these types are likely not the only kind of software you will want to
+track in Backstage, it is possible to
+
+It is possible to add your own software types that fits your organization's data
+model. Inside Spotify our model has grown significantly over the years, and now
+includes ML models, Apps, data pipelines and many more.
+
+## Adding a new type
+
+TODO: Describe what changes are needed to add a new type that shows up in the
+catalog.
+
+## The Other type
+
+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 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)
+only makes sense for Websites. The more specific you can be in how you model
+your software, the easier it is to provide plugins that are contextual.
diff --git a/docs/features/software-catalog/external-integrations.md b/docs/features/software-catalog/external-integrations.md
index e69de29bb2..7ca869cdae 100644
--- a/docs/features/software-catalog/external-integrations.md
+++ b/docs/features/software-catalog/external-integrations.md
@@ -0,0 +1,11 @@
+---
+id: external-integrations
+title: External integrations
+---
+
+Backstage natively supports storing software components in
+[metadata YAML files](descriptor-format.md). However, companies that already
+have an existing system for keeping track of software and its owners can
+integrate such systems with Backstage.
+
+TODO: Describe the API contract.
diff --git a/docs/features/software-catalog/index.md b/docs/features/software-catalog/index.md
index 4925f32e1a..bfc3d53d4d 100644
--- a/docs/features/software-catalog/index.md
+++ b/docs/features/software-catalog/index.md
@@ -1,4 +1,8 @@
-# Backstage Service Catalog (alpha)
+---
+id: software-catalog-overview
+title: Backstage Service Catalog (alpha)
+sidebar_label: Backstage Service Catalog
+---
## What is a Service Catalog?
@@ -6,21 +10,132 @@ The Backstage Service Catalog — actually, a software catalog, since it include
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](../../architecture-decisions/adr002-default-catalog-file-format.md#format)
-stored together with the code, which are then harvested and visualized in
-Backstage.
+[metadata YAML files](descriptor-format.md) stored together with the code, which
+are then harvested and visualized in Backstage.

-We have also 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.
+## How it works
-## Using the Service Catalog
+Backstage and the Backstage Service Catalog makes it easy for one team to manage
+10 services — and makes it possible for your company to manage thousands of
+them.
-TODO
+More specifically, the Service Catalog enables two main use-cases:
-
+1. Helping teams manage and maintain the software they own. Teams get a uniform
+ view of all their software; services, libraries, websites, ML models — you
+ name it, Backstage knows all about it.
+2. Makes all the software in your company, and who owns it, discoverable. No
+ more orphan software hiding in the dark corners of your software ecosystem.
+
+## Getting Started
+
+The Software Catalog is available to browse on the start page at `/`. If you've
+followed [Installing in your Backstage App](./installation.md) in your separate
+App or [Getting Started with Backstage](../../getting-started) for this repo,
+you should be able to browse the catalog at `http://localhost:3000`.
+
+
+
+## Adding components to the catalog
+
+The source of truth for the components in your service catalog are
+[metadata YAML files](descriptor-format.md) stored in source control (GitHub,
+GitHub Enterprise, GitLab, ...).
+
+There are 3 ways to add components to the catalog:
+
+1. Manually register components
+2. Creating new components through Backstage
+3. Integrating with and [external source](external-integrations.md)
+
+### Manually register components
+
+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
+offering, for example) it is still useful to create components for tracking
+ownership.
+
+### Creating new components through Backstage
+
+All software created through the
+[Backstage Software Templates](../software-templates/index.md) are automatically
+registered in the catalog.
+
+### Static catalog configuration
+
+In addition to manually registering components, it is also possible to register
+components though [static configuration](../../conf/index.md). For example, the
+above example can be added using the following configuration:
+
+```yaml
+catalog:
+ locations:
+ - type: github
+ target: https://github.com/spotify/backstage/blob/master/packages/catalog-model/examples/artist-lookup-component.yaml
+```
+
+More information about catalog configuration can be found
+[here](configuration.md).
+
+### Updating component metadata
+
+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.
+
+## Finding software in the catalog
+
+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
+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 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 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.
+
+
+
+The Backstage platform can be customized by incorporating
+[existing open source plugins](https://github.com/spotify/backstage/tree/master/plugins),
+or by [building your own](../../plugins/index.md).
+
+## Links
+
+- [[Blog post] Backstage Service Catalog released in alpha](https://backstage.io/blog/2020/06/22/backstage-service-catalog-alpha)
diff --git a/docs/features/software-catalog/installation.md b/docs/features/software-catalog/installation.md
new file mode 100644
index 0000000000..397abcc6b0
--- /dev/null
+++ b/docs/features/software-catalog/installation.md
@@ -0,0 +1,193 @@
+# Installing in your Backstage App
+
+The catalog plugin comes in two packages, `@backstage/plugin-catalog` and
+`@backstage/plugin-catalog-backend`. Each has their own installation steps,
+outlined below.
+
+## Installing @backstage/plugin-catalog
+
+> **Note that if you used `npx @backstage/create-app`, the plugin may already be
+> present**
+
+The catalog frontend plugin should be installed in your `app` package, which is
+created as a part of `@backstage/create-app`. To install the package, run:
+
+```bash
+cd packages/app
+yarn add @backstage/plugin-catalog
+```
+
+Make sure the version of `@backstage/plugin-catalog` matches the version of
+other `@backstage` packages. You can update it in `packages/app/package.json` if
+it doesn't.
+
+### Adding the Plugin to your `packages/app`
+
+Add the following entry to the head of your `packages/app/src/plugins.ts`:
+
+```ts
+export { plugin as CatalogPlugin } from '@backstage/plugin-catalog';
+```
+
+Add the following to your `packages/app/src/apis.ts`:
+
+```ts
+import { catalogApiRef, CatalogClient } from '@backstage/plugin-catalog';
+
+// Inside the ApiRegistry builder function ...
+
+builder.add(
+ catalogApiRef,
+ new CatalogClient({
+ apiOrigin: backendUrl,
+ basePath: '/catalog',
+ }),
+);
+```
+
+Where `backendUrl` is the `backend.baseUrl` from config, i.e.
+`const backendUrl = config.getString('backend.baseUrl')`.
+
+The catalog components depend on a number of other
+[Utility APIs](../../api/utility-apis.md) to function, including at least the
+`ErrorApi` and `StorageApi`. You can find an example of how to install these in
+your app
+[here](https://github.com/spotify/backstage/blob/61c3a7e5b750dc7c059ef16b188594d31b2c04c2/packages/app/src/apis.ts#L80).
+
+## Gotchas that we will fix
+
+Since the catalog plugin currently ships with a sentry plugin `InfoCard`
+installed by default, you'll need to set `sentry.organization` in your
+`app-yaml.yaml`. For example:
+
+```yaml
+sentry:
+ organization: Acme Corporation
+```
+
+If you've created an app with an older version of `@backstage/create-app` or
+`@backstage/cli create-app`, be sure to remove the Welcome plugin from the app,
+as that will conflict with the catalog routes.
+
+## Installing @backstage/plugin-catalog-backend
+
+> **Note that if you used `npx @backstage/create-app`, the plugin may already be
+> present**
+
+The catalog backend should be installed in your `backend` package, which is
+created as a part of `@backstage/create-app`. To install the package, run:
+
+```bash
+cd packages/backend
+yarn add @backstage/plugin-catalog-backend
+```
+
+Make sure the version of `@backstage/plugin-catalog-backend` matches the version
+of other `@backstage` packages. You can update it in
+`packages/backend/package.json` if it doesn't.
+
+### Adding the Plugin to your `packages/backend`
+
+You'll need to add the plugin to the `backend`'s router. You can do this by
+creating a file called `packages/backend/src/plugins/catalog.ts` with the
+following contents to get you up and running quickly.
+
+```ts
+import {
+ createRouter,
+ DatabaseEntitiesCatalog,
+ DatabaseLocationsCatalog,
+ DatabaseManager,
+ HigherOrderOperations,
+ LocationReaders,
+ runPeriodically,
+} from '@backstage/plugin-catalog-backend';
+import { PluginEnvironment } from '../types';
+import { useHotCleanup } from '@backstage/backend-common';
+
+export default async function createPlugin({
+ logger,
+ database,
+}: PluginEnvironment) {
+ const locationReader = new LocationReaders(logger);
+
+ const db = await DatabaseManager.createDatabase(database, { logger });
+ const entitiesCatalog = new DatabaseEntitiesCatalog(db);
+ const locationsCatalog = new DatabaseLocationsCatalog(db);
+ const higherOrderOperation = new HigherOrderOperations(
+ entitiesCatalog,
+ locationsCatalog,
+ locationReader,
+ logger,
+ );
+
+ useHotCleanup(
+ module,
+ runPeriodically(() => higherOrderOperation.refreshAllLocations(), 10000),
+ );
+
+ return await createRouter({
+ entitiesCatalog,
+ locationsCatalog,
+ higherOrderOperation,
+ logger,
+ });
+}
+```
+
+Once the `catalog.ts` router setup file is in place, add the router to
+`packages/backend/src/index.ts`:
+
+```ts
+import catalog from './plugins/catalog';
+
+const catalogEnv = useHotMemoize(module, () => createEnv('catalog'));
+
+const service = createServiceBuilder(module)
+ .loadConfig(configReader)
+ /** several different routers */
+ .addRouter('/catalog', await catalog(catalogEnv));
+```
+
+### Adding Entries to the Catalog
+
+At this point the catalog backend is installed in your backend package, but you
+will not have any entities loaded.
+
+To get up and running and try out some templates quickly, you can add some of
+our example templates through static configuration. Add the following to the
+`catalog.locations` section in your `app-config.yaml`:
+
+```yaml
+catalog:
+ locations:
+ # Backstage Example Component
+ - type: github
+ target: https://github.com/spotify/backstage/blob/master/packages/catalog-model/examples/artist-lookup-component.yaml
+ - type: github
+ target: https://github.com/spotify/backstage/blob/master/packages/catalog-model/examples/playback-order-component.yaml
+ - type: github
+ target: https://github.com/spotify/backstage/blob/master/packages/catalog-model/examples/podcast-api-component.yaml
+ - type: github
+ target: https://github.com/spotify/backstage/blob/master/packages/catalog-model/examples/queue-proxy-component.yaml
+ - type: github
+ target: https://github.com/spotify/backstage/blob/master/packages/catalog-model/examples/searcher-component.yaml
+ - type: github
+ target: https://github.com/spotify/backstage/blob/master/packages/catalog-model/examples/playback-lib-component.yaml
+ - type: github
+ target: https://github.com/spotify/backstage/blob/master/packages/catalog-model/examples/www-artist-component.yaml
+ - type: github
+ target: https://github.com/spotify/backstage/blob/master/packages/catalog-model/examples/shuffle-api-component.yaml
+```
+
+### Running the Backend
+
+Finally, start up the backend with the new configuration:
+
+```bash
+cd packages/backend
+yarn start
+```
+
+If you've also set up the frontend plugin, so you should be ready to go browse
+the catalog at [localhost:3000](http://localhost:3000) now!
diff --git a/docs/features/software-catalog/system-model.md b/docs/features/software-catalog/system-model.md
index e69de29bb2..4436f60fc2 100644
--- a/docs/features/software-catalog/system-model.md
+++ b/docs/features/software-catalog/system-model.md
@@ -0,0 +1,116 @@
+---
+id: system-model
+title: System Model
+---
+
+We believe that a strong shared understanding and terminology around software
+and resources leads to a better Backstage experience.
+
+_This description originates from
+[this RFC](https://github.com/spotify/backstage/issues/390). Note that some of
+the concepts are not yet supported in Backstage._
+
+## Core Entities
+
+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
+
+A component is a piece of software, for example a mobile feature, web site,
+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.
+
+### 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.
+
+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.
+
+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
+consumers), or private (only available within their system). As public APIs are
+going to be the primary way interaction between components, Backstage supports
+documenting, indexing and searching all APIs so we can browse them as
+developers.
+
+### Resource
+
+Resources are the infrastructure a component needs to operate at runtime, like
+BigTable databases, Pub/Sub topics, S3 buckets or CDNs. Modelling them together
+with components and systems will better allow us to visualize resource
+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
+
+### System
+
+With increasing complexity in software, systems form an important abstraction
+level to help us reason about software ecosystems. Systems are a useful concept
+in that they allow us to ignore the implementation details of a certain
+functionality for consumers, while allowing the owning team to make changes as
+they see fit (leading to low coupling).
+
+A system, in this sense, is a collection of resources and components that
+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).
+
+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
+bounded context.
+
+For example, it would make sense if the different systems in the “Payments”
+domain would come with some documentation on how to accept payments for a new
+product or use-case, share the same entity types in their APIs, and integrate
+well with each other. Other domains could be “Content Ingestion”, “Ads” or
+“Search”.
+
+## Current status
+
+Backstage currently supports Components and APIs.
+
+## Links
+
+- [Original RFC](https://github.com/spotify/backstage/issues/390)
+- [YAML file format](../../architecture-decisions/adr002-default-catalog-file-format.md)
diff --git a/docs/features/software-templates/adding-templates.md b/docs/features/software-templates/adding-templates.md
index bf540d656a..4f7af7c015 100644
--- a/docs/features/software-templates/adding-templates.md
+++ b/docs/features/software-templates/adding-templates.md
@@ -1,4 +1,7 @@
-# Adding your own Templates
+---
+id: adding-templates
+title: Adding your own Templates
+---
Templates are stored in the **Service Catalog** under a kind `Template`. The
minimum that the a template skeleton needs is a `template.yaml` but it would be
@@ -15,11 +18,12 @@ metadata:
# title of the template
title: React SSR Template
# a description of the template
- description: Next.js application skeleton for creating isomorphic web applications.
+ description:
+ Next.js application skeleton for creating isomorphic web applications.
# some tags to display in the frontend
tags:
- - Recommended
- - React
+ - recommended
+ - react
spec:
# which templater key to use in the templaters builder
templater: cookiecutter
@@ -39,7 +43,7 @@ spec:
type: string
description: Unique name of the component
description:
- title: Description
+ title: Description
type: string
description: Description of the component
```
@@ -50,11 +54,34 @@ contains more information about the required fields.
Once we have a `template.yaml` ready, we can then add it to the service catalog
for use by the scaffolder.
-Currently the catalog supports loading definitions from Github + Local Files. To
+Currently the catalog supports loading definitions from GitHub + Local Files. To
load from other places, not only will there need to be another preparer, but the
support to load the location will also need to be added to the Catalog.
-For loading from a file the following command should work when the backend is
+You can add the template files to the catalog through
+[static location configuration](../software-catalog/configuration.md#static-location-configuration),
+for example
+
+```yaml
+catalog:
+ locations:
+ - type: github
+ target: https://github.com/spotify/cookiecutter-golang/blob/master/template.yaml
+ rules:
+ - allow: [Template]
+```
+
+Templates can also be added by posting the to the catalog directly. Note that if
+you're doing this, you need to configure the catalog to allow template entities
+to be ingested from any source, for example:
+
+```yaml
+catalog:
+ rules:
+ - allow: [Component, API, Template]
+```
+
+For loading from a file, the following command should work when the backend is
running:
```sh
@@ -65,7 +92,7 @@ curl \
--data-raw "{\"type\": \"file\", \"target\": \"${YOUR PATH HERE}/template.yaml\"}"
```
-If loading from a git location, you can run the following
+If loading from a Git location, you can run the following
```sh
curl \
@@ -79,7 +106,7 @@ This should then have added the catalog, and also should now be listed under the
create page at http://localhost:3000/create.
Alternatively, if you want to get setup with some mock templates that are
-already provided for you, you can run the following to load those templates:
+already provided, run the following to load those templates:
```
yarn lerna run mock-data
diff --git a/docs/features/software-templates/extending/create-your-own-preparer.md b/docs/features/software-templates/extending/create-your-own-preparer.md
index 4e45bef535..0b3fb31323 100644
--- a/docs/features/software-templates/extending/create-your-own-preparer.md
+++ b/docs/features/software-templates/extending/create-your-own-preparer.md
@@ -1,4 +1,7 @@
-# Create your own Preparer
+---
+id: extending-preparer
+title: Create your own Preparer
+---
Preparers are responsible for reading the location of the definition of a
[Template Entity](../../software-catalog/descriptor-format.md#kind-template) and
@@ -51,7 +54,7 @@ The `protocol` is set on the
when added to the service catalog. You can see more about this `PreparerKey`
here in [Register your own template](../adding-templates.md)
-**note:** Currently the catalog supports loading definitions from Github + Local
+**note:** Currently the catalog supports loading definitions from GitHub + Local
Files, which translate into the two `PreparerKeys` `file` and `github`. To load
from other places, not only will there need to be another preparer, but the
support to load the location will also need to be added to the Catalog.
diff --git a/docs/features/software-templates/extending/create-your-own-publisher.md b/docs/features/software-templates/extending/create-your-own-publisher.md
index 8baf604e01..391f6f0658 100644
--- a/docs/features/software-templates/extending/create-your-own-publisher.md
+++ b/docs/features/software-templates/extending/create-your-own-publisher.md
@@ -1,11 +1,14 @@
-# Create your own Publisher
+---
+id: extending-publisher
+title: Create your own Publisher
+---
Publishers are responsible for pushing and storing the templated skeleton after
the values have been templated by the `Templater`. See
[Create your own templater](./create-your-own-templater.md) for more info.
-They recieve a directory or location where the templater has sucessfully run on,
-and is now ready to store somewhere. They also get given some other options
+They receive a directory or location where the templater has sucessfully run
+and is now ready to store somewhere. They also are given some other options
which are sent from the frontend, such as the `storePath` which is a string of
where the frontend thinks we should save this templated folder.
@@ -14,7 +17,7 @@ Currently we provide the following `publishers`:
- `github`
This publisher is passed through to the `createRouter` function of the
-`@spotify/plugin-scaffolder-backend`. Currently only one publisher is supported,
+`@spotify/plugin-scaffolder-backend`. Currently, only one publisher is supported,
but PR's are always welcome.
An full example backend can be found
diff --git a/docs/features/software-templates/extending/create-your-own-templater.md b/docs/features/software-templates/extending/create-your-own-templater.md
index 947190c5e5..9dee66af06 100644
--- a/docs/features/software-templates/extending/create-your-own-templater.md
+++ b/docs/features/software-templates/extending/create-your-own-templater.md
@@ -1,18 +1,21 @@
-# Creating your own Templater
+---
+id: extending-templater
+title: Creating your own Templater
+---
Templaters are responsible for taking the directory path for the skeleton
returned by the preparers, and then executing the templating command on top of
the file and returning the completed template path. This may or may not be the
same directory as the input directory.
-They also recieve additional values from the frontend, which can be used to
+They also receive additional values from the frontend, which can be used to
interpolate into the skeleton files.
Currently we provide the following templaters:
- `cookiecutter`
-This templater is added the `TemplaterBuilder` and then passed into the
+This templater is added to the `TemplaterBuilder` and then passed into the
`createRouter` function of the `@spotify/plugin-scaffolder-backend`
An full example backend can be found
@@ -45,7 +48,7 @@ This `TemplaterKey` is used to select the correct templater from the
`spec.templater` in the
[Template Entity](../../software-catalog/descriptor-format.md#kind-template).
-If you wish to add a new templater you'll need to register it with the
+If you wish to add a new templater, you'll need to register it with the
`TemplaterBuilder`.
### Creating your own Templater to add to the `TemplaterBuilder`
@@ -80,10 +83,10 @@ follows:
- `dockerClient` - a [dockerode](https://github.com/apocas/dockerode) client to
be able to run docker containers.
-_note_ currently the templaters that we provide are basically docker action
+_note_ Currently the templaters that we provide are basically Docker action
containers that are run on top of the skeleton folder. This keeps dependencies
to a minimal for running backstage scaffolder, but you don't /have/ to use
-docker. You could create your own templater that spins up an EC2 instance and
+Docker. You could create your own templater that spins up an EC2 instance and
downloads the folder and does everything using an AMI if you want. It's entirely
up to you!
@@ -113,8 +116,8 @@ metadata:
description:
Next.js application skeleton for creating isomorphic web applications.
tags:
- - Recommended
- - React
+ - recommended
+ - react
spec:
owner: web@example.com
templater: handlebars
@@ -135,7 +138,7 @@ spec:
description: Description of the component
```
-You see that the `spec.templater` is set as `handlebars`, you'll need to
+You see that the `spec.templater` is set as `handlebars`, so you'll need to
register this with the `TemplaterBuilder` like so:
```ts
diff --git a/docs/features/software-templates/extending/index.md b/docs/features/software-templates/extending/index.md
index a55128c57d..02d27a5725 100644
--- a/docs/features/software-templates/extending/index.md
+++ b/docs/features/software-templates/extending/index.md
@@ -1,12 +1,15 @@
-## Extending the Scaffolder
+---
+id: extending-index
+title: Extending the Scaffolder
+---
Welcome. Take a seat. You're at the Scaffolder Documentation.
-So - You wanna create stuff inside your company from some prebaked templates?
+So, you want to create stuff inside your company from some prebaked templates?
You're at the right place.
-This guide is gonna take you through how the Scaffolder in Backstage works.
-We'll dive into some jargon and run through whats going on in the backend to be
+This guide is going to take you through how the Scaffolder in Backstage works.
+We'll dive into some jargon and run through what's going on in the backend to be
able to create these templates. There's also more guides that you might find
useful at the bottom of this document. At it's core, theres 3 simple stages.
@@ -22,9 +25,9 @@ scaffolder that you will need to know:
3. Publish
Each of these steps can be configured for your own use case, but we provide some
-sensible defaults too.
+sensible defaults, too.
-Lets dive a little deeper into these phases.
+Let's dive a little deeper into these phases.
### Glossary and Jargon
@@ -35,8 +38,8 @@ the router to pick the correct `Preparer` to run for the `Template` entity.
**Templater** - The templater is responsible for actually running the chosen
templater on top of the previously returned temporary directory from the
-**Preprarer**. We advise making these docker containers as it can keep all
-dependencies, for example Cookiecutter, self contained and not a dependency on
+**Preprarer**. We advise making these Docker containers as it can keep all
+dependencies--for example Cookiecutter--self contained and not a dependency on
the host machine.
**Publisher** - The publisher is responsible for taking the finished directory,
@@ -47,11 +50,11 @@ passed through to the scaffolder backend.
### How it works
-The main of the heavy lifting is done in the
+Most of the heavy lifting is done in the
[router.ts](https://github.com/spotify/backstage/blob/master/plugins/scaffolder-backend/src/service/router.ts#L93)
file in the `scaffolder-backend` plugin.
-There are 2 routes defined in the router. `POST /v1/jobs` and
+There are two routes defined in the router: `POST /v1/jobs` and
`GET /v1/job/:jobId`
To create a scaffolding job, a JSON object containing the
@@ -75,7 +78,7 @@ additional templating values must be posted as the post body.
The values should represent something that is valid with the `schema` part of
the [Template Entity](../../software-catalog/descriptor-format.md#kind-template)
-Once that has been posted, a job will be setup with different stages. And the
+Once that has been posted, a job will be setup with different stages, and the
job processor will complete each stage before moving onto the next stage, whilst
collecting logs and mutating the running job.
diff --git a/docs/features/software-templates/index.md b/docs/features/software-templates/index.md
index c7358518cd..1c67676b3e 100644
--- a/docs/features/software-templates/index.md
+++ b/docs/features/software-templates/index.md
@@ -1,19 +1,27 @@
-# Software Templates
+---
+id: software-templates-index
+title: Software Templates
+---
The Software Templates part of Backstage is a tool that can help you create
-Components inside Backstage. It by default has the ability to load skeletons of
-code, template in some variables and then publish the template to some location
+Components inside Backstage. By default, it has the ability to load skeletons of
+code, template in some variables, and then publish the template to some location
like GitHub.
+
+
### Getting Started
-The Software Templates are available under `/create`, and if you've followed
-[Getting Started with Backstage](../../getting-started), you should be able to
-reach `http://localhost:3000/create`.
+The Software Templates are available under `/create`. If you've followed
+[Installing in your Backstage App](./installation.md) in your separate App or
+[Getting Started with Backstage](../../getting-started) for this repo, you
+should be able to reach `http://localhost:3000/create`.
You should get something that looks similar to this:
-
+
### Choose a template
@@ -22,38 +30,38 @@ page which may or may not look different for each template. Each template can
ask for different input variables, and they are then passed to the templater
internally.
-
+
After filling in these variables, you'll get some more fields to fill out which
-are required for backstage usage. The owner, which is a `user` in the backstage
-system, and the `storePath` which right now must be a Github Organisation and a
-non-existing github repository name in the format `organistaion/reponame`.
+are required for backstage usage: the owner, (which is a `user` in the backstage
+system), the `storePath` (which right now must be a GitHub Organisation), and a
+non-existing github repository name in the format `organisation/reponame`.
-
+
### 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, and you'll have a success screen!
-
+
If it fails, you'll be able to click on each section to get the log from the
-step that failed which can be helpful to debug.
+step that failed which can be helpful in debugging.
-
+
### View Component in Catalog
-When it's been created you'll see the `View in Catalog` button, which will take
+When it's been created, you'll see the `View in Catalog` button, which will take
you to the registered component in the catalog:
-
+
And then you'll also be able to see it in the Catalog View table
-
+
diff --git a/docs/features/software-templates/installation.md b/docs/features/software-templates/installation.md
new file mode 100644
index 0000000000..73b4f20359
--- /dev/null
+++ b/docs/features/software-templates/installation.md
@@ -0,0 +1,194 @@
+# Installing in your Backstage App
+
+The scaffolder plugin comes in two packages, `@backstage/plugin-scaffolder` and
+`@backstage/plugin-scaffolder-backend`. Each has their own installation steps,
+outlined below.
+
+The Scaffolder plugin also depends on the Software Catalog. Instructions for how
+to set that up can be found [here](../software-catalog/installation.md).
+
+## Installing @backstage/plugin-scaffolder
+
+> **Note that if you used `npx @backstage/create-app`, the plugin may already be
+> present**
+
+The scaffolder frontend plugin should be installed in your `app` package, which
+is created as a part of `@backstage/create-app`. To install the package, run:
+
+```bash
+cd packages/app
+yarn add @backstage/plugin-scaffolder
+```
+
+Make sure the version of `@backstage/plugin-scaffolder` matches the version of
+other `@backstage` packages. You can update it in `packages/app/package.json` if
+it doesn't.
+
+### Adding the Plugin to your `packages/app`
+
+Add the following entry to the head of your `packages/app/src/plugins.ts`:
+
+```ts
+export { plugin as ScaffolderPlugin } from '@backstage/plugin-scaffolder';
+```
+
+Add the following to your `packages/app/src/apis.ts`:
+
+```ts
+import { scaffolderApiRef, ScaffolderApi } from '@backstage/plugin-scaffolder';
+
+// Inside the ApiRegistry builder function ...
+
+builder.add(
+ scaffolderApiRef,
+ new ScaffolderApi({
+ apiOrigin: backendUrl,
+ basePath: '/scaffolder/v1',
+ }),
+);
+```
+
+Where `backendUrl` is the `backend.baseUrl` from config, i.e.
+`const backendUrl = config.getString('backend.baseUrl')`.
+
+This is all that is needed for the frontend part of the Scaffolder plugin to
+work!
+
+## Installing @backstage/plugin-scaffolder-backend
+
+> **Note that if you used `npx @backstage/create-app`, the plugin may already be
+> present**
+
+The scaffolder backend should be installed in your `backend` package, which is
+created as a part of `@backstage/create-app`. To install the package, run:
+
+```bash
+cd packages/backend
+yarn add @backstage/plugin-scaffolder-backend
+```
+
+Make sure the version of `@backstage/plugin-scaffolder-backend` matches the
+version of other `@backstage` packages. You can update it in
+`packages/backend/package.json` if it doesn't.
+
+### Adding the Plugin to your `packages/backend`
+
+You'll need to add the plugin to the `backend`'s router. You can do this by
+creating a file called `packages/backend/src/plugins/scaffolder.ts` with the
+following contents to get you up and running quickly.
+
+```ts
+import {
+ CookieCutter,
+ createRouter,
+ FilePreparer,
+ GithubPreparer,
+ Preparers,
+ GithubPublisher,
+ CreateReactAppTemplater,
+ Templaters,
+} from '@backstage/plugin-scaffolder-backend';
+import { Octokit } from '@octokit/rest';
+import type { PluginEnvironment } from '../types';
+import Docker from 'dockerode';
+
+export default async function createPlugin({ logger }: PluginEnvironment) {
+ const cookiecutterTemplater = new CookieCutter();
+ const craTemplater = new CreateReactAppTemplater();
+ const templaters = new Templaters();
+
+ // Register default templaters
+ templaters.register('cookiecutter', cookiecutterTemplater);
+ templaters.register('cra', craTemplater);
+
+ const filePreparer = new FilePreparer();
+ const githubPreparer = new GithubPreparer();
+ const preparers = new Preparers();
+
+ // Register default preparers
+ preparers.register('file', filePreparer);
+ preparers.register('github', githubPreparer);
+
+ // Create GitHub client with your access token from environment variables
+ const githubClient = new Octokit({ auth: process.env.GITHUB_ACCESS_TOKEN });
+ const publisher = new GithubPublisher({ client: githubClient });
+
+ const dockerClient = new Docker();
+ return await createRouter({
+ preparers,
+ templaters,
+ publisher,
+ logger,
+ dockerClient,
+ });
+}
+```
+
+Once the `scaffolder.ts` router setup file is in place, add the router to
+`packages/backend/src/index.ts`:
+
+```ts
+import scaffolder from './plugins/scaffolder';
+
+const scaffolderEnv = useHotMemoize(module, () => createEnv('scaffolder'));
+
+const service = createServiceBuilder(module)
+ .loadConfig(configReader)
+ /** several different routers */
+ .addRouter('/scaffolder', await scaffolder(scaffolderEnv));
+```
+
+### Adding Templates
+
+At this point the scaffolder backend is installed in your backend package, but
+you will not have any templates available to use. These need to be added to the
+software catalog, as they are represented as entities of kind
+[Template](../software-catalog/descriptor-format.md#kind-template). You can find
+out more about adding templates [here](./adding-templates.md).
+
+To get up and running and try out some templates quickly, you can add some of
+our example templates through static configuration. Add the following to the
+`catalog.locations` section in your `app-config.yaml`:
+
+```yaml
+catalog:
+ locations:
+ # Backstage Example Templates
+ - type: github
+ target: https://github.com/spotify/backstage/blob/master/plugins/scaffolder-backend/sample-templates/react-ssr-template/template.yaml
+ - type: github
+ target: https://github.com/spotify/backstage/blob/master/plugins/scaffolder-backend/sample-templates/springboot-grpc-template/template.yaml
+ - type: github
+ target: https://github.com/spotify/backstage/blob/master/plugins/scaffolder-backend/sample-templates/create-react-app/template.yaml
+ - type: github
+ target: https://github.com/spotify/cookiecutter-golang/blob/master/template.yaml
+```
+
+### Runtime Dependencies
+
+For the scaffolder backend plugin to function, it needs a GitHub access token,
+and access to a running Docker daemon. You can create a GitHub access token
+[here](https://github.com/settings/tokens/new), select `repo` scope only. Full
+docs on creating private GitHub access tokens is available
+[here](https://docs.github.com/en/github/authenticating-to-github/creating-a-personal-access-token).
+Note that the need for private GitHub access tokens will be replaced with GitHub
+Apps integration further down the line.
+
+> **Right now it is only possible to scaffold repositories inside GitHub
+> organizations, and not under personal accounts.**
+
+The GitHub access token is passed along using the `GITHUB_ACCESS_TOKEN`
+environment variable.
+
+### Running the Backend
+
+Finally, make sure you have a local Docker daemon running, and start up the
+backend with the new configuration:
+
+```bash
+cd packages/backend
+GITHUB_ACCESS_TOKEN= yarn start
+```
+
+If you've also set up the frontend plugin, so you should be ready to go browse
+the templates at [localhost:3000/create](http://localhost:3000/create) now!
diff --git a/docs/features/techdocs/FAQ.md b/docs/features/techdocs/FAQ.md
index f872e63718..1a52a35cfb 100644
--- a/docs/features/techdocs/FAQ.md
+++ b/docs/features/techdocs/FAQ.md
@@ -1,8 +1,13 @@
-# TechDocs FAQ
+---
+id: faqs
+title: TechDocs FAQ
+sidebar_label: FAQ
+---
This page answers frequently asked questions about [TechDocs](README.md).
-_Got a question that you think others might be interested in knowing the answer to? Edit this file
+_Got a question that you think others might be interested in knowing the answer
+to? Edit this file
[here](https://github.com/spotify/backstage/edit/master/docs/features/techdocs/FAQ.md)._
## Technology
@@ -25,4 +30,3 @@ package is a MkDocs Plugin that works like a wrapper around multiple MkDocs
plugins (e.g.
[MkDocs Monorepo Plugin](https://github.com/spotify/mkdocs-monorepo-plugin)) as
well as a selection of Python Markdown extensions that TechDocs supports.
-
diff --git a/docs/features/techdocs/README.md b/docs/features/techdocs/README.md
index d054483482..8bdbd27d3c 100644
--- a/docs/features/techdocs/README.md
+++ b/docs/features/techdocs/README.md
@@ -1,4 +1,8 @@
-# TechDocs Documentation
+---
+id: techdocs-overview
+title: TechDocs Documentation
+sidebar_label: Overview
+---
## What is it?
@@ -16,9 +20,9 @@ Spotify’s developer experience offering with 2,400+ documentation sites and
- A clear end-to-end docs-like-code solution. (_Coming soon in V.1_)
- A tightly coupled feedback loop with the developer workflow. (_Coming soon in
- V.2_)
+ V.3_)
-- A developer ecosystem for creating extensions. (_Coming soon in V.2_)
+- A developer ecosystem for creating extensions. (_Coming soon in V.3_)
## Project roadmap
@@ -26,12 +30,15 @@ Spotify’s developer experience offering with 2,400+ documentation sites and
| ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------- |
| [TechDocs V.0 ✅][v0] | Read docs in Backstage - Enable anyone to get a reader experience working in Backstage. [See V.0 Use Cases.](./#techdocs-v0) |
| [TechDocs V.1 🚧][v1] | TechDocs end to end (alpha) - Alpha of TechDocs that you can use end to end - and contribute to. [See V.1 Use Cases.](./#techdocs-v1) |
-| [TechDocs V.2 🔮⌛][v2] | Widget Architecture - TechDocs widget architecture available, so the community can create their own customized features. |
+| [TechDocs V.2 🔮⌛][v2] | Platform stability and compatibility improvements. [See V.2 Use Cases.](./#techdocs-v2) |
+| TechDocs V.3 🔮⌛ | Widget Architecture - TechDocs widget architecture available, so the community can create their own customized features. |
[v0]: https://github.com/spotify/backstage/milestone/15
[v1]: https://github.com/spotify/backstage/milestone/16
[v2]: https://github.com/spotify/backstage/milestone/17
+
+
## Use Cases
#### TechDocs V.0
@@ -56,6 +63,14 @@ Spotify’s developer experience offering with 2,400+ documentation sites and
#### TechDocs V.2
+Platform stability and compatibility improvements
+
+- As a user I can define the metadata generated for my documentation.
+- As a user I will be able to browse metadata from within my documentation in
+ Backstage.
+
+#### TechDocs V.3
+
more to come...
## Structure
@@ -86,3 +101,7 @@ more to come...
https://github.com/spotify/backstage/blob/master/packages/techdocs-container
[techdocs/cli]:
https://github.com/spotify/backstage/blob/master/packages/techdocs-cli
+
+## TechDocs Big Picture
+
+
diff --git a/docs/features/techdocs/concepts.md b/docs/features/techdocs/concepts.md
index f06ed8b4c0..2fa84cebd6 100644
--- a/docs/features/techdocs/concepts.md
+++ b/docs/features/techdocs/concepts.md
@@ -1,6 +1,10 @@
-# Concepts
+---
+id: concepts
+title: Concepts
+---
-This page describes concepts that are introduced with Spotify's docs-like-code solution in Backstage.
+This page describes concepts that are introduced with Spotify's docs-like-code
+solution in Backstage.
### TechDocs Core Plugin
@@ -8,7 +12,7 @@ The TechDocs Core Plugin is a MkDocs plugin created as a wrapper around multiple
MkDocs plugins and Python Markdown extensions to standardize the configuration
of MkDocs used for TechDocs.
-[TechDocs Core](../../../packages/techdocs-container/techdocs-core/README.md)
+[TechDocs Core](https://github.com/spotify/backstage/blob/master/packages/techdocs-container/techdocs-core/README.md)
### TechDocs container
@@ -17,7 +21,7 @@ The TechDocs container is a Docker container available at
pages, including stylesheets and scripts from Python flavored Markdown, through
MkDocs.
-[TechDocs Container](../../../packages/techdocs-container/README.md)
+[TechDocs Container](https://github.com/spotify/backstage/blob/master/packages/techdocs-container/README.md)
### TechDocs publisher (coming soon)
@@ -28,7 +32,7 @@ documentation for publishing. Currently it mostly acts as a wrapper around the
TechDocs container and provides an easy-to-use interface for our docker
container.
-[TechDocs CLI](../../../packages/techdocs-cli/README.md)
+[TechDocs CLI](https://github.com/spotify/backstage/blob/master/packages/techdocs-cli/README.md)
### TechDocs Reader
@@ -38,9 +42,9 @@ sites with the Backstage UI.
The TechDocs Reader purpose is also to open up the opportunity to integrate
TechDocs widgets for a customized full-featured TechDocs experience.
-([coming soon V.2](https://github.com/spotify/backstage/milestone/17))
+([coming soon V.3](./README.md#project-roadmap))
-[TechDocs Reader](../../../plugins/techdocs/src/reader/README.md)
+[TechDocs Reader](https://github.com/spotify/backstage/blob/master/plugins/techdocs/src/reader/README.md)
### Transformers
@@ -49,4 +53,4 @@ Reader. The reason why transformers were introduced was to provide a way to
transform the HTML content on pre and post render (e.g. rewrite docs links or
modify css).
-[Transformers API docs](../../../plugins/techdocs/src/reader/transformers/README.md)
+[Transformers API docs](https://github.com/spotify/backstage/blob/master/plugins/techdocs/src/reader/README.md)
diff --git a/docs/features/techdocs/creating-and-publishing.md b/docs/features/techdocs/creating-and-publishing.md
index b38fb77b08..037c4be172 100644
--- a/docs/features/techdocs/creating-and-publishing.md
+++ b/docs/features/techdocs/creating-and-publishing.md
@@ -1,24 +1,48 @@
-# Creating and publishing your docs
+---
+id: creating-and-publishing
+title: Creating and publishing your docs
+sidebar_label: Creating and Publishing Documentation
+---
This section will guide you through:
-- Creating a basic setup for your documentation
-- Writing and previewing your documentation in a local Backstage environment
-- Creating a build ready for publication
-- Publishing your documentation and making your Backstage instance read your published docs.
+- [Create a basic documentation setup](#create-a-basic-documentation-setup)
+ - [Use the documentation template](#use-the-documentation-template)
+ - [Manually add documentation setup to already existing repository](#manually-add-documentation-setup-to-already-existing-repository)
+- [Writing and previewing your documentation](#writing-and-previewing-your-documentation)
## Prerequisities
-- [Docker](https://docs.docker.com/get-docker/)
-- Static file hosting
-- A working Backstage instance with TechDocs installed
- (see [TechDocs getting started](getting-started.md))
+- A working Backstage instance with TechDocs installed (see
+ [TechDocs getting started](getting-started.md))
## Create a basic documentation setup
-In your home directory (also known as `~`), create a directory that contains your documentation (for example, `hello-docs`). Inside this directory, create a file called `mkdocs.yml`. Below is a basic example of how it could look.
+### Use the documentation template
-The `~/hello-docs/mkdocs.yml` file should have the following content:
+Your working Backstage instance should by default have a documentation template
+added. If not, follow these
+[instructions](../software-templates/installation.md#adding-templates) to add
+the documentation template.
+
+
+
+Create an entity from the documentation template and you will get the needed
+setup for free.
+
+!!! warning Currently the Backstage Software Templates are limited to create repositories
+inside GitHub organizations. You also need to generate an personal access token
+and use as an environment variable. Read more about this
+[here](../software-templates/installation.md#runtime-dependencies).
+
+### Manually add documentation setup to already existing repository
+
+Prerequisities:
+
+- `catalog-info.yml` file registered to Backstage.
+
+Create a `mkdocs.yml` file in the root of the repository with the following
+content:
```yaml
site_name: 'example-docs'
@@ -30,7 +54,20 @@ plugins:
- techdocs-core
```
-The `~/hello-docs/docs/index.md` should have the following content:
+Update your `catalog-info.yaml` file in the root of the repository with the
+following content:
+
+```yaml
+metadata:
+ annotations:
+ backstage.io/techdocs-ref: dir:./
+```
+
+Create a `/docs` folder in the root of the project with at least a `index.md`
+file. _(If you add more markdown files, make sure to update the nav in the
+mkdocs.yml file to get a proper navigation for your documentation.)_
+
+The `docs/index.md` can for example have the following content:
```md
# example docs
@@ -38,6 +75,9 @@ The `~/hello-docs/docs/index.md` should have the following content:
This is a basic example of documentation.
```
+Commit your changes, open a pull request and merge. You will now get your
+updated documentation next time you run Backstage!
+
## Writing and previewing your documentation
Using the `techdocs-cli` you can preview your docs inside a local Backstage
@@ -47,77 +87,6 @@ want to write your documentation.
To do this you can run:
```bash
-cd ~/hello-docs/
+cd ~//
npx techdocs-cli serve
```
-
-## Build production ready documentation
-
-To get a build suitable for publication you can build your docs using the
-`spotify/techdocs` container:
-
-```bash
-cd ~/hello-docs/
-docker run -it -w /content -v $(pwd):/content spotify/techdocs build
-```
-
-You should now have a folder called `~/hello-docs/site/`.
-
-## Deploy to a file server
-
-In order to serve documentation to TechDocs, our Backstage plugin needs to download the HTML rendered from the previous step. This will likely exist on an external file server, or a storage solution such as Google Cloud Storage.
-
-When deploying documentation, it should be deployed on that file server/storage solution with the following convention: `{id}/{file}`. For example, if
-you want to upload the `getting-started/index.html` file for the `backstage`
-documentation site, we would upload it to our file server as
-`backstage/getting-started/index.html`.
-
-To explain further what this would look like for multiple documentation sites,
-take a look at this example file tree that would be represented on your file server:
-
-```md
-/backstage/index.html /backstage/getting-started/index.html
-/backstage/contributing/index.html /mkdocs/index.html
-/mkdocs/plugin-development/index.html
-/mkdocs/plugin-development/debugging/index.html
-```
-
-In this file tree, we have two documentation sites available: `backstage` and
-`mkdocs`. Each of them expose several pages. Let's say both of these are hosted
-on `http://example.com` as the server URL.
-
-When you configure the TechDocs plugin in Backstage to use `http://example.com`
-as the file server/storage solution, it will translate the following URLs to
-the file server:
-
-| Backstage URL | File Server URL |
-| --------------------------------------------------------- | ------------------------------------------------------- |
-| https://demo.backstage.io/docs/backstage/ | http://example.com/backstage/index.html |
-| https://demo.backstage.io/docs/mkdocs/plugin-development/ | http://example.com/mkdocs/plugin-development/index.html |
-
-Then deploying new sites is easy: simply copy over the `site/`
-folder produced in the [Create documentation](#build-production-ready-documentation) step above to the file server/storage solution under the ID of the documentation site. It will then become immediately available in Backstage under
-the same ID as you can see in the table above.
-
-So, if the URL to your file server is `http://example.com/`, your
-`~/hello-docs/site` folder containing the documentation should be accessible at
-`http://example.com/hello-docs/`.
-
-## Configure TechDocs to read from file server
-
-In order for Backstage to show your documentation, it needs to know where you
-uploaded it.
-
-Make sure you have Backstage set up using
-[TechDocs getting started](getting-started.md).
-
-To point Backstage to your docs storage, add or change the following lines in
-your Backstage `app-config.yaml`:
-
-```yaml
-techdocs:
- storageUrl: http://example.com
-```
-
-You can now start Backstage using `yarn start` and open up your browser at
-`http://localhost:3000/docs/hello-docs` to view your docs.
diff --git a/docs/features/techdocs/getting-started.md b/docs/features/techdocs/getting-started.md
index 90dcd423fa..414b3baae8 100644
--- a/docs/features/techdocs/getting-started.md
+++ b/docs/features/techdocs/getting-started.md
@@ -1,17 +1,10 @@
-# Getting Started
+---
+id: getting-started
+title: Getting Started
+---
-> TechDocs is not yet feature complete - currently you can't set up a complete
-> end-to-end working TechDocs plugin without customizing the plugin itself.
-
-> What you can expect from TechDocs V.0 is a demonstration of how to integrate docs into
-> Backstage. TechDocs can create docs using
-> [mkdocs](https://www.mkdocs.org/), as well as read published docs. If you
-> publish generated docs and pass in a `storageUrl` in your `app-config.yaml`,
-> you can view them in Backstage by going to
-> `http://localhost:3000/docs/`.
-
-TechDocs functions as a plugin to
-Backstage, so you will need to use Backstage to use TechDocs.
+TechDocs functions as a plugin to Backstage, so you will need to use Backstage
+to use TechDocs.
## What is Backstage?
@@ -38,17 +31,20 @@ To create a new Backstage application for TechDocs, run the following command:
npx @backstage/cli create-app
```
-You will then be prompted to enter a name for your application. Once that's done, a new Backstage application will be created in a new folder. For
-example, if you choose the name `hello-world`, a new `hello-world` folder is created containing your new Backstage application.
+You will then be prompted to enter a name for your application. Once that's
+done, a new Backstage application will be created in a new folder. For example,
+if you choose the name `hello-world`, a new `hello-world` folder is created
+containing your new Backstage application.
## Installing TechDocs
-TechDocs is not provided with the Backstage application by default, so you will now need to set up TechDocs manually. It should take less
-than a minute.
+TechDocs is provided with the Backstage application by default. If you want to
+set up TechDocs manually, keep follow the instructions below.
### Adding the package
-The first step is to add the TechDocs plugin to your Backstage application. Navigate to your new Backstage application folder:
+The first step is to add the TechDocs plugin to your Backstage application.
+Navigate to your new Backstage application folder:
```bash
cd hello-world/
@@ -61,7 +57,7 @@ cd packages/app
yarn add @backstage/plugin-techdocs
```
-After a short while, the TechDocs plugin should be successfully installed.
+After a short while, the TechDocs plugin should be successfully installed.
Next, you need to set up some basic configuration. Enter the following command:
@@ -78,18 +74,29 @@ export { plugin as TechDocs } from '@backstage/plugin-techdocs';
### Setting the configuration
TechDocs allows for configuration of the docs storage URL through your
-`app-config` file. The URL provided here is for demo docs to use for testing purposes.
+`app-config` file.
-To use the demo docs, add the following lines to `app-config.yaml`:
+The default storage URL:
```yaml
techdocs:
- storageUrl: https://techdocs-mock-sites.storage.googleapis.com
+ storageUrl: http://localhost:7000/techdocs/static/docs
```
+If you want to configure this to point to another storage URL, change the value
+of `storageUrl`.
+
## Run Backstage locally
-Change folder to your Backstage application root and run the following command:
+Change folder to `/packages/backend` and run the
+following command:
+
+```bash
+yarn start
+```
+
+Open a new command line window. Change directory to your Backstage application
+root and run the following command:
```bash
yarn start
@@ -99,5 +106,5 @@ Open your browser at [http://localhost:3000/docs/](http://localhost:3000/docs/).
## Additional reading
- * [Creating and publishing your docs](creating-and-publishing.md)
- * [Back to README](README.md)
+- [Creating and publishing your docs](creating-and-publishing.md)
+- [Back to README](README.md)
diff --git a/docs/getting-started/app-custom-theme.md b/docs/getting-started/app-custom-theme.md
index 8c8b150171..e555c6b52d 100644
--- a/docs/getting-started/app-custom-theme.md
+++ b/docs/getting-started/app-custom-theme.md
@@ -1,4 +1,7 @@
-# Custom App Themes
+---
+id: app-custom-theme
+title: Customize the look-and-feel of your App
+---
Backstage ships with a default theme with a light and dark mode variant. The
themes are provided as a part of the
diff --git a/docs/getting-started/configure-app-with-plugins.md b/docs/getting-started/configure-app-with-plugins.md
index e69de29bb2..a0d2c27f89 100644
--- a/docs/getting-started/configure-app-with-plugins.md
+++ b/docs/getting-started/configure-app-with-plugins.md
@@ -0,0 +1,6 @@
+---
+id: configure-app-with-plugins
+title: Configuring App with plugins
+---
+
+Coming soon!
diff --git a/docs/getting-started/create-an-app.md b/docs/getting-started/create-an-app.md
index ab5e71ad60..fe22935002 100644
--- a/docs/getting-started/create-an-app.md
+++ b/docs/getting-started/create-an-app.md
@@ -1,4 +1,7 @@
-# Backstage App
+---
+id: create-an-app
+title: Create an App
+---
To get set up quickly with your own Backstage project you can create a Backstage
App.
@@ -22,7 +25,7 @@ This will create a new Backstage App inside the current folder. The name of the
app-folder is the name that was provided when prompted.
-
+
Inside that directory, it will generate all the files and folder structure
diff --git a/docs/getting-started/deployment-k8s.md b/docs/getting-started/deployment-k8s.md
index e69de29bb2..2a184779e2 100644
--- a/docs/getting-started/deployment-k8s.md
+++ b/docs/getting-started/deployment-k8s.md
@@ -0,0 +1,6 @@
+---
+id: deployment-k8s
+title: Kubernetes
+---
+
+Coming soon!
diff --git a/docs/getting-started/deployment-other.md b/docs/getting-started/deployment-other.md
index 26c70acac4..3b7796f8fe 100644
--- a/docs/getting-started/deployment-other.md
+++ b/docs/getting-started/deployment-other.md
@@ -1,4 +1,7 @@
-# Deployment (Other)
+---
+id: deployment-other
+title: Other
+---
## Deploying Locally
diff --git a/docs/getting-started/development-environment.md b/docs/getting-started/development-environment.md
index e10ee4b24a..421ce6d2c5 100644
--- a/docs/getting-started/development-environment.md
+++ b/docs/getting-started/development-environment.md
@@ -1,4 +1,7 @@
-# Development Environment
+---
+id: development-environment
+title: Development Environment
+---
This section describes how to get set up for doing development on the Backstage
repository.
@@ -82,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/getting-started/index.md b/docs/getting-started/index.md
index 2770b7a154..abe7776371 100644
--- a/docs/getting-started/index.md
+++ b/docs/getting-started/index.md
@@ -1,10 +1,24 @@
-# Getting started with Backstage
+---
+id: index
+title: Running Backstage Locally
+---
-## Running Backstage Locally
+First make sure you are using NodeJS with an Active LTS Release, currently v12.
+This is made easy with a version manager such as nvm which allows for version switching.
+
+```bash
+# Checking your version
+node --version
+> v14.7.0
+
+# Adding a second node version
+nvm install 12
+> Downloading and installing node v12.18.3...
+> Now using node v12.18.3 (npm v6.14.6)
+```
To get up and running with a local Backstage to evaluate it, let's clone it off
-of GitHub and run an initial build. First make sure that you have at least node
-version 12 installed locally.
+of GitHub and run an initial build.
```bash
# Start from your local development folder
diff --git a/docs/getting-started/installation.md b/docs/getting-started/installation.md
index e69de29bb2..a4f91b6e95 100644
--- a/docs/getting-started/installation.md
+++ b/docs/getting-started/installation.md
@@ -0,0 +1,6 @@
+---
+id: installation
+title: Installation
+---
+
+Coming soon!
diff --git a/docs/overview/adopting.md b/docs/overview/adopting.md
new file mode 100644
index 0000000000..893eac6398
--- /dev/null
+++ b/docs/overview/adopting.md
@@ -0,0 +1,160 @@
+---
+id: adopting
+title: Strategies for adopting
+---
+
+This document outlines some general best practices that have been key to
+Backstage's success inside Spotify. Every organization is different and some of
+these learnings will therefore not be applicable for your company. We are hoping
+that this can become a living document, and strongly encourage you to contribute
+back whatever learnings you gather while adopting Backstage inside your company.
+
+## Organizational setup
+
+The true value of Backstage is unlocked when it becomes _THE_ developer portal
+at your company. As such it is important to recognize that you will need a
+central team that owns your Backstage deployment and treats it like a product.
+
+This team will have **four** primary objectives:
+
+1. Maintain and operate your deployment of Backstage. This includes customer
+ support, infrastructure, CI/CD and, as your Backstage product grows, on-call
+ support.
+
+2. Drive adoption of customers (developers at your company).
+
+3. Work with senior tech leadership and architects to ensure your organizations
+ best practices for software development are encoded into a set of
+ [Software Templates](../features/software-templates/index.md).
+
+4. Evangelize Backstage as a central platform towards other
+ infrastructure/platform teams.
+
+## Internal evangelization
+
+The last objective deserves more attention, since it is the least obvious, but
+also the most critical to successfully creating a consolidated platform. When
+done right, Backstage acts as a "platform of platforms" or marketplace between
+infra/platform teams and end-users:
+
+
+
+While anyone at your company can contribute to the platform, the vast majority
+of work will be done by teams that also has internal engineers as their
+customers. The central team should treat these _contributing teams_ as customers
+of the platform as well.
+
+These teams should be able to autonomously deliver value directly to their
+customers. This is done primarily by building [plugins](../plugins/index.md).
+Contributing teams should themselves treat their plugins as, or part of, the
+products they maintain.
+
+> Case study: Inside Spotify we have a team that owns our CI platform. They
+> don't only maintain the pipelines and build servers, but also expose their
+> product in Backstage through a plugin. Since they also
+> [maintain their own API](../plugins/call-existing-api.md), they can improve
+> their product by iterating on API and UI in lockstep. Because the plugin
+> follows our [platform design guidelines](../dls/design.md) their customers get
+> a CI experience that is consistent with other tools on the platform (and users
+> don't have to become experts in Jenkins).
+
+### Tactics
+
+Example of tactics we have used to evangelize Backstage internally:
+
+- Arrange "Lunch & Learns" and seminars. Frequently offer teams interested in
+ Backstage development to come to a seminar where you show, for example, how to
+ build a plugin from scratch.
+
+- Embedding. As contributing teams start development of their first plugin it is
+ often very appreciated to have one person from the central team come over and
+ "embed" for a Sprint or two.
+
+- Hack days. Backstage-focused Hackathons or hack days is a fun way to get
+ people into plugin development.
+
+- Show & tell meetings. In order to build an internal community around Backstage
+ we have quarterly meetings where anyone working on Backstage is invited to
+ present their work. This is a not only a great way to get early feedback, but
+ also helps coordination between teams that are building overlapping
+ experiences.
+
+- Provide metrics. Add instrumentation to your Backstage deployment and make
+ metrics available to contributing teams. At Spotify we have even gone so far
+ as sending out weekly digest email showing how usage metrics have changed for
+ individual plugins.
+
+- Pro-actively identify new plugins. Reach out to teams that own internal UIs or
+ platforms that you think would make sense to consolidate into Backstage.
+
+## KPIs and metrics
+
+These are some of the metrics that you can use to verify if Backstage has a
+successful impact on your software development process:
+
+- **Onboarding time** Time until new engineers are productive. At Spotify we
+ measure this as the time until the employee has merged their 10th PR (this
+ metric was down 55% two years after deploying Backstage). Even though you may
+ not be onboarding engineers at a rapid pace, this metric is a great proxy for
+ the overall complexity of your ecosystem. Reducing it will therefore benefit
+ your whole engineering organization, not just new joiners.
+
+- **Number of merges per developer/day** Less time spent jumping between
+ different tools and looking for information means more time to focus on
+ shipping code. A second level of bottlenecks can be identified if you
+ categorize contributions by domain (services, web, data, etc).
+
+- **Deploys to production** Cousin to the metric above: How many times does an
+ engineer push changes into production.
+
+- **MTTR** With clear ownership of all the pieces in your micro services
+ ecosystem and all tools integrated into one place, Backstage makes it quicker
+ for teams to find the root cause of failures, and fix them.
+
+- **Context switching** Reducing context switching can help engineers stay in
+ the "zone". We measure the number of different tools an engineer have to
+ interact with in order to get a certain job done (e.g. push a change, follow
+ it into production and validate it did not break anything).
+
+- **T-shapedness** A
+ [T-shaped](https://medium.com/@jchyip/why-t-shaped-people-e8706198e437)
+ engineer is someone that is able to contribute to different domains of
+ engineering. Teams with T-shaped people have fewer bottlenecks and can
+ therefore deliver more consistently. Backstage makes it easier to be T-shaped
+ since tools and infrastructure is consistent between domains, and information
+ is available centrally.
+
+- **eNPS** Surveys asking about how productive people feel, how easy it is to
+ find information and overall satisfaction with internal tools.
+
+- **Fragmentation** _(Experimental)_ Backstage
+ [Software Templates](../features/software-templates/index.md) helps drive
+ standardization in your software ecosystem. By measuring the variance in
+ technology between different software components it is possible to get a sense
+ of the overall fragmentation in your ecosystem. Examples could include:
+ framework versions, languages, deployment methods and various code quality
+ measurements.
+
+Additionally, these proxy metrics can be used to validate the success of
+Backstage as _the_ platform:
+
+- Nr of teams that have contributed at least one plugin (currently 63 inside
+ Spotify)
+
+- Nr of total plugins (currently 135 inside Spotify)
+
+- % of contributions coming from outside the central Backstage team (currently
+ 85% inside Spotify)
+
+- Traditional metrics such as visits (MAU, DAU, etc) and page views. Currently
+ ~50% of all Spotifiers use Backstage on a monthly basis, even though the
+ percentage of engineers is below 50%. Most engineers actually use Backstage on
+ a daily basis.
+
+Again, any feedback is appreciated. Please use the Edit button at the top of the
+page to make a suggestion.
+
+_**Note!** It might be tempting to try to optimize Backstage usage and
+"engagement". Even though you want to consolidate all your tooling and technical
+documentation in Backstage, it is important to remember that time spent in
+Backstage is time not spent writing code_ 🙃
diff --git a/docs/overview/architecture-overview.md b/docs/overview/architecture-overview.md
index 9093e98e2e..9f1d6d3291 100644
--- a/docs/overview/architecture-overview.md
+++ b/docs/overview/architecture-overview.md
@@ -1,4 +1,9 @@
-# Typical Backstage architecture
+---
+id: architecture-overview
+title: Architecture overview
+---
+
+## Overview
The following diagram shows how Backstage might look when deployed inside a
company which uses the Tech Radar plugin, the Lighthouse plugin, the Circle CI
@@ -14,27 +19,27 @@ Running this architecture in a real environment typically involves
containerising the components. Various commands are provided for accomplishing
this.
-
+
-# The UI
+## The UI
The UI is a thin, client-side wrapper around a set of plugins. It provides some
core UI components and libraries for shared activities such as config
management. [[live demo](https://backstage-demo.roadie.io/)]
-
+
Each plugin typically makes itself available in the UI on a dedicated URL. For
example, the lighthouse plugin is registered with the UI on `/lighthouse`.
[[live demo](https://backstage-demo.roadie.io/lighthouse)]
-
+
The Circle CI plugin is available on `/circleci`.
-
+
-# Plugins and plugin backends
+## Plugins and plugin backends
Each plugin is a client side application which mounts itself on the UI. Plugins
are written in TypeScript or JavaScript. They each live in their own directory
@@ -42,7 +47,7 @@ in `backstage/plugins`. For example, the source code for the lighthouse plugin
is available at
[backstage/plugins/lighthouse](https://github.com/spotify/backstage/tree/master/plugins/lighthouse).
-## Installing plugins
+### Installing plugins
Plugins are typically loaded by the UI in your Backstage applications
`plugins.ts` file. For example,
@@ -74,7 +79,7 @@ export default builder.build() as ApiHolder;
As of this moment, there is no config based install procedure for plugins. Some
code changes are required.
-## Plugin architecture
+### Plugin architecture
Architecturally, plugins can take three forms:
@@ -82,21 +87,21 @@ Architecturally, plugins can take three forms:
2. Service backed
3. Third-party backed
-### Standalone plugins
+#### Standalone plugins
Standalone plugins run entirely in the browser.
[The tech radar plugin](https://backstage-demo.roadie.io/tech-radar), for
example, simply renders hard-coded information. It doesn't make any API requests
to other services.
-
+
The architecture of the Tech Radar installed into a Backstage app is very
simple.
-
+
-### Service backed plugins
+#### Service backed plugins
Service backed plugins make API requests to a service which is within the
purview of the organisation running Backstage.
@@ -109,7 +114,7 @@ results in a PostgreSQL database.
Its architecture looks like this:
-
+
The service catalog in Backstage is another example of a service backed plugin.
It retrieves a list of services, or "entities", from the Backstage Backend
@@ -131,9 +136,9 @@ Cross Origin Resource Sharing policies which prevent a browser page served at
[https://example.com](https://example.com) from serving resources hosted at
https://circleci.com.
-
+
-# Databases
+## Databases
As we have seen, both the lighthouse-audit-service and catalog-backend require a
database to work with.
@@ -150,7 +155,7 @@ GitHub issues.
[Update migrations to support postgres by dariddler · Pull Request #1527 · spotify/backstage](https://github.com/spotify/backstage/pull/1527#discussion_r450374145)
-# Containerization
+## Containerization
The example Backstage architecture shown above would Dockerize into three
separate docker images.
@@ -159,7 +164,7 @@ separate docker images.
2. The backend container
3. The lighthouse audit service container
-
+
The frontend container can be built with a provided command.
diff --git a/docs/overview/architecture-terminology.md b/docs/overview/architecture-terminology.md
index 6a9d773142..aee581f927 100644
--- a/docs/overview/architecture-terminology.md
+++ b/docs/overview/architecture-terminology.md
@@ -1,4 +1,7 @@
-# Architecture and Terminology
+---
+id: architecture-terminology
+title: Architecture terminology
+---
Backstage is constructed out of three parts. We separate Backstage in this way
because we see three groups of contributors that work with Backstage in three
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/overview/roadmap.md b/docs/overview/roadmap.md
index 36ff658596..5a06f4544f 100644
--- a/docs/overview/roadmap.md
+++ b/docs/overview/roadmap.md
@@ -1,36 +1,134 @@
-# Project roadmap
+---
+id: roadmap
+title: Project roadmap
+---
-We created Backstage about 4 years ago. While our internal version of Backstage
-has had the benefit of time to mature and evolve, the first iteration of our
-open source version is still nascent. We are envisioning three phases of the
-project and we have already begun work on various aspects of these phases:
+## Current status
+
+> Backstage is currently under rapid development. This means that you can expect
+> APIs and features to evolve. It is also recommended that teams who adopt
+> Backstage today upgrade their installation as new
+> [releases](https://github.com/spotify/backstage/releases) become available, as
+> Backwards compatibility is not yet guaranteed.
+
+## Phases
+
+We have divided the project into three high-level _phases_:
- 🐣 **Phase 1:** Extensible frontend platform (Done ✅) - 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](http://storybook.backstage.io) help ensure a
+ [UX patterns and components](https://backstage.io/storybook) help ensure a
consistent experience between tools.
- 🐢 **Phase 2:** Service Catalog
([alpha released](https://backstage.io/blog/2020/06/22/backstage-service-catalog-alpha)) -
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.
- Developers can get a uniform overview of all their software and related
- resources, regardless of how and where they are running, as well as an easy
- way to onboard and manage those resources.
- 🐇 **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.
-Check out our [Milestones](https://github.com/spotify/backstage/milestones) and
-open [RFCs](https://github.com/spotify/backstage/labels/rfc) how they relate to
-the three Phases outlined above.
+## Detailed roadmap
-Our vision for Backstage is for it to become the trusted standard toolbox (read:
-UX 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 me directly:
+If you have questions about the roadmap or want to provide feedback, we would
+love to hear from you! Please create an
+[Issue](https://github.com/spotify/backstage/issues/new/choose), ping us on
+[Discord](https://discord.gg/EBHEGzX) or reach out directly at
[alund@spotify.com](mailto:alund@spotify.com).
+
+Want to help out? Awesome ❤️ Head over to
+[CONTRIBUTING](https://github.com/spotify/backstage/blob/master/CONTRIBUTING.md)
+guidelines to get started.
+
+### Ongoing work 🚧
+
+- **[Plugins for managing micro services end-2-end](https://github.com/spotify/backstage/milestone/14)** -
+ Out of the box Backstage will ship with a set of plugins (Overview, CI, API
+ and Docs) that will demonstrate how a user can manage a micro service and
+ follow a change all the way out in production. Completing this work will make
+ it much easier to see how a plugin can be built that integrates with the
+ Backstage Service Catalog.
+
+- **Backstage Design System** - By providing design guidelines for common plugin
+ layouts together, rich set of reusable UI components
+ ([Storybook](https://backstage.io/storybook)) and Figma design resources. The
+ Design System will make it easy to design and build plugins that are
+ consistent across the platform -- supporting both developers and designers.
+
+- **[TechDocs v1](https://github.com/spotify/backstage/milestone/16)** - Our
+ docs-like-code feature TechDocs working end to end.
+
+- **[Initial GraphQL API](https://github.com/spotify/backstage/milestone/13)** -
+ A GraphQL API will open up the rich metadata provided by Backstage in a single
+ query. Plugins can easily query this API as well as extend the model where
+ needed.
+
+- **Production deployments** - Provide instructions and default configurations
+ (e.g. through Helm charts) for easy deployments of Backstage and its
+ subsystems on Kubernetes.
+
+- **Cloud Cost Insights plugin (from Spotify)** - Spotify teams are fully
+ responsible for their own software, including the cost of the cloud resources
+ they use. By making our internal cost insights plugin available as open source
+ you will also be able to treat cost as an engineering problem, and make it
+ easy for your engineers to see their spend and where there's opportunity to
+ reduce waste.
+
+- Further improvements to platform documentation
+
+### Plugins
+
+Building and maintaining [plugins](https://backstage.io/plugins) is the work of
+the entire Backstage community.
+
+A list of plugins that are in development is
+[available here](https://github.com/spotify/backstage/issues?q=is%3Aissue+is%3Aopen+label%3Aplugin+sort%3Areactions-%2B1-desc).
+We strongly recommend to upvote 👍 plugins you are interested in. This helps us
+and the community prioritize what plugins to build.
+
+Are you missing a plugin for your favorite tool? Please
+[suggest a new one](https://github.com/spotify/backstage/issues/new?labels=plugin&template=plugin_template.md&title=%5BPlugin%5D+THE+PLUGIN+NAME).
+Chances are that someone will jump in and help build it.
+
+### Future work 🔮
+
+- **[Backstage platform is stable](https://github.com/spotify/backstage/milestone/19)** -
+ The platform APIs and features are stable and can be depended on for
+ production use. After this plugins will require little to no maintenance.
+
+- **Deploy a product demo at `demo.backstage.io`** - Deploy a typical Backstage
+ deployment available publicly so that people can click around and get a feel
+ for the product without having to install anything.
+
+- **[Global search](https://github.com/spotify/backstage/issues/1499)** - Extend
+ the basic search available in the Backstage Service Catalog with a global
+ search experience. Long term this search solution should be extensible, making
+ it possible for you add custom search results.
+
+- **[[TechDocs V.2] Stabilization release](https://github.com/spotify/backstage/milestone/17)** -
+ Platform stability and compatibility improvements.
+
+- **Additional auth providers** - Backstage should work for most (all!) auth
+ solutions. Since Backstage can be used by companies regardless of what cloud
+ (or on prem) you are using we are especially keen to get auth support for
+ [AWS](https://github.com/spotify/backstage/issues/290),
+ [Azure](https://github.com/spotify/backstage/issues/348) and others.
+
+### Completed milestones ✅
+
+- [Plugin marketplace](https://backstage.io/plugins)
+- [Improved and move documentation to backstage.io](https://backstage.io/docs/overview/what-is-backstage)
+- [Backstage Service Catalog (alpha)](https://backstage.io/blog/2020/06/22/backstage-service-catalog-alpha)
+- [Backstage Software Templates (alpha)](https://backstage.io/blog/2020/08/05/announcing-backstage-software-templates)
+- [Make it possible to add custom auth providers](https://backstage.io/blog/2020/07/01/how-to-enable-authentication-in-backstage-using-passport)
+- [TechDocs v0](https://github.com/spotify/backstage/milestone/15)
+- CI plugins: CircleCI, Jenkins, GitHub Actions and TravisCI
+- [Service API documentation](https://github.com/spotify/backstage/pull/1737)
+- Backstage Service Catalog can read from: GitHub, GitLab,
+ [Bitbucket](https://github.com/spotify/backstage/pull/1938)
+- Support auth providers: Google, Okta, GitHub, GitLab,
+ [auth0](https://github.com/spotify/backstage/pull/1611),
+ [AWS](https://github.com/spotify/backstage/pull/1990)
diff --git a/docs/overview/support.md b/docs/overview/support.md
index 7c7390fb69..9e4e9eca15 100644
--- a/docs/overview/support.md
+++ b/docs/overview/support.md
@@ -1,4 +1,7 @@
-# Support and community
+---
+id: support
+title: Support and community
+---
- [Discord chatroom](https://discord.gg/MUpMjP2) - Get support or discuss the
project
diff --git a/docs/overview/vision.md b/docs/overview/vision.md
new file mode 100644
index 0000000000..2ab7cdc6f4
--- /dev/null
+++ b/docs/overview/vision.md
@@ -0,0 +1,21 @@
+---
+id: vision
+title: Vision
+---
+
+Our goal is to provide engineers with the best developer experience in the
+world.
+
+A fantastic developer experience leads to happy, creative and productive
+engineers. Our belief is that engineers should not have to be experts in various
+infrastructure tools to be productive. Infrastructure should be abstracted away
+so that you can return to building and scaling, quickly and safely.
+
+
+
+We are working on making Backstage the trusted standard toolbox (read: UX 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 me directly:
+[alund@spotify.com](mailto:alund@spotify.com).
diff --git a/docs/overview/what-is-backstage.md b/docs/overview/what-is-backstage.md
index eb8ce1f906..96e89618a8 100644
--- a/docs/overview/what-is-backstage.md
+++ b/docs/overview/what-is-backstage.md
@@ -1,44 +1,53 @@
-# [Backstage](https://backstage.io)
+---
+id: what-is-backstage
+title: What is Backstage?
+---
-
-
-## What is Backstage?
+
[Backstage](https://backstage.io/) is an open platform for building developer
-portals. It’s based on the developer portal we’ve been using internally at
-Spotify for over four years. Backstage can be as simple as a services catalog or
-as powerful as the UX layer for your entire tech infrastructure.
+portals. Powered by a centralized service catalog, Backstage restores order to
+your microservices and infrastructure. So your product teams can ship
+high-quality code quickly — without compromising autonomy.
-For more information go to [backstage.io](https://backstage.io) or join our
-[Discord chatroom](https://discord.gg/EBHEGzX).
+Backstage unifies all your infrastructure tooling, services, and documentation
+to create a streamlined development environment from end to end.
-### Features
+Out of the box, Backstage includes:
-- Create and manage all of your organization’s software and microservices in one
- place.
-- Services catalog keeps track of all software and its ownership.
-- Visualizations provide information about your backend services and tooling,
- and help you monitor them.
-- A unified method for managing microservices offers both visibility and
- control.
-- Preset templates allow engineers to quickly create microservices in a
- standardized way
- ([coming soon](https://github.com/spotify/backstage/milestone/11)).
-- Centralized, full-featured technical documentation with integrated tooling
- that makes it easy for developers to set up, publish, and maintain alongside
- their code ([coming soon](https://github.com/spotify/backstage/milestone/15)).
+- [Backstage Service Catalog](../features/software-catalog/index.md) for
+ managing all your software (microservices, libraries, data pipelines,
+ websites, ML models, etc.)
+
+- [Backstage Software Templates](../features/software-templates/index.md) for
+ quickly spinning up new projects and standardizing your tooling with your
+ organization’s best practices
+
+- [Backstage TechDocs](../features/techdocs/README.md) for making it easy to
+ create, maintain, find, and use technical documentation, using a "docs like
+ code" approach
+
+- Plus, a growing ecosystem of
+ [open source plugins](https://github.com/spotify/backstage/tree/master/plugins)
+ that further expand Backstage’s customizability and functionality
### Benefits
- For _engineering managers_, it allows you to maintain standards and best
practices across the organization, and can help you manage your whole tech
ecosystem, from migrations to test certification.
+
- For _end users_ (developers), it makes it fast and simple to build software
components in a standardized way, and it provides a central place to manage
all projects and documentation.
+
- For _platform engineers_, it enables extensibility and scalability by letting
you easily integrate new tools and services (via plugins), as well as
extending the functionality of existing ones.
+
- For _everyone_, it’s a single, consistent experience that ties all your
infrastructure tooling, resources, standards, owners, contributors, and
administrators together in one place.
+
+If you have questions or want support, please join our
+[Discord chatroom](https://discord.gg/EBHEGzX).
diff --git a/docs/plugins/add-to-marketplace.md b/docs/plugins/add-to-marketplace.md
new file mode 100644
index 0000000000..d85807a226
--- /dev/null
+++ b/docs/plugins/add-to-marketplace.md
@@ -0,0 +1,25 @@
+---
+id: add-to-marketplace
+title: Add to Marketplace
+---
+
+## Adding a Plugin to the Marketplace
+
+To add a new plugin to the [plugin marketplace](https://backstage.io/plugins)
+create a file in
+[`microsite/data/plugins`](https://github.com/spotify/backstage/tree/master/microsite/data/plugins)
+with your plugin's information. Example:
+
+```yaml
+---
+title: Your Plugin
+author: Your Name
+authorUrl: # A link to information about the author E.g. Company url, github user profile, etc
+category: Monitoring # A single category e.g. CI, Machine Learning, Services, Monitoring
+description: A brief description of the plugin. # Max 170 characters
+documentation: # A link to your documentation E.g. Your github README
+iconUrl: # Used as the src attribute for your logo.
+# You can provide an external url or add your logo under static/img and provide a path
+# relative to static/ e.g. img/my-logo.png
+npmPackageName: # Your npm package name E.g. '@backstage/plugin-' quotes are required
+```
diff --git a/docs/plugins/backend-plugin.md b/docs/plugins/backend-plugin.md
index e69de29bb2..986af66c20 100644
--- a/docs/plugins/backend-plugin.md
+++ b/docs/plugins/backend-plugin.md
@@ -0,0 +1,6 @@
+---
+id: backend-plugin
+title: Backend plugin
+---
+
+## TODO
diff --git a/docs/plugins/call-existing-api.md b/docs/plugins/call-existing-api.md
index e69de29bb2..9658176224 100644
--- a/docs/plugins/call-existing-api.md
+++ b/docs/plugins/call-existing-api.md
@@ -0,0 +1,172 @@
+---
+id: call-existing-api
+title: Call Existing API
+---
+
+This article describes the various options that Backstage frontend plugins have,
+in communicating with service APIs that already exist. Each section below
+describes a possible choice, and the circumstances under which it fits.
+
+In these examples, we will be ultimately requesting data from the fictional
+FrobsCo API.
+
+## Issuing Requests Directly
+
+The most basic choice available is to issue requests directly from the plugin
+frontend code to the FrobsCo API, using for example `fetch` or a support library
+such as `axios`.
+
+Example:
+
+```ts
+// Inside your component
+fetch('https://api.frobsco.com/v1/list')
+ .then(response => response.json())
+ .then(payload => setFrobs(payload as Frob[]));
+```
+
+Internally at Spotify, this has not been a very common choice. Third party APIs
+are sometimes accessed like this. Just a handful of internal APIs also went
+through the trouble of exposing themselves in a way that is useful directly from
+a browser, but even then, often not from the public internet but only supporting
+users that are already on the company VPN.
+
+This can be used when:
+
+- The API already does/exposes exactly what you need.
+- The request/response patterns of the API match real world usage needs in
+ Backstage frontend plugins. For example, if the end use case is to show a
+ small summary in Backstage, but the only available API endpoint gives a 30
+ megabyte blob with large amounts of redundant information, it would hurt the
+ end user experience. Particularly on mobile. The same goes for cases where you
+ want to show many individual pieces of information: if a common use case is to
+ show large tables where one API request per cell is necessary, the browser
+ will quickly become swamped and you may want to consider performing
+ aggregation elsewhere instead.
+- The API can maintain interactive request/response times at your required peak
+ request rates. The end user experience will be degraded if they spend a lot of
+ time waiting for the data to arrive.
+- The API endpoint is highly available. The browser does not have builtin
+ facilities for load balancing, service discovery, retries, health checks,
+ circuit breaking and similar. If the endpoint is occasionally down even for
+ short periods of time (e.g. during deploys), end users will quickly notice.
+- The API is exposed over HTTPS (not just HTTP), and properly handles
+ [CORS](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS). These are
+ requirements that the user's browser will impose for security reasons, and the
+ requests will be rejected otherwise.
+- The API endpoint is easily reachable, in terms of network conditions, by end
+ users. This may be particularly relevant if your end users are outside of your
+ perimeter.
+- The requests do not require secrets to be passed. This limitation does not
+ apply to OAuth tokens, which the frontend can negotiate and make proper use
+ of.
+
+## Using The Backstage Proxy
+
+Backstage has an optional proxy plugin for the backend, that can be used to
+easily add proxy routes to downstream APIs.
+
+Example:
+
+```yaml
+# In app-config.yaml
+proxy:
+ '/frobs': http://api.frobsco.com/v1
+```
+
+```ts
+// Inside your component
+const backendUrl = config.getString('backend.baseUrl');
+fetch(`${backendUrl}/proxy/frobs/list`)
+ .then(response => response.json())
+ .then(payload => setFrobs(payload as Frob[]));
+```
+
+The proxy is powered by the `http-proxy-middleware` package. See
+[Proxying](proxying.md) for a full description of its configuration options.
+
+Internally at Spotify, the proxy option has been the overwhelmingly most popular
+choice for plugin makers. Since we have DNS based service discovery in place and
+a microservices framework that made it trivial to expose plain HTTP, it has been
+a matter of just adding a few lines of Backstage config to get the benefit of
+being easily and robustly reachable from users' web browsers as well.
+
+This may be used instead of direct requests, when:
+
+- You need to perform HTTPS termination and/or CORS handling, because the API
+ itself is not supplying those.
+- You need to inject a simple static secret into the requests, e.g. an
+ Authorization header that gets added to the request headers.
+- You want to make use of other proxy facilities, such as retries, failover,
+ health checks, routing, request logging, rewrites, etc.
+- You already have the Backstage backend itself exposed through your perimeter
+ and find it practical to have only one entry point to deal with, governing
+ ingress with just the Backstage config.
+
+## Creating a Backstage Backend Plugin
+
+Much like the Backstage frontend, the Backstage backend also has a plugin
+system. The above mentioned proxy is actually one such plugin. If you were in
+need of a more involved integration than just direct access to the FrobsCo API,
+or if you needed to hold state, you may want to make such a plugin.
+
+Example:
+
+```ts
+// Inside your component
+const backendUrl = config.getString('backend.baseUrl');
+fetch(`${backendUrl}/frobs-aggregator/summary`)
+ .then(response => response.json())
+ .then(payload => setSummary(payload as FrobSummary));
+```
+
+```ts
+// Inside a new frobs-aggregator backend plugin
+router.use('/summary', async (req, res) => {
+ const agg = await Promise.all([
+ fetch('https://api.frobsco.com/v1/list'),
+ fetch('http://flerps.partnercompany.com:8080/flerp-batch'),
+ database.currentThunk(),
+ ]).then(async ([frobs, flerps, thunk]) => {
+ return computeAggregate(await frobs.json(), await flerps.json(), thunk);
+ });
+ res.status(200).send(agg);
+});
+```
+
+For a more detailed example, see
+[the lighthouse plugin](https://github.com/spotify/backstage/tree/master/plugins/lighthouse)
+that stores some state in a database and adds new capabilities to the underlying
+API.
+
+Internally at Spotify, this has been a fairly popular choice for different
+reasons. Commonly, the backend has been used as a caching and data massaging
+layer for slow APIs or APIs whose request/response shapes or speeds were not
+acceptable for direct use by frontends. For example, this has made it possible
+to issue efficient batch queries from the frontend, e.g. in big lists or tables
+that want to resolve a lot of sparse data from the larger list that an
+underlying service supplies.
+
+This may be used instead of the above, when:
+
+- You need to perform complex model conversion, or protocol translation beyond
+ what the proxy handles.
+- You want to perform aggregations or summaries on the backend instead of on the
+ frontend.
+- You want to enable batching or caching of slower or more unreliable APIs.
+- You need to maintain state for your plugin, perhaps using the builtin database
+ support in the backend.
+- You need to inject secrets or in other ways negotiate with other parts of the
+ API or other services in order to perform your work.
+- You want to enforce end user authentication / authorization for operations on
+ behalf of the API, have session handling, or similar.
+
+There is a balance to strike regarding when to make an entirely separate backend
+for a purpose, and when to make a Backstage backend plugin that adapts something
+that already exists. General advice is not easy to give, but contact us on
+Discord if you have any questions, and we may be able to offer guidance.
+
+## Extending the GraphQL Model
+
+The extensible GraphQL backend layer is not built yet. This section will be
+expanded when that happens. Stay tuned!
diff --git a/docs/plugins/create-a-plugin.md b/docs/plugins/create-a-plugin.md
index fa91e38b06..4bcc4da387 100644
--- a/docs/plugins/create-a-plugin.md
+++ b/docs/plugins/create-a-plugin.md
@@ -1,4 +1,7 @@
-# Create a Backstage Plugin
+---
+id: create-a-plugin
+title: Create a Backstage Plugin
+---
A Backstage Plugin adds functionality to Backstage.
@@ -12,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:
@@ -37,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/existing-plugins.md b/docs/plugins/existing-plugins.md
index bd6fd19691..8598ae02c4 100644
--- a/docs/plugins/existing-plugins.md
+++ b/docs/plugins/existing-plugins.md
@@ -1,4 +1,7 @@
-# Existing plugins
+---
+id: existing-plugins
+title: Existing plugins
+---
## Open source plugins
diff --git a/docs/plugins/index.md b/docs/plugins/index.md
index 5021ac9896..5aaf8acadf 100644
--- a/docs/plugins/index.md
+++ b/docs/plugins/index.md
@@ -1,4 +1,7 @@
-# Plugins
+---
+id: index
+title: Intro to plugins
+---
Backstage is a single-page application composed of a set of plugins.
@@ -8,7 +11,7 @@ development tool as a plugin in Backstage. By following strong
[design guidelines](../dls/design.md) we ensure the the overall user experience
stays consistent between plugins.
-
+
## Creating a plugin
@@ -18,8 +21,15 @@ To create a plugin, follow the steps outlined [here](create-a-plugin.md).
If you start developing a plugin that you aim to release as open source, we
suggest that you create a new
-[new Issue](https://github.com/spotify/backstage/issues/new?template=plugin_template.md).
+[new Issue](https://github.com/spotify/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.
You can also use this process if you have an idea for a good plugin but you hope
that someone else will pick up the work.
+
+## Integrate into the Service Catalog
+
+If your plugin isn't supposed to live as a standalone page, but rather needs to
+be presented as a part of a Service Catalog (e.g. a separate tab or a card on an
+"Overview" tab), then check out
+[the instruction](integrating-plugin-into-service-catalog.md). on how to do it.
diff --git a/docs/plugins/integrating-plugin-into-service-catalog.md b/docs/plugins/integrating-plugin-into-service-catalog.md
new file mode 100644
index 0000000000..4408c27ccc
--- /dev/null
+++ b/docs/plugins/integrating-plugin-into-service-catalog.md
@@ -0,0 +1,124 @@
+---
+id: integrating-plugin-into-service-catalog
+title: Integrate into the Service Catalog
+---
+
+> This is an advanced use case and currently is an experimental feature. Expect
+> API to change over time
+
+## Steps
+
+1. [Create a plugin](#create-a-plugin)
+1. [Export a router with relative routes](#export-a-router)
+1. [Import and use router in the APP](#import-and-use-router-in-the-app)
+
+### Create a plugin
+
+Follow the [same process](create-a-plugin.md) as for standalone plugin. You
+should have a separate package in a folder, which represents your plugin.
+
+Example:
+
+```
+$ yarn create-plugin
+> ? Enter an ID for the plugin [required] my-plugin
+> ? Enter the owner(s) of the plugin. If specified, this will be added to CODEOWNERS for the plugin path. [optional]
+
+Creating the plugin...
+```
+
+### Export a router
+
+Now in the plugin you have a `Router.tsx` file in the `src` folder. By default
+it contains only one example route. Create a routing structure needed for your
+plugin, keeping in mind that the whole set of routes defined here are going to
+be mounted under some different route in the App.
+
+Example:
+
+`my-plugin` consists of 2 different views - `/me` and `/about`. I envision
+people integrating it into plugin catalog as a tab named "MyPlugin". Then, my
+`Routes.tsx` for the plugin is going to look like:
+
+```tsx
+
+ } />
+ } />
+
+```
+
+(where MePage and AboutPage are 2 components defined in your plugin and imported
+accordingly inside `Router.tsx`)
+
+> Pay attention, if your `MePage` references the `AboutPage` it needs to do it
+> through link to `about`, not `/about`. This allows react-router v6 to enable
+> its relative routing mechanism. Read more -
+> https://reacttraining.com/blog/react-router-v6-pre/#relative-route-path-and-link-to
+
+### Import and use router in the APP
+
+In the `app/src/components/catalog/EntityPage.tsx` (app === your folder,
+containing backstage app) import your created Router:
+
+```tsx
+import { Router as MyPluginRouter } from '@backstage/plugin-my-plugin;
+```
+
+Now, you need to mount `MyPluginRouter` onto some route, for example if you had:
+
+```tsx
+const DefaultEntityPage = ({ entity }: { entity: Entity }) => (
+
+ }
+ />
+
+);
+```
+
+after you add your code it becomes:
+
+```tsx
+const DefaultEntityPage = ({ entity }: { entity: Entity }) => (
+
+ }
+ />
+ }
+ />
+
+);
+```
+
+All of magic happens thanks to the `EntityPageLayout` component, which comes as
+an export from `@backstage/plugin-catalog` package.
+
+```tsx
+type EntityPageLayoutContentProps = {
+ /**
+ * Going to be transformed into react-router v6
+ * path under the hood. Read more at https://reacttraining.com/blog/react-router-v6-pre
+ */
+ path: string;
+ /**
+ * Gets transformed into the title for the tab
+ */
+ title: string;
+ /**
+ * Element that is rendered when the location
+ * matches the path provided
+ */
+ element: JSX.Element;
+};
+```
+
+> You can either pass the entity from App to the plugin's router as a prop or
+> use `useEntity` hook from `@backstage/plugin-catalog` directly inside your
+> plugin.
diff --git a/docs/plugins/plugin-development.md b/docs/plugins/plugin-development.md
index 41918b5de2..faf3c6ddbd 100644
--- a/docs/plugins/plugin-development.md
+++ b/docs/plugins/plugin-development.md
@@ -1,4 +1,7 @@
-# Plugin Development in Backstage
+---
+id: plugin-development
+title: Plugin Development
+---
Backstage plugins provide features to a Backstage App.
@@ -7,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/plugins/proxying.md b/docs/plugins/proxying.md
index e69de29bb2..658df3dda1 100644
--- a/docs/plugins/proxying.md
+++ b/docs/plugins/proxying.md
@@ -0,0 +1,75 @@
+---
+id: proxying
+title: Proxying
+---
+
+## Overview
+
+The Backstage backend comes packaged with a basic HTTP proxy, that can aid in
+reaching backend service APIs from frontend plugin code. See
+[Call Existing API](call-existing-api.md) for a description of when the proxy
+can be the best choice for communicating with an API.
+
+## Getting Started
+
+The plugin is already added to a default Backstage project.
+
+In `packages/backend/src/index.ts`:
+
+```ts
+const proxyEnv = useHotMemoize(module, () => createEnv('proxy'));
+
+const service = createServiceBuilder(module)
+ .loadConfig(configReader)
+ /** ... other routers ... */
+ .addRouter('/proxy', await proxy(proxyEnv, '/proxy'));
+```
+
+## Configuration
+
+Configuration for the proxy plugin lives under a `proxy` root key of your
+`app-config.yaml` file.
+
+Example:
+
+```yaml
+# in app-config.yaml
+proxy:
+ '/simple-example': http://simple.example.com:8080
+ '/larger-example/v1':
+ target: http://larger.example.com:8080/svc.v1
+ headers:
+ Authorization:
+ $secret:
+ env: EXAMPLE_AUTH_HEADER
+```
+
+Each key under the proxy configuration entry is a route to match, below the
+prefix that the proxy plugin is mounted on. It must start with a slash. For
+example, if the backend mounts the proxy plugin as `/proxy`, the above
+configuration will lead to the proxy acting on backend requests to
+`/proxy/simple-example/...` and `/proxy/larger-example/v1/...`.
+
+The value inside each route is either a simple URL string, or an object on the
+format accepted by
+[http-proxy-middleware](https://www.npmjs.com/package/http-proxy-middleware).
+
+If the value is a string, it is assumed to correspond to:
+
+```yaml
+target:
+changeOrigin: true
+pathRewrite:
+ '^/': '/'
+```
+
+When the target is an object, it is given verbatim to `http-proxy-middleware`
+except with the following caveats for convenience:
+
+- If `changeOrigin` is not specified, it is set to `true`. This is the most
+ commonly useful value.
+- If `pathRewrite` is not specified, it is set to a single rewrite that removes
+ the entire prefix and route. In the above example, a rewrite of
+ `'^/proxy/larger-example/v1/': '/'` is added. That means that a request to
+ `/proxy/larger-example/v1/some/path` will be translated to a request to
+ `http://larger.example.com:8080/svc.v1/some/path`.
diff --git a/docs/plugins/publish-private.md b/docs/plugins/publish-private.md
index e69de29bb2..6361f70854 100644
--- a/docs/plugins/publish-private.md
+++ b/docs/plugins/publish-private.md
@@ -0,0 +1,6 @@
+---
+id: publish-private
+title: Publish private
+---
+
+## TODO
diff --git a/docs/plugins/publishing.md b/docs/plugins/publishing.md
index 76997c30d2..6fee4f9b1d 100644
--- a/docs/plugins/publishing.md
+++ b/docs/plugins/publishing.md
@@ -1,4 +1,7 @@
-# Publishing
+---
+id: publishing
+title: Publishing
+---
## NPM
@@ -36,4 +39,18 @@ $ git push origin -u new-release
And then create a PR. Once the PR is approved and merged into master, the master
build will publish new versions of all bumped packages.
+### Include new changes in existing release PR
+
+If you want to include some last minute changes to an existing release PR,
+follow these instructions:
+
+```sh
+$ git checkout master
+$ git pull
+$ git checkout new-release
+$ git reset --hard master
+$ yarn release
+$ git push --force
+```
+
[Back to Docs](../README.md)
diff --git a/docs/plugins/structure-of-a-plugin.md b/docs/plugins/structure-of-a-plugin.md
index ceacf578fe..20e72c539d 100644
--- a/docs/plugins/structure-of-a-plugin.md
+++ b/docs/plugins/structure-of-a-plugin.md
@@ -1,4 +1,7 @@
-# Structure of a Plugin
+---
+id: structure-of-a-plugin
+title: Structure of a Plugin
+---
Nice, you have a new plugin! We'll soon see how we can develop it into doing
great things. But first off, let's look at what we get out of the box.
diff --git a/docs/plugins/testing.md b/docs/plugins/testing.md
index 701db3eff4..110bc97515 100644
--- a/docs/plugins/testing.md
+++ b/docs/plugins/testing.md
@@ -1,4 +1,7 @@
-# Testing with Jest
+---
+id: testing
+title: Testing with Jest
+---
Backstage uses [Jest](https://facebook.github.io/jest/) for all our unit testing
needs.
diff --git a/docs/reference/createPlugin-feature-flags.md b/docs/reference/createPlugin-feature-flags.md
index 0f1debd515..bc38656939 100644
--- a/docs/reference/createPlugin-feature-flags.md
+++ b/docs/reference/createPlugin-feature-flags.md
@@ -1,4 +1,7 @@
-# createPlugin - feature flags
+---
+id: createPlugin-feature-flags
+title: createPlugin - feature flags
+---
The `featureFlags` object passed to the `register` function makes it possible
for plugins to register Feature Flags in Backstage for users to opt into. You
diff --git a/docs/reference/createPlugin-router.md b/docs/reference/createPlugin-router.md
index 831b27f388..361b485df9 100644
--- a/docs/reference/createPlugin-router.md
+++ b/docs/reference/createPlugin-router.md
@@ -1,4 +1,7 @@
-# createPlugin - router
+---
+id: createPlugin-router
+title: createPlugin - router
+---
The router that is passed to the `register` function makes it possible for
plugins to hook into routing of the Backstage app and provide the end users with
@@ -34,5 +37,3 @@ const myPluginRouteRef = createRouteRef({
title: 'My Plugin',
});
```
-
-[Back to References](../README.md)
diff --git a/docs/reference/createPlugin.md b/docs/reference/createPlugin.md
index 7ecb6d461a..0cabe63b39 100644
--- a/docs/reference/createPlugin.md
+++ b/docs/reference/createPlugin.md
@@ -1,4 +1,7 @@
-# createPlugin
+---
+id: createPlugin
+title: createPlugin
+---
Taking a plugin config as argument and returns a new plugin.
diff --git a/docs/reference/utility-apis/AppThemeApi.md b/docs/reference/utility-apis/AppThemeApi.md
index 2c57199fba..eda1bafef0 100644
--- a/docs/reference/utility-apis/AppThemeApi.md
+++ b/docs/reference/utility-apis/AppThemeApi.md
@@ -178,7 +178,10 @@ type PaletteAdditions = {
linkHover: string;
link: string;
gold: string;
- sidebar: string;
+ navigation: {
+ background: string;
+ indicator: string;
+ };
tabbar: {
indicator: string;
};
diff --git a/docs/reference/utility-apis/README.md b/docs/reference/utility-apis/README.md
index 8b9ebcbdad..521628fd33 100644
--- a/docs/reference/utility-apis/README.md
+++ b/docs/reference/utility-apis/README.md
@@ -1,11 +1,14 @@
-# Backstage Core Utility APIs
+---
+id: README
+title: Utility API References
+---
The following is a list of all Utility APIs defined by `@backstage/core`. They
are available to use by plugins and components, and can be accessed using the
`useApi` hook, also provided by `@backstage/core`. For more information, see
https://github.com/spotify/backstage/blob/master/docs/api/utility-apis.md.
-### alert
+## alert
Used to report alerts and forward them to the app
@@ -14,7 +17,7 @@ Implemented type: [AlertApi](./AlertApi.md)
ApiRef:
[alertApiRef](https://github.com/spotify/backstage/blob/f8780ff32509d0326bc513791ea60846d7614b34/packages/core-api/src/apis/definitions/AlertApi.ts#L41)
-### appTheme
+## appTheme
API Used to configure the app theme, and enumerate options
@@ -23,7 +26,7 @@ Implemented type: [AppThemeApi](./AppThemeApi.md)
ApiRef:
[appThemeApiRef](https://github.com/spotify/backstage/blob/f8780ff32509d0326bc513791ea60846d7614b34/packages/core-api/src/apis/definitions/AppThemeApi.ts#L74)
-### config
+## config
Used to access runtime configuration
@@ -32,7 +35,7 @@ Implemented type: [Config](./Config.md)
ApiRef:
[configApiRef](https://github.com/spotify/backstage/blob/f8780ff32509d0326bc513791ea60846d7614b34/packages/core-api/src/apis/definitions/ConfigApi.ts#L22)
-### error
+## error
Used to report errors and forward them to the app
@@ -41,7 +44,7 @@ Implemented type: [ErrorApi](./ErrorApi.md)
ApiRef:
[errorApiRef](https://github.com/spotify/backstage/blob/f8780ff32509d0326bc513791ea60846d7614b34/packages/core-api/src/apis/definitions/ErrorApi.ts#L65)
-### featureFlags
+## featureFlags
Used to toggle functionality in features across Backstage
@@ -50,9 +53,9 @@ Implemented type: [FeatureFlagsApi](./FeatureFlagsApi.md)
ApiRef:
[featureFlagsApiRef](https://github.com/spotify/backstage/blob/f8780ff32509d0326bc513791ea60846d7614b34/packages/core-api/src/apis/definitions/FeatureFlagsApi.ts#L58)
-### githubAuth
+## githubAuth
-Provides authentication towards Github APIs
+Provides authentication towards GitHub APIs
Implemented types: [OAuthApi](./OAuthApi.md),
[ProfileInfoApi](./ProfileInfoApi.md),
@@ -62,9 +65,9 @@ Implemented types: [OAuthApi](./OAuthApi.md),
ApiRef:
[githubAuthApiRef](https://github.com/spotify/backstage/blob/f8780ff32509d0326bc513791ea60846d7614b34/packages/core-api/src/apis/definitions/auth.ts#L230)
-### gitlabAuth
+## gitlabAuth
-Provides authentication towards Gitlab APIs
+Provides authentication towards GitLab APIs
Implemented types: [OAuthApi](./OAuthApi.md),
[ProfileInfoApi](./ProfileInfoApi.md),
@@ -74,7 +77,7 @@ Implemented types: [OAuthApi](./OAuthApi.md),
ApiRef:
[gitlabAuthApiRef](https://github.com/spotify/backstage/blob/f8780ff32509d0326bc513791ea60846d7614b34/packages/core-api/src/apis/definitions/auth.ts#L260)
-### googleAuth
+## googleAuth
Provides authentication towards Google APIs and identities
@@ -87,7 +90,7 @@ Implemented types: [OAuthApi](./OAuthApi.md),
ApiRef:
[googleAuthApiRef](https://github.com/spotify/backstage/blob/f8780ff32509d0326bc513791ea60846d7614b34/packages/core-api/src/apis/definitions/auth.ts#L213)
-### identity
+## identity
Provides access to the identity of the signed in user
@@ -96,7 +99,7 @@ Implemented type: [IdentityApi](./IdentityApi.md)
ApiRef:
[identityApiRef](https://github.com/spotify/backstage/blob/f8780ff32509d0326bc513791ea60846d7614b34/packages/core-api/src/apis/definitions/IdentityApi.ts#L54)
-### oauth2
+## oauth2
Example of how to use oauth2 custom provider
@@ -107,7 +110,7 @@ Implemented types: [OAuthApi](./OAuthApi.md),
ApiRef:
[oauth2ApiRef](https://github.com/spotify/backstage/blob/f8780ff32509d0326bc513791ea60846d7614b34/packages/core-api/src/apis/definitions/auth.ts#L270)
-### oauthRequest
+## oauthRequest
An API for implementing unified OAuth flows in Backstage
@@ -116,7 +119,7 @@ Implemented type: [OAuthRequestApi](./OAuthRequestApi.md)
ApiRef:
[oauthRequestApiRef](https://github.com/spotify/backstage/blob/f8780ff32509d0326bc513791ea60846d7614b34/packages/core-api/src/apis/definitions/OAuthRequestApi.ts#L130)
-### oktaAuth
+## oktaAuth
Provides authentication towards Okta APIs
@@ -129,7 +132,7 @@ Implemented types: [OAuthApi](./OAuthApi.md),
ApiRef:
[oktaAuthApiRef](https://github.com/spotify/backstage/blob/f8780ff32509d0326bc513791ea60846d7614b34/packages/core-api/src/apis/definitions/auth.ts#L243)
-### storage
+## storage
Provides the ability to store data which is unique to the user
diff --git a/docs/tutorials/index.md b/docs/tutorials/index.md
deleted file mode 100644
index e69de29bb2..0000000000
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/docs/verify-links.js b/docs/verify-links.js
new file mode 100755
index 0000000000..a218cde71b
--- /dev/null
+++ b/docs/verify-links.js
@@ -0,0 +1,124 @@
+#!/usr/bin/env node
+/*
+ * Copyright 2020 Spotify AB
+ *
+ * Licensed under the Apache License, Version 2.0 (the "License");
+ * you may not use this file except in compliance with the License.
+ * You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing, software
+ * distributed under the License is distributed on an "AS IS" BASIS,
+ * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
+ * See the License for the specific language governing permissions and
+ * limitations under the License.
+ */
+
+const { resolve: resolvePath, dirname } = require('path');
+const fs = require('fs-extra');
+const recursive = require('recursive-readdir');
+
+const projectRoot = resolvePath(__dirname, '..');
+
+async function verifyUrl(basePath, url) {
+ // Avoid having absolute URL links within docs/, so that links work on the site
+ if (
+ url.match(
+ /https:\/\/github.com\/spotify\/backstage\/(tree|blob)\/master\/docs\//,
+ ) &&
+ basePath.match(/^(?:docs|microsite)\//)
+ ) {
+ return { url, basePath, problem: 'absolute' };
+ }
+
+ url = url.replace(/#.*$/, '');
+ url = url.replace(
+ /https:\/\/github.com\/spotify\/backstage\/(tree|blob)\/master/,
+ '',
+ );
+ if (!url) {
+ return;
+ }
+
+ // Only verify existence of local files for now, so skip anything with a schema
+ if (url.match(/[a-z]+:/)) {
+ return;
+ }
+
+ let path = '';
+
+ if (url.startsWith('/')) {
+ if (url.startsWith('/docs/') && basePath.match(/^(?:docs|microsite)\//)) {
+ return { url, basePath, problem: 'not-relative' };
+ }
+
+ path = resolvePath(projectRoot, `.${url}`);
+ } else {
+ path = resolvePath(dirname(resolvePath(projectRoot, basePath)), url);
+ }
+
+ const exists = await fs.pathExists(path);
+ if (!exists) {
+ return { url, basePath, problem: 'missing' };
+ }
+
+ return;
+}
+
+async function verifyFile(filePath) {
+ const content = await fs.readFile(filePath, 'utf8');
+ const mdLinks = content.match(/\[.+?\]\(.+?\)/g) || [];
+ const badUrls = [];
+
+ for (const mdLink of mdLinks) {
+ const url = mdLink.match(/\[.+\]\((.+)\)/)[1].trim();
+ const badUrl = await verifyUrl(filePath, url);
+ if (badUrl) {
+ badUrls.push(badUrl);
+ }
+ }
+
+ return badUrls;
+}
+
+async function main() {
+ process.chdir(projectRoot);
+
+ const files = await recursive('.', [
+ 'node_modules',
+ 'dist',
+ 'bin',
+ 'microsite',
+ ]);
+ const mdFiles = files.filter(f => f.endsWith('.md'));
+ const badUrls = [];
+
+ for (const mdFile of mdFiles) {
+ const badFileUrls = await verifyFile(mdFile);
+ badUrls.push(...badFileUrls);
+ }
+
+ if (badUrls.length) {
+ console.log(`Found ${badUrls.length} bad links within repo`);
+ for (const { url, basePath, problem } of badUrls) {
+ if (problem === 'missing') {
+ console.error(`Unable to reach ${url}, linked from ${basePath}`);
+ } else if (problem === 'not-relative') {
+ console.error('Links to /docs/ must be relative');
+ console.error(` From: ${basePath}`);
+ console.error(` To: ${url}`);
+ } else if (problem === 'absolute') {
+ console.error(`Link to docs/ should be replaced by a relative URL`);
+ console.error(` From: ${basePath}`);
+ console.error(` To: ${url}`);
+ }
+ }
+ process.exit(1);
+ }
+}
+
+main().catch(error => {
+ console.error(error.stack);
+ process.exit(1);
+});
diff --git a/install/kubernetes/backstage/README.md b/install/kubernetes/backstage/README.md
index e8d809c228..fc3d20733b 100644
--- a/install/kubernetes/backstage/README.md
+++ b/install/kubernetes/backstage/README.md
@@ -23,7 +23,7 @@
| app.resources | Kubernetes Pod resource requests/limits | `{}` |
| app.nodeSelector | Node selectors for scheduling app/frontend pods | `{}` |
| app.tolerations | Tolerations for scheduling app/frontend pods | `{}` |
-| app.affinity | Affinity setttings for scheduling app/frontend pods | `{}` |
+| app.affinity | Affinity settings for scheduling app/frontend pods | `{}` |
## Backend Values
@@ -48,4 +48,4 @@
| backend.resources | Kubernetes Pod resource requests/limits | `{}` |
| backend.nodeSelector | Node selectors for scheduling backend pods | `{}` |
| backend.tolerations | Tolerations for scheduling backend pods | `{}` |
-| backend.affinity | Affinity setttings for scheduling backend pods | `{}` |
+| backend.affinity | Affinity settings for scheduling backend pods | `{}` |
diff --git a/lerna.json b/lerna.json
index 35f84c54d0..63e4701ce3 100644
--- a/lerna.json
+++ b/lerna.json
@@ -2,5 +2,5 @@
"packages": ["packages/*", "plugins/*"],
"npmClient": "yarn",
"useWorkspaces": true,
- "version": "0.1.1-alpha.18"
+ "version": "0.1.1-alpha.20"
}
diff --git a/microsite/README.md b/microsite/README.md
new file mode 100644
index 0000000000..d7187888a3
--- /dev/null
+++ b/microsite/README.md
@@ -0,0 +1,182 @@
+This website was created with [Docusaurus](https://docusaurus.io/).
+
+# What's In This Document
+
+- [Get Started in 5 Minutes](#get-started-in-5-minutes)
+- [Directory Structure](#directory-structure)
+- [Editing Content](#editing-content)
+- [Adding Content](#adding-content)
+- [Full Documentation](#full-documentation)
+
+## Directory Structure
+
+Your project file structure should look something like this
+
+```
+my-docusaurus/
+ docs/
+ doc-1.md
+ doc-2.md
+ doc-3.md
+ website/
+ blog/
+ 2016-3-11-oldest-post.md
+ 2017-10-24-newest-post.md
+ core/
+ node_modules/
+ pages/
+ static/
+ css/
+ img/
+ package.json
+ sidebars.json
+ siteConfig.js
+```
+
+# Editing Content
+
+## Editing an existing docs page
+
+Edit docs by navigating to `docs/` and editing the corresponding document:
+
+`docs/doc-to-be-edited.md`
+
+```markdown
+---
+id: page-needs-edit
+title: This Doc Needs To Be Edited
+---
+
+Edit me...
+```
+
+For more information about docs, click [here](https://docusaurus.io/docs/en/navigation)
+
+## Editing an existing blog post
+
+Edit blog posts by navigating to `website/blog` and editing the corresponding post:
+
+`website/blog/post-to-be-edited.md`
+
+```markdown
+---
+id: post-needs-edit
+title: This Blog Post Needs To Be Edited
+---
+
+Edit me...
+```
+
+For more information about blog posts, click [here](https://docusaurus.io/docs/en/adding-blog)
+
+# Adding Content
+
+## Adding a new docs page to an existing sidebar
+
+1. Create the doc as a new markdown file in `/docs`, example `docs/newly-created-doc.md`:
+
+```md
+---
+id: newly-created-doc
+title: This Doc Needs To Be Edited
+---
+
+My new content here..
+```
+
+1. Refer to that doc's ID in an existing sidebar in `website/sidebars.json`:
+
+```javascript
+// Add newly-created-doc to the Getting Started category of docs
+{
+ "docs": {
+ "Getting Started": [
+ "quick-start",
+ "newly-created-doc" // new doc here
+ ],
+ ...
+ },
+ ...
+}
+```
+
+For more information about adding new docs, click [here](https://docusaurus.io/docs/en/navigation)
+
+## Adding a new blog post
+
+1. Make sure there is a header link to your blog in `website/siteConfig.js`:
+
+`website/siteConfig.js`
+
+```javascript
+headerLinks: [
+ ...
+ { blog: true, label: 'Blog' },
+ ...
+]
+```
+
+2. Create the blog post with the format `YYYY-MM-DD-My-Blog-Post-Title.md` in `website/blog`:
+
+`website/blog/2018-05-21-New-Blog-Post.md`
+
+```markdown
+---
+author: Frank Li
+authorURL: https://twitter.com/foobarbaz
+authorFBID: 503283835
+title: New Blog Post
+---
+
+Lorem Ipsum...
+```
+
+For more information about blog posts, click [here](https://docusaurus.io/docs/en/adding-blog)
+
+## Adding items to your site's top navigation bar
+
+1. Add links to docs, custom pages or external links by editing the headerLinks field of `website/siteConfig.js`:
+
+`website/siteConfig.js`
+
+```javascript
+{
+ headerLinks: [
+ ...
+ /* you can add docs */
+ { doc: 'my-examples', label: 'Examples' },
+ /* you can add custom pages */
+ { page: 'help', label: 'Help' },
+ /* you can add external links */
+ { href: 'https://github.com/facebook/docusaurus', label: 'GitHub' },
+ ...
+ ],
+ ...
+}
+```
+
+For more information about the navigation bar, click [here](https://docusaurus.io/docs/en/navigation)
+
+## Adding custom pages
+
+1. Docusaurus uses React components to build pages. The components are saved as .js files in `website/pages/en`:
+1. If you want your page to show up in your navigation header, you will need to update `website/siteConfig.js` to add to the `headerLinks` element:
+
+`website/siteConfig.js`
+
+```javascript
+{
+ headerLinks: [
+ ...
+ { page: 'my-new-custom-page', label: 'My New Custom Page' },
+ ...
+ ],
+ ...
+}
+```
+
+For more information about custom pages, click [here](https://docusaurus.io/docs/en/custom-pages).
+
+# Full Documentation
+
+Full documentation can be found on the [website](https://docusaurus.io/).
diff --git a/microsite/blog/2020-03-16-announcing-backstage.md b/microsite/blog/2020-03-16-announcing-backstage.md
new file mode 100644
index 0000000000..3911debf08
--- /dev/null
+++ b/microsite/blog/2020-03-16-announcing-backstage.md
@@ -0,0 +1,44 @@
+---
+title: Announcing Backstage
+author: Stefan Ålund
+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.
+
+
+
+
+
+## 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 me directly: [alund@spotify.com](mailto:alund@spotify.com).
diff --git a/microsite/blog/2020-03-18-what-is-backstage.md b/microsite/blog/2020-03-18-what-is-backstage.md
new file mode 100644
index 0000000000..8b0a0fcbe6
--- /dev/null
+++ b/microsite/blog/2020-03-18-what-is-backstage.md
@@ -0,0 +1,88 @@
+---
+title: What the heck is Backstage anyway?
+author: Stefan Ålund
+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.
+
+
+
+## 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/spotify/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/spotify/backstage/milestones
+
+Want to discuss the project or need support? Join us on [Discord](https://discord.gg/MUpMjP2) or reach out on [alund@spotify.com](mailto:alund@spotify.com).
diff --git a/microsite/blog/2020-04-06-lighthouse-plugin.md b/microsite/blog/2020-04-06-lighthouse-plugin.md
new file mode 100644
index 0000000000..2d5c7b96b7
--- /dev/null
+++ b/microsite/blog/2020-04-06-lighthouse-plugin.md
@@ -0,0 +1,40 @@
+---
+title: Introducing Lighthouse for Backstage
+author: Paul Marbach
+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.
+
+
+
+## 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/spotify/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.
diff --git a/microsite/blog/2020-04-30-how-to-quickly-set-up-backstage.md b/microsite/blog/2020-04-30-how-to-quickly-set-up-backstage.md
new file mode 100644
index 0000000000..65ee02f6a0
--- /dev/null
+++ b/microsite/blog/2020-04-30-how-to-quickly-set-up-backstage.md
@@ -0,0 +1,135 @@
+---
+title: How to quickly set up Backstage
+author: Marcus Eide
+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).
+
+
+
+## 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/cli 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 start
+```
+
+And you are good to go! 👍
+
+Read the full documentation on how to [create an app](/docs/getting-started/create-an-app.md) 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 (`/packages/app`) with:
+
+```bash
+yarn add @backstage/plugin-
+```
+
+Then add it to your app's `plugin.ts` file to import and register it:
+
+`/packages/app/src/plugin.ts`:
+
+```js
+export { plugin as PluginName } from '@backstage/plugin-';
+```
+
+A plugin registers its own `route` in the app — read the documentation for the specific plugin you are installing for more information on that.
+
+### 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 (``) run:
+
+```bash
+yarn create-plugin
+```
+
+This command will create a new plugin in `/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/spotify/backstage) or download our [CLI](https://www.npmjs.com/package/@backstage/cli). If you have more questions, join us on [Discord](https://discord.gg/MUpMjP2) or [create an issue](https://github.com/spotify/backstage/issues/new/choose).
diff --git a/microsite/blog/2020-05-14-tech-radar-plugin.md b/microsite/blog/2020-05-14-tech-radar-plugin.md
new file mode 100644
index 0000000000..d78d5d67fa
--- /dev/null
+++ b/microsite/blog/2020-05-14-tech-radar-plugin.md
@@ -0,0 +1,44 @@
+---
+title: Introducing Tech Radar for Backstage
+author: Bilawal Hameed
+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]!
+
+
+
+## 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/spotify/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/spotify/backstage/tree/master/plugins/tech-radar
+[thoughtworks]: https://www.thoughtworks.com/radar
+[zalando]: https://opensource.zalando.com/tech-radar/
diff --git a/microsite/blog/2020-05-14-weaveworks-covid-19-app-uses-backstage-ui.md b/microsite/blog/2020-05-14-weaveworks-covid-19-app-uses-backstage-ui.md
new file mode 100644
index 0000000000..68e3f903c7
--- /dev/null
+++ b/microsite/blog/2020-05-14-weaveworks-covid-19-app-uses-backstage-ui.md
@@ -0,0 +1,33 @@
+---
+title: Weaveworks’ COVID-19 app uses Backstage UI
+author: Jeff Feng
+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.
+
+
+
+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
diff --git a/microsite/blog/2020-05-22-phase-2-service-catalog.md b/microsite/blog/2020-05-22-phase-2-service-catalog.md
new file mode 100644
index 0000000000..682965d2dd
--- /dev/null
+++ b/microsite/blog/2020-05-22-phase-2-service-catalog.md
@@ -0,0 +1,54 @@
+---
+title: Starting Phase 2: The Service Catalog
+author: Stefan Ålund
+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/spotify/backstage#project-roadmap).
+
+
+
+
+
+## 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/spotify/backstage/labels/plugin). In fact, thanks to our amazing (30+) [contributors](https://github.com/spotify/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/spotify/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/adr002-default-catalog-file-format.md) 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/spotify/backstage/tree/master/plugins/circleci) to show only the builds for the specific service you are viewing, or a [Spinnaker](https://github.com/spotify/backstage/issues/631) plugin to show running deployments, or an Open API plugin to [show documentation](https://github.com/spotify/backstage/issues/627) for endpoints exposed by the service, or the [Lighthouse](https://github.com/spotify/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/spotify/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!
diff --git a/microsite/blog/2020-06-22-backstage-service-catalog-alpha.md b/microsite/blog/2020-06-22-backstage-service-catalog-alpha.md
new file mode 100644
index 0000000000..0928b8769b
--- /dev/null
+++ b/microsite/blog/2020-06-22-backstage-service-catalog-alpha.md
@@ -0,0 +1,54 @@
+---
+title: Backstage Service Catalog released in alpha
+author: Stefan Ålund
+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.
+
+
+
+
+
+## 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/adr002-default-catalog-file-format.md#format) 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/spotify/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/spotify/backstage/issues), ping us on [Discord chat](https://discord.gg/EBHEGzX) or send me an email at [alund@spotify.com](mailto:alund@spotify.com) 🙏
+
+To get regular product updates and news about the Backstage community, sign up for the [Backstage newsletter](https://mailchi.mp/spotify/backstage-community).
diff --git a/microsite/blog/2020-07-01-how-to-enable-authentication-in-backstage-using-passport.md b/microsite/blog/2020-07-01-how-to-enable-authentication-in-backstage-using-passport.md
new file mode 100644
index 0000000000..ccdd8b34c6
--- /dev/null
+++ b/microsite/blog/2020-07-01-how-to-enable-authentication-in-backstage-using-passport.md
@@ -0,0 +1,46 @@
+---
+title: How to enable authentication in Backstage using Passport
+author: Lee Mills
+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.
+
+
+
+## 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/spotify/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 `/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.md) 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/spotify/backstage/issues?q=is%3Aissue+is%3Aopen+label%3Aauth).
diff --git a/microsite/blog/2020-08-05-announcing-backstage-software-templates.md b/microsite/blog/2020-08-05-announcing-backstage-software-templates.md
new file mode 100644
index 0000000000..51c1da2885
--- /dev/null
+++ b/microsite/blog/2020-08-05-announcing-backstage-software-templates.md
@@ -0,0 +1,78 @@
+---
+title: Announcing Backstage Software Templates
+author: Stefan Ålund
+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.
+
+
+
+
+
+## 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`. If you’ve already been running Backstage locally, run the command `yarn lerna run mock-data` to load the new sample templates into the Service Catalog first.
+
+
+
+### 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/software-templates-index). 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/spotify/backstage/issues), ping us on [Discord chat](https://discord.gg/EBHEGzX) or send me an email at [alund@spotify.com](mailto:alund@spotify.com) 🙏
+
+To get regular product updates and news about the Backstage community, sign up for the [Backstage newsletter](https://mailchi.mp/spotify/backstage-community).
diff --git a/microsite/blog/assets/2/1.png b/microsite/blog/assets/2/1.png
new file mode 100644
index 0000000000..21fb8bc26f
Binary files /dev/null and b/microsite/blog/assets/2/1.png differ
diff --git a/microsite/blog/assets/2/2.png b/microsite/blog/assets/2/2.png
new file mode 100644
index 0000000000..16fa0cf5bf
Binary files /dev/null and b/microsite/blog/assets/2/2.png differ
diff --git a/microsite/blog/assets/2/3.png b/microsite/blog/assets/2/3.png
new file mode 100644
index 0000000000..f610782186
Binary files /dev/null and b/microsite/blog/assets/2/3.png differ
diff --git a/microsite/blog/assets/2/4.png b/microsite/blog/assets/2/4.png
new file mode 100644
index 0000000000..d5e59ef92a
Binary files /dev/null and b/microsite/blog/assets/2/4.png differ
diff --git a/microsite/blog/assets/2/5.png b/microsite/blog/assets/2/5.png
new file mode 100644
index 0000000000..00a6163c9a
Binary files /dev/null and b/microsite/blog/assets/2/5.png differ
diff --git a/microsite/blog/assets/2/screen.gif b/microsite/blog/assets/2/screen.gif
new file mode 100644
index 0000000000..a0d52a23b4
Binary files /dev/null and b/microsite/blog/assets/2/screen.gif differ
diff --git a/microsite/blog/assets/2/spotify-labs-header.png b/microsite/blog/assets/2/spotify-labs-header.png
new file mode 100644
index 0000000000..8effd4b05a
Binary files /dev/null and b/microsite/blog/assets/2/spotify-labs-header.png differ
diff --git a/microsite/blog/assets/20-05-14/weaveworks-firekube-covid-19-spotify-backstage.png b/microsite/blog/assets/20-05-14/weaveworks-firekube-covid-19-spotify-backstage.png
new file mode 100644
index 0000000000..fc5d05cd5d
Binary files /dev/null and b/microsite/blog/assets/20-05-14/weaveworks-firekube-covid-19-spotify-backstage.png differ
diff --git a/microsite/blog/assets/20-05-20/Service_Catalog_MVP.png b/microsite/blog/assets/20-05-20/Service_Catalog_MVP.png
new file mode 100644
index 0000000000..4a50f17d15
Binary files /dev/null and b/microsite/blog/assets/20-05-20/Service_Catalog_MVP.png differ
diff --git a/microsite/blog/assets/20-05-20/Service_Catalog_MVP_service.png b/microsite/blog/assets/20-05-20/Service_Catalog_MVP_service.png
new file mode 100644
index 0000000000..8067f665c9
Binary files /dev/null and b/microsite/blog/assets/20-05-20/Service_Catalog_MVP_service.png differ
diff --git a/microsite/blog/assets/20-05-20/tabs.png b/microsite/blog/assets/20-05-20/tabs.png
new file mode 100644
index 0000000000..4a5b11f6fe
Binary files /dev/null and b/microsite/blog/assets/20-05-20/tabs.png differ
diff --git a/microsite/blog/assets/20-07-01/auth-landing.png b/microsite/blog/assets/20-07-01/auth-landing.png
new file mode 100644
index 0000000000..e00f4c2e43
Binary files /dev/null and b/microsite/blog/assets/20-07-01/auth-landing.png differ
diff --git a/microsite/blog/assets/20-07-01/auth-sidebar.png b/microsite/blog/assets/20-07-01/auth-sidebar.png
new file mode 100644
index 0000000000..b089ab6c0a
Binary files /dev/null and b/microsite/blog/assets/20-07-01/auth-sidebar.png differ
diff --git a/microsite/blog/assets/2020-08-05/cards.png b/microsite/blog/assets/2020-08-05/cards.png
new file mode 100644
index 0000000000..4779618b92
Binary files /dev/null and b/microsite/blog/assets/2020-08-05/cards.png differ
diff --git a/microsite/blog/assets/2020-08-05/catalog.png b/microsite/blog/assets/2020-08-05/catalog.png
new file mode 100644
index 0000000000..e9c0c65ade
Binary files /dev/null and b/microsite/blog/assets/2020-08-05/catalog.png differ
diff --git a/microsite/blog/assets/2020-08-05/create-component.png b/microsite/blog/assets/2020-08-05/create-component.png
new file mode 100644
index 0000000000..4d815393fc
Binary files /dev/null and b/microsite/blog/assets/2020-08-05/create-component.png differ
diff --git a/microsite/blog/assets/2020-08-05/feature.mp4 b/microsite/blog/assets/2020-08-05/feature.mp4
new file mode 100644
index 0000000000..a42d9da0e6
Binary files /dev/null and b/microsite/blog/assets/2020-08-05/feature.mp4 differ
diff --git a/microsite/blog/assets/2020-08-05/template-form.png b/microsite/blog/assets/2020-08-05/template-form.png
new file mode 100644
index 0000000000..5805243f59
Binary files /dev/null and b/microsite/blog/assets/2020-08-05/template-form.png differ
diff --git a/microsite/blog/assets/2020-08-05/templates.png b/microsite/blog/assets/2020-08-05/templates.png
new file mode 100644
index 0000000000..e350d463f6
Binary files /dev/null and b/microsite/blog/assets/2020-08-05/templates.png differ
diff --git a/microsite/blog/assets/3/audit-list.png b/microsite/blog/assets/3/audit-list.png
new file mode 100644
index 0000000000..84b64f976a
Binary files /dev/null and b/microsite/blog/assets/3/audit-list.png differ
diff --git a/microsite/blog/assets/3/audit-view.png b/microsite/blog/assets/3/audit-view.png
new file mode 100644
index 0000000000..a2e9716cf4
Binary files /dev/null and b/microsite/blog/assets/3/audit-view.png differ
diff --git a/microsite/blog/assets/3/create-audit.png b/microsite/blog/assets/3/create-audit.png
new file mode 100644
index 0000000000..cb28de73a4
Binary files /dev/null and b/microsite/blog/assets/3/create-audit.png differ
diff --git a/microsite/blog/assets/3/lead-copy.png b/microsite/blog/assets/3/lead-copy.png
new file mode 100644
index 0000000000..fbf247eec8
Binary files /dev/null and b/microsite/blog/assets/3/lead-copy.png differ
diff --git a/microsite/blog/assets/3/lead.png b/microsite/blog/assets/3/lead.png
new file mode 100644
index 0000000000..4b60c4961c
Binary files /dev/null and b/microsite/blog/assets/3/lead.png differ
diff --git a/microsite/blog/assets/4/create-app.png b/microsite/blog/assets/4/create-app.png
new file mode 100644
index 0000000000..52dcc13097
Binary files /dev/null and b/microsite/blog/assets/4/create-app.png differ
diff --git a/microsite/blog/assets/4/welcome.png b/microsite/blog/assets/4/welcome.png
new file mode 100644
index 0000000000..5de0d57098
Binary files /dev/null and b/microsite/blog/assets/4/welcome.png differ
diff --git a/microsite/blog/assets/5/lead.png b/microsite/blog/assets/5/lead.png
new file mode 100644
index 0000000000..657268fc09
Binary files /dev/null and b/microsite/blog/assets/5/lead.png differ
diff --git a/microsite/blog/assets/6/header.png b/microsite/blog/assets/6/header.png
new file mode 100644
index 0000000000..6908e40dbc
Binary files /dev/null and b/microsite/blog/assets/6/header.png differ
diff --git a/microsite/blog/assets/blog_1.png b/microsite/blog/assets/blog_1.png
new file mode 100644
index 0000000000..f8c3516fa7
Binary files /dev/null and b/microsite/blog/assets/blog_1.png differ
diff --git a/microsite/blog/assets/illustration.svg b/microsite/blog/assets/illustration.svg
new file mode 100644
index 0000000000..50e865ed4f
--- /dev/null
+++ b/microsite/blog/assets/illustration.svg
@@ -0,0 +1,104 @@
+
diff --git a/microsite/core/Components.js b/microsite/core/Components.js
new file mode 100644
index 0000000000..49e7d7daca
--- /dev/null
+++ b/microsite/core/Components.js
@@ -0,0 +1,114 @@
+const React = require('react');
+const PropTypes = require('prop-types');
+const simpleComponent = (Component, baseClassName = '', mods = []) => {
+ const SimpleComponent = props => {
+ // Extra BEM modifiers, e.g. `Block__Container--reversed`
+ const modClasses = [];
+ const otherProps = {};
+ for (const prop in props) {
+ if (mods.indexOf(prop) !== -1) {
+ modClasses.push(`${baseClassName}--${prop}`);
+ } else {
+ otherProps[prop] = props[prop];
+ }
+ }
+
+ return (
+
+ );
+ };
+ SimpleComponent.displayName = `SimpleComponent(${Component}, ${baseClassName})`;
+
+ SimpleComponent.propTypes = {};
+ for (const mod of mods) {
+ SimpleComponent.propTypes[mod] = PropTypes.bool;
+ }
+
+ return SimpleComponent;
+};
+
+const Block = simpleComponent('section', 'Block', ['small', 'wrapped']);
+Block.Container = simpleComponent('div', 'Block__Container', [
+ 'reversed',
+ 'wrapped',
+ 'column',
+]);
+Block.TitleBox = simpleComponent('h1', 'Block__TitleBox', ['large', 'story']);
+Block.TextBox = simpleComponent('div', 'Block__TextBox', ['wide', 'small']);
+
+Block.Title = simpleComponent('h1', 'Block__Title', ['half', 'main']);
+Block.Subtitle = simpleComponent('h1', 'Block__Subtitle');
+
+Block.SmallTitle = simpleComponent('h2', 'Block__SmallTitle');
+Block.SmallestTitle = simpleComponent('h3', 'Block__SmallestTitle');
+
+const BulletLine = simpleComponent('div', 'BulletLine');
+
+Block.Paragraph = simpleComponent('p', 'Block__Paragraph');
+Block.LinkButton = simpleComponent('a', 'Block__LinkButton', ['stretch']);
+Block.QuoteContainer = simpleComponent('div', 'Block__QuoteContainer');
+Block.Quote = simpleComponent('p', 'Block__Quote');
+Block.Divider = simpleComponent('p', 'Block__Divider', ['quote']);
+Block.MediaFrame = simpleComponent('div', 'Block__MediaFrame');
+Block.Graphics = ({ padding, children }) => {
+ const style = {};
+ if (padding) {
+ style.padding = `${padding}% 0`;
+ }
+ return (
+
+
+
+ );
+};
+Block.Graphic = props => {
+ /* Coordinates and size are in % of graphics container size, e.g. width={50} is 50% of parent width */
+ const { x = 0, y = 0, width = 0, src, className = '' } = props;
+ const style = Object.assign(
+ { left: `${x}%`, top: `${y}%`, width: `${width}%` },
+ props.style,
+ );
+ return (
+
+ );
+};
+
+Block.Image = props => {
+ /* Coordinates and size are in % of graphics container size, e.g. width={50} is 50% of parent width */
+ return (
+
+ );
+};
+
+const ActionBlock = simpleComponent('section', 'ActionBlock');
+ActionBlock.Title = simpleComponent('h1', 'ActionBlock__Title');
+ActionBlock.Subtitle = simpleComponent('h2', 'ActionBlock__Subtitle');
+ActionBlock.Link = simpleComponent('a', 'ActionBlock__Link');
+
+const Breakpoint = ({ narrow, wide }) => (
+
+
+ );
+ }
+}
+
+GridBlockWithButton.defaultProps = {
+ align: 'left',
+ contents: [],
+ layout: 'twoColumn',
+};
+
+module.exports = GridBlockWithButton;
diff --git a/microsite/data/plugins/api-docs.yaml b/microsite/data/plugins/api-docs.yaml
new file mode 100644
index 0000000000..babcbf74f1
--- /dev/null
+++ b/microsite/data/plugins/api-docs.yaml
@@ -0,0 +1,9 @@
+---
+title: API Docs
+author: SDA SE
+authorUrl: https://sda.se/
+category: Discovery
+description: Components to discover and display API entities as an extension to the catalog plugin.
+documentation: https://github.com/spotify/backstage/blob/master/plugins/api-docs/README.md
+iconUrl: https://thecoders.io/wp-content/uploads/2019/11/tech-swagger.svg
+npmPackageName: '@backstage/plugin-api-docs'
diff --git a/microsite/data/plugins/circleci.yaml b/microsite/data/plugins/circleci.yaml
new file mode 100644
index 0000000000..5f7b4b08e2
--- /dev/null
+++ b/microsite/data/plugins/circleci.yaml
@@ -0,0 +1,12 @@
+---
+title: CircleCI
+author: Spotify
+authorUrl: https://github.com/spotify
+category: CI
+description: Automate your development process with CI hosted in the cloud or on a private server.
+documentation: https://github.com/spotify/backstage/tree/master/plugins/circleci
+iconUrl: https://www.saaves.com/storage/brochure/logo-circleci-icon1583764538.png
+npmPackageName: '@backstage/plugin-circleci'
+tags:
+ - ci
+ - cd
diff --git a/microsite/data/plugins/github-actions.yaml b/microsite/data/plugins/github-actions.yaml
new file mode 100644
index 0000000000..062d0fff61
--- /dev/null
+++ b/microsite/data/plugins/github-actions.yaml
@@ -0,0 +1,13 @@
+---
+title: GitHub Actions
+author: Spotify
+authorUrl: https://github.com/spotify
+category: CI
+description: GitHub Actions makes it easy to automate all your software workflows, now with world-class CI/CD. Build, test, and deploy your code right from GitHub.
+documentation: https://github.com/spotify/backstage/tree/master/plugins/github-actions
+iconUrl: https://avatars2.githubusercontent.com/u/44036562?s=400&v=4
+npmPackageName: '@backstage/plugin-github-actions'
+tags:
+ - ci
+ - cd
+ - github
diff --git a/microsite/data/plugins/github-pull-requests.yaml b/microsite/data/plugins/github-pull-requests.yaml
new file mode 100644
index 0000000000..917198a221
--- /dev/null
+++ b/microsite/data/plugins/github-pull-requests.yaml
@@ -0,0 +1,10 @@
+---
+title: GitHub Pull Requests
+author: roadie.io
+authorUrl: https://roadie.io/
+category: CI
+description: View GitHub pull requests for your service in Backstage.
+documentation: https://roadie.io/backstage/plugins/github-pull-requests
+iconUrl: https://roadie.io/static/7f13bb8d861d8dedc5112fb939d215f9/351f2/GitHub-Mark-Light-120px-plus.png
+npmPackageName: '@roadiehq/backstage-plugin-github-pull-requests'
+
diff --git a/microsite/data/plugins/gitops-cluster.yaml b/microsite/data/plugins/gitops-cluster.yaml
new file mode 100644
index 0000000000..6f8ab6b097
--- /dev/null
+++ b/microsite/data/plugins/gitops-cluster.yaml
@@ -0,0 +1,14 @@
+---
+title: GitOps Clusters
+author: Weaveworks
+authorUrl: https://www.weave.works/
+category: Kubernetes
+description: Create GitOps-managed Kubernetes clusters. Currently, it supports provisioning EKS clusters on GitHub via GitHub Actions.
+documentation: https://github.com/spotify/backstage/tree/master/plugins/gitops-profiles
+iconUrl: https://res-5.cloudinary.com/crunchbase-production/image/upload/c_lpad,h_256,w_256,f_auto,q_auto:eco/v1462316670/i9d3delzvx1erzjhmcws.png
+npmPackageName: '@backstage/plugin-gitops-profiles'
+tags:
+ - kubernetes
+ - gitops
+ - github
+ - eks
diff --git a/microsite/data/plugins/graphiql.yaml b/microsite/data/plugins/graphiql.yaml
new file mode 100644
index 0000000000..6c95d1b175
--- /dev/null
+++ b/microsite/data/plugins/graphiql.yaml
@@ -0,0 +1,14 @@
+---
+title: GraphiQL
+author: Spotify
+authorUrl: https://github.com/spotify
+category: Debugging
+description: Integrates GraphiQL as a tool to browse GraphiQL endpoints inside Backstage.
+documentation: https://github.com/spotify/backstage/tree/master/plugins/lighthouse
+iconUrl: https://upload.wikimedia.org/wikipedia/commons/thumb/1/17/GraphQL_Logo.svg/1024px-GraphQL_Logo.svg.png
+npmPackageName: '@backstage/plugin-graphiql'
+tags:
+ - graphql
+ - github
+ - gitlab
+ - api
diff --git a/microsite/data/plugins/jenkins.yaml b/microsite/data/plugins/jenkins.yaml
new file mode 100644
index 0000000000..78b3616595
--- /dev/null
+++ b/microsite/data/plugins/jenkins.yaml
@@ -0,0 +1,12 @@
+---
+title: Jenkins
+author: '@timja'
+authorUrl: https://github.com/timja
+category: CI
+description: Jenkins offers a simple way to set up a continuous integration and continuous delivery environment.
+documentation: https://github.com/spotify/backstage/tree/master/plugins/jenkins
+iconUrl: https://img.icons8.com/color/1600/jenkins.png
+npmPackageName: '@backstage/plugin-jenkins'
+tags:
+ - ci
+ - cd
diff --git a/microsite/data/plugins/lighthouse.yaml b/microsite/data/plugins/lighthouse.yaml
new file mode 100644
index 0000000000..0819455ed2
--- /dev/null
+++ b/microsite/data/plugins/lighthouse.yaml
@@ -0,0 +1,14 @@
+---
+title: Lighthouse
+author: Spotify
+authorUrl: https://github.com/spotify
+category: Accessibility
+description: Google's Lighthouse tool is a great resource for benchmarking and improving the accessibility, performance, SEO, and best practices of your website.
+documentation: https://github.com/spotify/backstage/tree/master/plugins/lighthouse
+iconUrl: https://seeklogo.com/images/G/google-lighthouse-logo-1C7FA08580-seeklogo.com.png
+npmPackageName: '@backstage/plugin-lighthouse'
+tags:
+ - web
+ - seo
+ - accessibility
+ - performance
diff --git a/microsite/data/plugins/new-relic.yaml b/microsite/data/plugins/new-relic.yaml
new file mode 100644
index 0000000000..e3ddf18652
--- /dev/null
+++ b/microsite/data/plugins/new-relic.yaml
@@ -0,0 +1,14 @@
+---
+title: New Relic
+author: '@timwheelercom'
+authorUrl: https://github.com/timwheelercom
+category: Monitoring
+description: Observability platform built to help engineers create and monitor their software.
+documentation: https://github.com/spotify/backstage/tree/master/plugins/newrelic
+iconUrl: https://www.mulesoft.com/sites/default/files/2018-10/New_relic.png
+npmPackageName: '@backstage/plugin-newrelic'
+tags:
+ - performance
+ - monitoring
+ - errors
+ - alerting
diff --git a/microsite/data/plugins/rollbar.yaml b/microsite/data/plugins/rollbar.yaml
new file mode 100644
index 0000000000..0118fab391
--- /dev/null
+++ b/microsite/data/plugins/rollbar.yaml
@@ -0,0 +1,10 @@
+---
+title: Rollbar
+author: '@andrewthauer'
+authorUrl: https://github.com/andrewthauer
+category: Monitoring
+description: View Rollbar errors for your services in Backstage.
+documentation: https://github.com/spotify/backstage/tree/master/plugins/rollbar
+iconUrl: https://rollbar.com/assets/media/rollbar-mark-color.png
+npmPackageName: '@backstage/plugin-rollbar'
+
diff --git a/microsite/data/plugins/sentry.yaml b/microsite/data/plugins/sentry.yaml
new file mode 100644
index 0000000000..8da488f727
--- /dev/null
+++ b/microsite/data/plugins/sentry.yaml
@@ -0,0 +1,9 @@
+---
+title: Sentry
+author: Spotify
+authorUrl: https://github.com/spotify
+category: Monitoring
+description: View Sentry issues in Backstage.
+documentation: https://github.com/spotify/backstage/tree/master/plugins/sentry
+iconUrl: https://sentry-brand.storage.googleapis.com/sentry-glyph-white.png
+npmPackageName: '@backstage/plugin-sentry'
diff --git a/microsite/data/plugins/tech-radar.yaml b/microsite/data/plugins/tech-radar.yaml
new file mode 100644
index 0000000000..b1d4f5cc17
--- /dev/null
+++ b/microsite/data/plugins/tech-radar.yaml
@@ -0,0 +1,9 @@
+---
+title: Tech Radar
+author: Spotify
+authorUrl: https://github.com/spotify
+category: Discovery
+description: Visualize the your company's official guidelines of different areas of software development.
+documentation: https://github.com/spotify/backstage/tree/master/plugins/tech-radar
+iconUrl: https://www.materialui.co/materialIcons/action/track_changes_white_192x192.png
+npmPackageName: '@backstage/plugin-tech-radar'
diff --git a/microsite/data/plugins/travis-ci.yaml b/microsite/data/plugins/travis-ci.yaml
new file mode 100644
index 0000000000..48c0a4cb86
--- /dev/null
+++ b/microsite/data/plugins/travis-ci.yaml
@@ -0,0 +1,10 @@
+---
+title: Travis CI
+author: roadie.io
+authorUrl: https://roadie.io/
+category: CI
+description: View Travis CI builds for your service in Backstage.
+documentation: https://roadie.io/backstage/plugins/travis-ci
+iconUrl: https://roadie.io/static/af2941eaf0af675facb281d566f42e14/45f2b/travis-ci-mascot-200x200.png
+npmPackageName: '@roadiehq/backstage-plugin-travis-ci'
+
diff --git a/microsite/package.json b/microsite/package.json
new file mode 100644
index 0000000000..ee3c7f8dc2
--- /dev/null
+++ b/microsite/package.json
@@ -0,0 +1,19 @@
+{
+ "version": "0.1.1-alpha.21",
+ "name": "backstage-microsite",
+ "license": "Apache-2.0",
+ "private": true,
+ "scripts": {
+ "examples": "docusaurus-examples",
+ "start": "docusaurus-start",
+ "build": "docusaurus-build",
+ "publish-gh-pages": "docusaurus-publish",
+ "write-translations": "docusaurus-write-translations",
+ "version": "docusaurus-version",
+ "rename-version": "docusaurus-rename-version"
+ },
+ "devDependencies": {
+ "docusaurus": "^2.0.0-alpha.61",
+ "js-yaml": "^3.14.0"
+ }
+}
diff --git a/microsite/pages/en/demos.js b/microsite/pages/en/demos.js
new file mode 100644
index 0000000000..9f9dcec819
--- /dev/null
+++ b/microsite/pages/en/demos.js
@@ -0,0 +1,217 @@
+/**
+ * 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 Background = props => {
+ const { config: siteConfig } = props;
+ const { baseUrl } = siteConfig;
+ return (
+
+
+
+
+ See us in action.
+
+ To illustrate the potential of Backstage, we’re showing you{' '}
+
+ how we use it here at Spotify
+
+ . The videos below feature the custom plugins and templates that
+ we built for our internal version of Backstage. You can use
+ Backstage to build the developer portal you want — integrating the
+ tools that you use in your own infrastructure ecosystem. (Or get
+ started by building an open source plugin for Backstage that
+ everyone can use, like our{' '}
+
+ Lighthouse Plugin
+
+ .)
+
+
+
+
+
+
+
+
+
+
+
+ Introduction to Backstage
+
+ Backstage is an open source platform for building developer
+ portals. We’ve been using our homegrown version at Spotify for
+ years — so it’s already packed with features. (We have over 120
+ internal plugins, built by 60 different teams.) In this live demo
+ recording, Stefan Ålund, product manager for Backstage, tells the
+ origin story of Backstage and gives you a tour of how we use it
+ here at Spotify.
+
+
+ Watch now
+
+
+
+
+
+
+
+
+
+
+
+ Manage your tech health
+
+ Instead of manually updating a spreadsheet, what if you had a
+ beautiful dashboard that could give you an instant, interactive
+ picture of your entire org’s tech stack? That’s how we do it at
+ Spotify. With our Tech Insights plugin for Backstage, anyone at
+ Spotify can see which version of which software anyone else at
+ Spotify is using — and a whole a lot more. From managing
+ migrations to fighting tech entropy, Backstage makes managing our
+ tech health actually kind of pleasant.
+
+
+
+ Watch now
+
+
+
+
+
+
+
+
+
+
+
+ Create a microservice
+
+ You’re a Spotify engineer about to build a new microservice (or
+ any component) using Spring Boot. Where do you start? Search for a
+ quick start guide online? Create an empty repo on GitHub? Copy and
+ paste an old project? Nope. Just go to Backstage, and you’ll be up
+ and running in two minutes — with a “Hello World” app, CI, and
+ documentation all automatically set up and configured in a
+ standardized way.
+
+
+
+ Watch now
+
+
+
+
+
+
+
+
+
+
+
+ Search all your services
+
+ All of Spotify’s services are automatically indexed in Backstage.
+ So our engineers can stop playing detective — no more spamming
+ Slack channels asking if anyone knows who owns a particular
+ service and where you can find its API, only to discover that the
+ owner went on sabbatical three months ago and you have to hunt
+ them down on a mountain in Tibet where they’re on a 12-day silent
+ meditation retreat. At Spotify, anyone can always find anyone
+ else’s service, inspect its APIs, and contact its current owner —
+ all with one search.
+
+
+ Watch now
+
+
+
+
+
+
+
+
+
+
+
+ Manage data pipelines
+
+ We manage a lot of data pipelines (also known as workflows) here
+ at Spotify. So, of course, we made a great workflows plugin for
+ our version of Backstage. All our workflow tools — including a
+ scheduler, log inspector, data lineage graph, and configurable
+ alerts — are integrated into one simple interface.
+
+
+ Watch now
+
+
+
+
+
+
+
+
+ );
+};
+
+module.exports = Background;
diff --git a/microsite/pages/en/docs.js b/microsite/pages/en/docs.js
new file mode 100644
index 0000000000..a8bda18f88
--- /dev/null
+++ b/microsite/pages/en/docs.js
@@ -0,0 +1,12 @@
+const React = require('react');
+const Redirect = require('../../core/Redirect.js');
+
+const siteConfig = require(process.cwd() + '/siteConfig.js');
+
+function Docs() {
+ return (
+
+ );
+}
+
+module.exports = Docs;
diff --git a/microsite/pages/en/index.js b/microsite/pages/en/index.js
new file mode 100644
index 0000000000..7a58ede25f
--- /dev/null
+++ b/microsite/pages/en/index.js
@@ -0,0 +1,480 @@
+/**
+ * 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 ActionBlock = Components.ActionBlock;
+const Breakpoint = Components.Breakpoint;
+const BulletLine = Components.BulletLine;
+
+class Index extends React.Component {
+ render() {
+ const { config: siteConfig } = this.props;
+ const { baseUrl } = siteConfig;
+
+ return (
+
+
+
+
+
+ An open platform for building developer portals
+
+
+ Powered by a centralized service catalog, Backstage restores
+ order to your infrastructure. So your product teams can ship
+ high-quality code quickly — without compromising autonomy.
+
+
+ GitHub
+
+
+
+
+
+
+
+
+
+
+
+
+
+ The Speed Paradox
+
+ 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.
+
+
+
+
+ The Standards Paradox
+
+ 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.
+
+
+
+
+
+
+
+
+ {' '}
+
+
+ Backstage Service Catalog{' '}
+
+ (alpha)
+
+
+
+ Build an ecosystem, not a wilderness
+
+
+
+
+
+ }
+ />
+
+
+
+ Manage all your software, all in one place{' '}
+
+
+ Backstage makes it easy for one team to manage 10 services — and
+ makes it possible for your company to manage thousands of them
+
+
+
+
+ A uniform overview
+
+ Every team can see all the services they own and related
+ resources (deployments, data pipelines, pull request status,
+ etc.)
+
+
+
+
+
+ Metadata on tap
+
+ All that information can be shared with plugins inside Backstage
+ to enable other management features, like resource monitoring
+ and testing
+
+
+
+
+
+ Not just services
+
+ Libraries, websites, ML models — you name it, Backstage knows
+ all about it, including who owns it, dependencies, and more
+
+
+
+
+
+
+ Discoverability & accountability
+
+
+ No more orphan software hiding in the dark corners of your tech
+ stack
+
+
+
+
+
+
+
+
+ Learn more about the service catalog
+
+
+ Read
+
+
+
+
+
+
+
+
+ Backstage Software Templates{' '}
+
+ (alpha)
+
+
+ Standards can set you free
+
+
+
+
+ }
+ />
+
+
+
+ Like automated getting started guides
+
+
+ Using templates, engineers can spin up a new microservice with
+ your organization’s best practices built-in, right from the
+ start
+
+
+
+
+
+ Push-button deployment
+
+ Click a button to create a Spring Boot project with your repo
+ automatically configured on GitHub and your CI already running
+ the first build
+
+
+
+
+
+ Built to your standards
+
+ Go instead of Java? CircleCI instead of Jenkins? Serverless
+ instead of Kubernetes? GCP instead of AWS? Customize your
+ recipes with your best practices baked-in
+
+
+
+
+
+
+ Golden Paths pave the way
+
+
+ When the right way is also the easiest way, engineers get up and
+ running faster — and more safely
+
+
+
+
+
+ }
+ />
+
+
+
+
+
+ Build your own software templates
+
+
+ Contribute
+
+
+
+
+
+
+
+
+
+ Backstage TechDocs (Coming Soon)
+
+ Docs like code
+
+
+
+
+
+
+ }
+ />
+
+
+ Free documentation
+
+ Whenever you use a Backstage Software Template, your project
+ automatically gets a TechDocs site, for free
+
+
+
+
+
+ Easy to write
+
+ With our docs-like-code approach, engineers write their
+ documentation in Markdown files right alongside their code
+
+
+
+
+
+ Easy to maintain
+
+ Updating code? Update your documentation while you’re there —
+ with docs and code in the same place, it becomes a natural part
+ of your workstream
+
+
+
+
+
+ Easy to find and use
+
+ Since all your documentation is in Backstage, finding any
+ TechDoc is just a search query away
+
+
+
+
+
+
+ }
+ />
+
+
+
+
+ Subscribe to our newsletter
+
+ TechDocs is our most used feature at Spotify. Be the first to know
+ when{' '}
+
+ the open source version
+ {' '}
+ ships.
+
+
+ Subscribe
+
+
+
+
+
+
+
+
+ Customize Backstage with plugins
+
+ An app store for your infrastructure
+
+
+
+
+
+ }
+ />
+
+
+ Add functionality
+
+ Want scalable website testing? Add the{' '}
+
+ Lighthouse
+ {' '}
+ plugin. Wondering about recommended frameworks? Add the{' '}
+
+ Tech Radar
+ {' '}
+ plugin.{' '}
+
+
+
+
+
+ BYO Plugins
+
+ If you don’t see the plugin you need, it’s simple to build your
+ own
+
+
+
+
+
+
+ Integrate your own custom tooling
+
+
+ Building internal plugins lets you tailor your version of
+ Backstage to be a perfect fit for your infrastructure
+
+
+
+
+
+
+ Share with the community
+
+
+ Building open source plugins contributes
+ to the entire Backstage ecosystem, which benefits everyone
+
+
+
+ }
+ />
+
+
+
+
+ Build a plugin
+
+ Contribute
+
+
+
+ );
+ }
+}
+
+module.exports = Index;
diff --git a/microsite/pages/en/plugins.js b/microsite/pages/en/plugins.js
new file mode 100644
index 0000000000..0ef8791970
--- /dev/null
+++ b/microsite/pages/en/plugins.js
@@ -0,0 +1,119 @@
+/**
+ * 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 fs = require('fs');
+const yaml = require('js-yaml');
+const React = require('react');
+const Components = require(`${process.cwd()}/core/Components.js`);
+const {
+ Block: { Container },
+ BulletLine,
+} = Components;
+
+const pluginsDirectory = require('path').join(process.cwd(), 'data/plugins');
+const pluginMetadata = fs
+ .readdirSync(pluginsDirectory)
+ .map(file =>
+ yaml.safeLoad(fs.readFileSync(`./data/plugins/${file}`, 'utf8')),
+ );
+const truncate = text =>
+ text.length > 170 ? text.substr(0, 170) + '...' : text;
+
+const addPluginDocsLink = '/docs/plugins/add-to-marketplace';
+const defaultIconUrl = 'img/logo-gradient-on-dark.svg';
+
+const Plugins = () => (
+
+
+
+
Plugin marketplace
+
+ Open source plugins that you can add to your Backstage deployment.
+ Learn how to build a plugin.
+
+ See what plugins are already{' '}
+
+ in progress
+ {' '}
+ and 👍. Missing a plugin for your favorite tool? Please{' '}
+
+ suggest
+ {' '}
+ a new one.
+