A real case with Angular and Storybook!
One of the most important projects that I have been following in recent years concerns the development of Aulos, a modular framework used in many Loccioni projects.
In this fundamental project for Loccioni’s software teams, I mainly deal with the development of the web-based frontend based on Angular and on the implementations of continuous integration and deploy pipelines.
Storybook in Aulos build pipelines
For more than a year, our team has introduced the Storybook library in Aulos in order to have a valid tool for sharing our components and documentation with all Loccioni’s software teams.
In particular, in this article, we will not focus on how we implemented the integration of Angular and Storybook (we are using MDX story format) but on how we made use of a new feature introduced by Teamcity in the 2020.1 version to speed up our build pipeline: conditional build steps.
As we know Storybook can generate a static version of its work to be enjoyed by all the collaborators of the project, in particular project managers and UX designers. The CLI command that does the static generation is:
build-storybook in the Aulos project and, unfortunately, this particular build step consumes more than 20% of the total build time.
The result of this step, in our specific case, produces an artifact that is consumed by a second build (we use build chain TeamCity feature) which has the responsibility to build and publish a new version of a Docker image containing the static Storybook site on our private Docker registry.
With this configuration of our builds (base on the composition of multiple build chains), our build flow is really simple and immediate, especially to those who enter the project for the first time. The only real problem we are experiencing is the build time increased to each commit of the main build configuration (Aulos Build) due to the static Storybook generation.
How did we take advantage of TeamCity's conditional builds?
First of all our team has determined that we don’t need a new storybook version with every Aulos Build. Consider that we run approximately 10 to 30 builds a day of the Aulos project to be able to perform more than a thousand tests (4 build agents, Windows, and Linux).
It is inconvenient and useless to produce a new version of the static Storybook site with each build.
We, therefore, thought of introducing a condition in the Storybook build step to be able to control when to build the website static or not.
We have simply introduced a boolean parameter called
BuildStoryBook in step configuration so that we are now able to control whether or not the build step is enabled.
Thanks to this new parameter we can easily control each build run launched manually:
But at this point, how to correctly link the generation builds and the deploy build easily?
Ps: please remember that the main build produces an artifact (Storybook static web) that is necessary for the second build configuration to build and publish the docker image.
After careful research in the TeamCity documentation, we found that a child build can control the value of a parent build parameter. That feature on TeamCity is called: Overriding Dependencies Properties.
Thanks to this configuration we have ensured the presence of the artifact (Storybook static web), produced by the main build, every time the child build (Storybook deploy) is launched (automatically or manually).
With these simple steps and configurations, every time the Product Manager or a UX Designer asks us to have the updated version of the component preview we just have to press the deploy button!
Easy, simple, and maintainable!
Please, Subscribe and Clap! Grazie!