Some history, background and information about the building of software at LinkedIn. This presentation was delivered at the Gradle Summit 2013 so it has a Gradle focus, but covers many other types of tooling and integration.
Homogenous -> HeterogenousBuild vs buy, starting taking on more tasks internally. Started open-sourcing our own stuff to pay it forward.
When there are more people who are new than established it’s hard to maintain anything
We needed to scale ourselves. The answer was to establish tools team to focus on internal productivity, code management and process.Performance improvements -> waterfall releases to every 2 weeks to every day to N times per day to continuous dev
If your code doesn’t impact my code then failures in your unit tests should not stop me from releasing my codeProducts move at different paces: experimentation, heavy development, stable and mature, maintenance mode etc.Public APIs at the code and service layers abstracts the messiness underneath.
“out of the box” thinking should make you ask why the heck you were in the box in the first placeAutomation requires trust in the system
But there must be basic sanity checks: our operations team must be able to configure and operate the products at scale, the organization must maintain focus and prioritize, have to consider compliance (legal, government, ethical)There’s constructive and destructive chaos. Multiproduct tries to define constructive chaos.
A product can publish a single or many artifacts
EOL dates solve several problems:I need certain versions to go away because they have bugs or flawsI need to not maintain too many versions. Focus my resources where they matter
Currently a manual step for product owners to promote to production (need more trust in verification to remove this step)
Dependency management probably what we need the build tool to do the mostXML is not a programming language.Groovy DSL has extreme learning curve, but our audience are programmers anyway.
We are able to ask Gradle complex dependency questions and get the answers we need
An example of where we elevate functionality to the product level using the Gradle plug-ins
~5,000 gradle executions per workday. ~10,000 mint executions
We need daemon and parallel execution to make this possible
Already made great progress: both in Gradle and in our plug-ins