This final article in the “Succeeding with Backstage” series focuses on how you can incorporate Backstage as part of a broader developer productivity engineering (DPE) initiative. The previous parts dealt with customizing the look and feel of Backstage, creating and maintaining custom plugins, and improving Backstage adoption.

This third installment of the “Succeeding with Backstage” series explores how you can improve the adoption of Backstage within your organization. The previous two parts dealt with customizing the look and feel of Backstage and creating and maintaining custom plugins.

Until fairly recently, software releases happened once or twice a year, maybe once a quarter. This gave IT teams plenty of time to verify and manually sign off on every change before they were released in big batches during a bank holiday weekend or off-peak hours. Typically, they’d produce paperwork to show that all changes had been properly tested, and then those changes would be approved for release in a change advisory board meeting (CAB).

This is the first article in the “Succeeding with Backstage” series. This series is for those with a working Backstage implementation who want to ensure smooth adoption and ongoing successful use of the tool. If you’re still trying to decide if Backstage is for you, you can check out the first article in the “Evaluating Backstage” series.

This second installment of the “Succeeding with Backstage” explains how to create a custom Backstage plugin. For many use cases, customizing the platform’s look using the methods from the last part and integrating existing plugins will be enough to align Backstage with your organization’s needs. But what happens when the plugin directory doesn’t have a plugin that solves your particular problem? You create a custom plugin, of course.

This third part of the “Implementing Backstage” series explains how to integrate Backstage with existing tools and plugins. If you’re at an earlier stage of your Backstage implementation, the two previous installments in this series focus on getting started and using the core features. If you’re looking for a more general introduction to Backstage, you can read the first article in the “Evaluating Backstage” series.

The fast-paced nature of modern software development means developers are capable of deploying changes to production multiple times a day. But, while DevOps allows development teams to deliver new features faster, increased deployment frequency can make it more difficult to stay on top of security threats. It only takes one malicious or incompetent change to dramatically increase the risk exposure of an application.

This final part of the “Implementing Backstage” series focuses on how to deploy Backstage on Kubernetes. This tutorial is a direct continuation of Using the Kubernetes Plugin in Backstage, which you should complete before tackling this one. The other installments in this series covered getting started, using the core features, integrating with existing tools using plugins, and security and compliance.

This second last part of the “Implementing Backstage” series explains how to use the Kubernetes plugin in Backstage using real-world scenarios. The previous installments covered getting started, using the core features, integrating with existing tools using plugins, and security and compliance. If you’re entirely new to Backstage and want to learn more, you can read the first entry in the “Evaluating Backstage” series.

This is the fourth part of the “Implementing Backstage” series and explores how to ensure your Backstage application is secure and how Backstage can contribute to more secure practices in general. The previous installments focused on how to get started, using the core features, and integrating with existing tools using plugins. If you’re unfamiliar with Backstage and need an introduction, check out part one of the “Evaluating Backstage” series.