The Challenge of the Polyglot Enterprise
The software landscape is fragmented and specialized and will continue to remain so. Developers have their own beloved tools for development, builds, testing, and so on. Often referred to as a tyranny of choice, this fragmentation is becoming increasingly intentional, especially among the ever-blooming open source development landscape.
Fighting this trend is more often than not a boondoggle for organizations, and ultimately, standardization can even lead to anti-patterns. Realizing this, how can you promote developer productivity in your company if you have the common pattern of a polyglot build system environment? Our own Gradle Enterprise Front End team has implemented both the practice and toolchain, and have seen impressive results:
- 431 builds per week
- 23.46 minutes saved per build
- Serial execution factor: 3.3
- 7.1 wall clock minutes saved per build
- 3,064 minutes saved per week (7.1 minutes x 431 builds)
- 102 days saved/year
Using Gradle Enterprise to Improve the Speed and Reliability of Webpack builds
The team wraps Gradle build scripts around their Webpack-driven CI builds to track the performance in the Gradle Enterprise dashboards, and they use the Gradle Node plugin to wrap Webpack, Jest, ESLint and others.
Beyond the immediate performance gains the team realizes through caching build commands, a great deal of friction has been removed from the debugging and troubleshooting process by using the Gradle Enterprise Build Scan™ service. With a flexible and shareable console log, our engineers can collaborate quickly on failures and significantly reduce their time to resolution.
The Build Failures Analytics dashboard has enabled more effective toolchain failure tracking across front end and back end development teams, allowing them to proactively identify negative trends and correct them quickly. By placing a focused effort in this area, developers do not have to report individual failures, nor do they have to stay vigilant over the build process. That’s taken care of by our own productivity engineers using the aggregated failure data presented in the dashboard, though not all businesses will need to build dedicated productivity engineering teams to realize these benefits.
The Trends & Insights view has helped our productivity engineering team track build performance and how well the cache is working, which is essential in ensuring that performance regressions do not creep back in as the codebase grows. Again, developers do not have to think about this, they can focus on their craft and rely on a speedy and consistent build process.