The latest News and Information on DevOps, CI/CD, Automation and related technologies.
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.
