[deng]

Well, that's Jenkins in a nutshell. You usually need to extend Jenkins with lots of plugins because they provide functionality that should have been in core in the first place. Then you realize that those plugins are not properly sandboxed and often do not work well together (especially with multi-configuration builds), not to speak of how updating Jenkins becomes a nightmare with plugins breaking left and right because of some internal API changes which are not yet properly handled by some plugin.

[jacques_chester]

In fairness, Jenkins did not have the benefit of hindsight. Plugins were the this-is-how-you-support-extension architectural style of the period (see also Wordpress, Eclipse).

I've been working on a Concourse tutorial video series. One of the points I've made is that plugins are unsafe to compose. They need to know too much about each other to prevent interference.

Concourse instead composes on resources, which all have an identical interface (check, get, put). You can pretty much use any resource with any other resource if they achieve your purpose.

We're still calling Concourse "CI/CD", but folk are now jokingly referring to "Continuous Everything" at Pivotal. Because it really is becoming the first tool for everything. We're running large automatic tooling with small teams, because it's easy to extend and relatively easy to rearrange.

Disclosure: I work for Pivotal, which sponsors Concourse development.

[dserodio]

I'd love to see -- or even better, read :) -- about how you "compose on resources".