Jenkins (when it was still just Hudson) was the forerunner for CI. It made a lot of mistakes but only because nothing else was there at the time to learn from,

Jenkins (when it was still just Hudson) was the forerunner for CI. It made a lot of mistakes but only because nothing else was there at the time to learn from, in my humble opinion. The only alternative in the early days was CruiseControl (which became GoCD) and of the two, Jenkins was far better and more advanced. I made extensive use of Hudson/Jenkins from 2007 to about 2015 and it has flaws, sure, but I know it made some pretty difficult tasks sane for me, and was pretty straightforward building CD pipelines. I didn't (and still don't) like the decision to adopt groovy but it is better than configuring via UI and I like that it is imperative, at least. Some of the jobs I built using Jenkins pretty rapidly include full CD from svn push/git commit to production with all the bells, whistles, gates, and stages in-between, to managing failovers, and even my early foray into IAC with rudimentary remote exec scripts and the likes of chef. I think it became a victim of its own success. It was _flooded_ with contributions that yanked Jenkins in all kinds of directions with no clear owner for direction and maintenance, which lead to frankly some horrific (but "working") architecture within and a jumbled mess of extensions vs plugins vs patches and all kinds of horrific UI changes, often all conflicting. I believe it was Gojko Adzic that wrote up a blog article (that I can't find) about 10 years ago listing some of the truly horrendous code in Jenkins source. Stuff like abstract classes typecasting themselves to derivatives to access members. Looking back Jenkins was and is clunky, messy, uncertain of its purpose in life. But so was just about everything to do with CI at the time. Would I use Jenkins again in 2021 and beyond? Probably not but it definitely added value to the build technosphere.