DEV Community

Discussion on: How-To: Setup a unit-testable Jenkins shared pipeline library

Collapse
 
prestontim profile image
Tim Preston

This is a great article. My only criticism is that I wish I would have discovered it a couple of months ago before I coded absolutely everything in vars. I'm now in the middle of a massive refactor and it's all your fault. :-)

Collapse
 
kuperadrian profile image
Adrian Kuper

๐Ÿ˜… Thanks for your feedback ๐Ÿ‘

Collapse
 
mcascone profile image
Max

Uh oh, I've done exactly the same thing because i really can't wrap my head around the java package structure, i'm not a java guy; it makes a lot of sense to me to just have everything in /vars as single groovy scripts and call them as steps. How did the refactor go? Was it worth it?

Collapse
 
prestontim profile image
Tim Preston

It was absolutely worth it (for me) because I'm a big proponent of unit testing. It just bugged me to have a huge repository of "untested" code that my whole enterprise is depending on. Our shared library has something like 80% unit test coverage right now (post refactor) and a deployment pipeline that makes sure that it doesn't regress.

Of course, your mileage will vary . I'm certainly not going to judge you if you're comfortable having all of your code in vars.

Thread Thread
 
mcascone profile image
Max • Edited

I agree completely in theory; i was just saying to the bosses today that

yes, [onboarding apps to the shared pipeline] is the priority, but the more apps we onboard, the more critical the robustness and reliability of the pipeline is. The more we are relying on it, the more we need to be able to maintain it without breaking it.

Is there a general pattern that develops when doing a refactor like this?

Whenever I start feeling like I'm some sort of jenkins guru, I come across an article like this that puts me in my place.