Mobile apps @ Backstage
We recently started adopting Backstage within our company to have a modern service catalog for all our software components within the SDA SE ecosystem. (The whole story around the Backstage adoption is probably worth its own article — hopefully coming soon.)
When thinking about integrating our mobile apps into the service catalog it was not straight forward since the focus of the plugins and structure orientated a bit more in the direction of (backend) services. (I have to admit though that this impression might be somewhat subjective.)
When looking at our monorepo there were two kinds of main artefacts: apps & libs. Libs easily match to the component type “library” but for apps it is a bit more complicated. At the end, the closest match was a component of the type “website”. Another problem was related to our monorepo structure. While every lib and app can contain a link to the latest build, release and health status, this approach becomes somewhat redundant in a monorepo since we don’t have isolated builds, for e.g. each lib. So overall, our components fitted into the catalog structure but there is some room for improvement in the context of mobile apps with multiple libs hosted in a monorepo. If you are interested in this topic the following thread might be worth looking at.
While the Backstage plugin list is growing, a plugin for our mobile CI (Bitrise) was missing. If the catalog should be the go-to-place for developers & testers we need some way to access the CI builds and download the build artefacts to work with them. After doing a series of interviews with potential users within the SDA, we started with a first mockup. Using the provided Figma file for the Backstage design system it was quite fun to build the prototype. (The storybook instance is also worth a look.)
Based on this prototype, we started with a first MVP providing the possibility to view, search and filter builds. In addition, the user is able to download the created artefacts. To facilitate development and get an impression if it proves to be useful during daily work, we deployed it in our internal instance first. The biggest obstacle during the development was the fact that most table filters/searches are only executed for the data already shown in the table while we wanted to execute these tasks against the server API.
After a successful beta phase in our service catalog, we opened up the PR to contribute the plugin to the catalog. While the amount of CI checks can drive you nuts when submitting a larger amount of code the PR process was quite smooth and a couple of days later the bitrise plugin was published. We hope it will be useful for others and would be interested in feedback about missing features or other improvements!
