Every person who wrote a Jenkins plugin, or a feature included in a plugin or Jenkins core, was trying to let users solve some problem more easily. The trouble is that some of these plugins are old and not so well maintained. Even when they are, every feature your CI/CD system relies on has a not-so-hidden cost: unknown or unaddressed bugs; complex UI with sparse documentation; lack of support for very new or exotic tools or protocols; small user community with little collective knowledge; risk of behavioral changes or regressions during upgrades. Therefore a smart administrator needs to understand the difference not only between critical and nice-to-have- features, but also which behaviors must be implemented in Jenkins as opposed to those which are mere conveniences that could be handled differently. “Building vs. buying” should not be a reflexive choice.
In this talk we will study some Jenkins capabilities from the perspective of whether and how you could get the same effect without them; in other words, the unique value of Jenkins feature code. Can you send mail/chat notifications without a special plugin for that system—and pick the right recipient(s) and message? Can you “check out” an SCM repository into a workspace as part of a Jenkins-neutral build script—or will you be stuck getting tooling, credentials, and changelogs right? When can and should you write Pipeline libraries instead of using a plugin? What is the difference between build “wrappers”, custom “project types”, and custom build “steps” when it comes to using complex tools? Do you need a report plugin tailored to your reporting tool or will a more generic integration serve as well?
Expect to see demonstrations of different approaches to the same problem which illustrate the trade-offs between tighter integration with the Jenkins UI and other features; vs. transparency, flexibility, and self-reliance.
