Slack’s Developer Experience (DevXP) team recently implemented significant optimizations to their end-to-end (E2E) testing pipeline, claiming a 60% reduction in frontend build frequency and a 50% decrease in overall build time. These enhancements, the team claims, streamline the continuous integration and deployment (CI/CD) process, allowing engineers to iterate more rapidly and efficiently.
Explaining how it works in a recent blog post, Slack’s existing repository (monorepo) employs a CI/CD pipeline that runs E2E tests before merging code into the main branch. This newly introduced process ensures that changes are validated across the entire application stack, including the frontend, backend, and database. However, the DevXP team observed that frontend builds were occurring even when no frontend-related changes were made, leading to long build times and resource consumption. Each build took approximately 10 minutes, with the frontend build consuming about 5 minutes of that time. Given the high volume of pull requests (PRs) merged daily, these redundant builds accumulated significant time and storage costs.
To address this inefficiency, the team introduced a conditional frontend build mechanism. Using git diff with the three-dot notation, they could detect whether a PR included frontend changes compared to the main branch. If no frontend changes were detected, the build process would skip the frontend build step and instead reuse a prebuilt version. These prebuilt assets were stored in AWS S3 and served via an internal Content Delivery Network (CDN), ensuring that tests ran against current assets without needing a new build.
According to the team, implementing this strategy at scale presented challenges, such as identifying frontend changes within a repository containing over 100,000 tracked files. The team leveraged Git’s capabilities to perform this check in just a couple of seconds. Additionally, by adopting S3 storage concepts and coherent file naming conventions, the team could locate suitable prebuilt assets in under three seconds on average amongst their large number of software assets..
The newly optimized end-to-end pipeline led to improvements in Slack’s development workflow. Most notably, the team claimed a 60% reduction in frontend build frequency, significantly cutting down on unnecessary builds that previously consumed valuable CI resources. This change alone reduced time and infrastructure load associated with merging pull requests that didn’t impact the frontend code. In addition, the overall build time saw a 50% decrease. Together, these gains contributed to a more efficient and responsive engineering process that not only enhanced developer productivity but also reduced storage costs and resource utilization.
