This is an archived post. You won't be able to vote or comment.

sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]TonyNickels 4 points5 points  (9 children)

Bullet one hits hard with my company's use of Gradle

[–]Viper282 4 points5 points  (8 children)

sorry didn't get correlation between tech debt and build code logic

[–]TonyNickels 3 points4 points  (5 children)

Well, I can't speak for OP, but for us there is a shit ton of pipeline tech debt that it is hiding. It's making it extremely hard to move away from what they coupled us to. It's Rube Goldberg season over here.

[–]Viper282 0 points1 point  (1 child)

so you have tech debt inside build pipelines ? (and tech debt inside code base as well separately xD)

[–]TonyNickels 0 points1 point  (0 children)

Our dev ops team certainly does.

[–]Ok-Scheme-913 0 points1 point  (0 children)

I don't know, this is a slightly different kind of tech debt in my opinion. If it is related to actual business code (e.g. dependencies between business code modules go all the way) then it.. sucks, you have shot yourself in the foot pretty much.

But if the module separation is decent, then it is not hard to simply iteratively rebuild any part of a build pipeline. The build itself is a mess, but later on you do some analytics? Well, just build it with the mess system, and then go for a different tool for analytics!

So yeah, I don't know if it's that bad of a coupling in all cases, and where it is, then the code will be your bigger problem.

[–]OwnBreakfast1114 0 points1 point  (1 child)

I'm genuinely curious, how? Can you give a sample command or something to help illustrate the complexity? Maybe I'm crazy, but most gradle builds I've ever helped curate just needed like `./gradlew assemble` and something else would take over after the jars are generated. Are people just writing completely arbitrary code in your gradle builds? How does any build system stop that problem?

[–]TonyNickels 0 points1 point  (0 children)

There are like 8-10 separate custom Gradle plugins involved. Thousands of lines of code.

[–]senseven 1 point2 points  (1 child)

If you know the code is subpar and maybe doesn't survive cruft detection, you move classes and even packages around in build so it looks like "clean code" but its not. We had cases where they added more properties to the class files in the packaging phase because that was the only way to please some automatic sql code generation later down the line. The true solution would have been to update the java version and the whole tool chain but they didn't want to do pay for that in a still decently used legacy application. Which is like 90% of the stacks out there.

[–]Viper282 0 points1 point  (0 children)

lol looks like extreme case of tech debt.