Releasing the common component library
This is part 2 of the blog series “Driving consistency across Druva UIs: Building a common component library”. In part 1, we discussed the process engineering went through to identify the common components within the product, and choose a common component library. Once a common component library was selected, we modified processes to adapt to utilizing the components selected. Engineering processes for testing, release management, distribution, versioning and documentation were all updated for more streamlined and efficient development.
Unit testing to ensure quality
Since the components in the component library are modular and self sufficient, we focused on unit testing our components thoroughly by using Enzyme with Jest. Jest is bundled with the create-react-library boiler-plate, which was used to start up the development of the common library. It provides a good assertion library and mocking framework, so it was an obvious choice for us. The integration testing is left to the products when they use the components in their UI.
In order to maintain strict quality control and ensure that there is no regression, no code changes could be merged unless a CI pipeline build/test (which checks linting rules and unit test failures) was executed successfully.
Evolution of the release process
Phase 1: Release on demand
In the initial stages of the library, we selected one product as the consumer for the library. This helped the library engineers validate whether the component contracts were satisfying the products’ requirements. Initially, the product team was wary of using the common component library. The team thought that the number of components needed would be very large and using a common component library would add another dependency to their development, which could delay the product delivery timelines.
To mitigate these concerns, the plan was to pick a specific feature or page within the product for adopting the library as a starting point. The UX team identified the components (table, select box, text boxes etc.) required for this feature and spent time with the product team to help them understand the impact of this change. An engineer from that product team was also part of the team that built the common components. To further support the product adoption and ensure that product timelines were not affected, we instituted a process of releasing the library on demand.
Once the decision was made to adopt the library for the feature, the product team estimated that moving to the common component library would delay the delivery of the feature by 2-3 weeks. However, once they started using the library, they realized that rather than delaying the delivery, the feature would be delivered faster than expected.
This convinced the product team that the library was the way to go forward. The strategy that they followed was to prioritize features and migrate these page by page to use the common component library. Since this worked so well, it also helped convince other product teams of the benefits of using the common component library.
Phase 2: Release fortnightly
Once the library was well established and stable enough to be opened up to other products, we moved away from on demand releases and implemented a fortnightly release schedule and formalized the library development process as follows:
- Product teams open a ticket (JIRA) for any feature/bug fix required in the component library.
- At the start of the fortnight, representatives from the product teams would meet with the library team and UX representatives to prioritise and finalize the tickets to be delivered in the release.
- At the end of the fortnight, the library team releases the latest version of the library with the committed fixes.
Phase 3: Agile Scrum
Reviewing the process above, the next obvious step was to move towards an Agile process. As Druva was adopting Agile across the company, this was a no-brainer. We followed the Scrum model for our Agile process with product requirements going into the backlog, fortnightly releases became Sprints, with stakeholders from products invited to the Sprint planning meetings.
Fig 2: Release process
Adoption of the library
How to migrate older products
Druva’s products are well established, and continue to evolve with new features being added continuously. The priority for the engineers on the product teams rightly focused on new customer facing features, bug fixes and supporting customers. However, engineering management realized the value of moving to the common library to streamline their development efforts, and led their teams to create a phased plan for adopting the new component library.
Some products were not yet using React, which required the applications to work in mixed mode, with parts of their application using Jquery while other parts used React with common components. (We’ll cover how this was achieved in a future blog)
The User Experience (UX) team played a very important role in the adoption of the common library components. For any new feature, the UX team would only use components from the component library in the feature mock-ups. This made it very easy for product teams to identify and use the components from the component library. If a feature required a component that was not part of the library, the UX team would evaluate if the required component could be used across products. If yes, then the UX team would create a ticket in JIRA with detailed specifications for the component so that it could be included in an upcoming library release. This process ensured that the component library was fully integrated into the feature development process, and helped drive consistency across all the UIs.
Distribution and Versioning
Initially, the product teams would use the Git url in the dependencies to get the latest version of the library for their builds. This was replaced with a private NPM registry (Verdaccio) so that we did not have to provide access to our Git repo to all consumers of the library, and improved our internal security.
Version control methodology was an easy decision for us, as we followed the industry standard to use semantic versioning when releasing the component library.
We developed our own in-house documentation application for the component library. This not only provides documentation but is also a sandbox for testing our components. This in-house application is actually an app that is developed using the components from the common component library.
Fig 3: Documentation application
Success in reducing time to build UI applications and features
The common component library has been successfully implemented across four products within Druva. While some of the older products continue the process of migrating to the common component library, any new product uses the components from the library. This has significantly reduced the time taken to build UI applications and features within Druva products. Consistency across UIs has increased because the components from the common component library are used across multiple products.
While the common component library is maintained by our team, its success was not possible without the support of key teams at Druva – the User Experience team who conceptualise and define the components, the engineering teams across Druva who use the components, and the management team who have supported and adopted the library within their respective products. It is this cross-team collaboration and contribution that really makes this library a “common” component library.
- Driving consistency across Druva UIs: Building a common component library Part 1 (link to blog published – 1st part of this google doc)
- How the front-end architecture at Druva has not only helped create a fast and responsive UI, but also helped in adopting modern design principles, covered in this blog Say Hello, A Refresh to Your Druva UI Experience Part 1 and Part 2
- Learn more about how the common component design impacts the end-user experience as part of the new UI for legal hold