The build manager is on life support. Call Gradle for some CPR

Build automation tooling is improving at record speed and a DevOps approach is on the rise throughout the software development arena. Within this whirlwind of advances, it’s easy to focus on products and processes while forgetting about the people, especially the build manager.

In an interview with Hans Dockter, Lead at the Open Source Gradle Project, TheServerSide delved into this often overlooked aspect of successful Continuous Deployment. It turns out, the pivotal role may lie at the point where Dev meets Ops—right in the heart of the build. In fact, the build manager can impact the entire software team on a fundamental level.

Is it possible to tell a build manager’s attitude from their preferred tooling?

Dockter took a trip down memory lane with a look at frameworks dating back to the 1990s. He drew a direct correlation between build manager personalities and the types of tools they like. For example, Hans suggested that XML was perfect for build managers who loved rigidity. It allowed them to anticipate all requirements, at least from their own perspective, and put them in the framework. “They can simply create this framework that tells the world how to do things. It knows what needs to be done and it puts everyone in the same box.” He admitted that such an approach might have worked for small Apache libraries or small open source projects, but it is not feasible for the complexities of enterprise and mobile development.

Next, there is the Apache Maven personality which can seem lazy and indifferent. “We see many organizations where build managers don’t care about the needs of the developers when the goal should be to make the developers productive. They just want stability and simplicity where they can deliver archives to the Ops people. Maven is a wonderful tool for these build managers because it allows them to say, ‘That just isn’t how it works.’ They like the rigidity because they have a wall they can put in front of the needs of the developers. It’s not a good pattern, and not what we need to move forward as an industry.”

Dockter’s outlook on Gradle-friendly build managers is rosier. “The Gradle mindset is not about just scripting the hell out of everything and creating a thousand lines of build scripts. We provide you with opinionated frameworks, but they are the outer layer build scripts. At the heart of Gradle is a toolkit with abstractions that allow you to tell your own story. For example, you can have a free version of software and a paid version, or a debug and a release version, etc. It gives developers the flexibility to express their real requirements. It doesn’t deny the requirements. At the same time, it provides them some structure and rigidity so they aren’t killed by the complexity of a low level build system. That is the Gradle way.”

Implementing Gradle is just one piece of the puzzle

Simply giving a build manager Gradle as a resource isn’t going to change their underlying attitude and make them more flexible. However, it would be unfair to lay the problem solely at the feet of one individual. In reality, organizations are often at fault for treating build management as a second class role and viewing the build as a distraction or an afterthought. For example, developers may be asked to handle the build as a side job when their focus should be on delivering features.

Hans saw such scenarios being played out in many organizations when the build process wasn’t given the respect and dedicated resources it required. “In many cases, build was considered a minor or inferior engineering discipline. The junior people or people with a non-engineering mindset who usually just did scripting were given the job. But with a bigger team, the complexity of the domain of shipping software was as complex as the business domain.”

Things can be done differently if enterprises are willing to make the effort. Dockter pointed to examples of corporations like LinkedIn and Netflix that invest substantially in build management and are enjoying the payoff. These organizations even have a new name for the role, referring to it as DevProd for developer productivity. “They try to hire really smart people. That’s not where they park the so-so engineers. If you looked at LinkedIn a few years ago they were releasing a new version every 30 days. Now, it’s multiple times a day—the whole software stack.”

In the end, Dockter clarified that using Gradle is not enough. The tools have to be backed with a determination to make the build a first class citizen. “We need to make things easier, but it’s never a free lunch. They have to care.” In a modern organization focused on improving productivity, giving the build the respect it deserves is a good start.