I work at one of the large insurance companies as a DevOps role wherein I convert the various product build processes into a CI pipeline. We use Jenkins (we us

I work at one of the large insurance companies as a DevOps role wherein I convert the various product build processes into a CI pipeline. We use Jenkins (we use all of them, but our department uses Jenkins). Everyone has roughly the same process in general - you store some code in SCM, and then something checks it out, runs various "Quality Gates" (corporate speek for tests), and then you eventually build the product and commit it to some secure artifact repository. You put some logs on there that you're somewhat convinced employees can't modify or delete, and call that an audit trail. Ok, so that said, I would say that for an open source core like Jenkins, the source code is hands down the only documentation you can trust. And that's very, very frustrating at first. Trusting what's in a wiki is the easiest way to burn a day, believing something that was once (possibly) true to still be true. Most interfaces are not documented at all, beyond system generated documentation. A certain class of developers are fine with that, but many of us need a little push up the hill in order to script our way around these ecosystems effectively. After accepting that the source code is the single source of truth, the job got a lot easier (and made me come across as far more of an expert). But it's a difficult sell to get other people interested in sharing this work.