Ask HN: DevOps learning resources

The Phoenix Project is a really inspirational novel, good for 'getting' the devops mindset and also as a tool to get other people in your organisation on board.

https://www.amazon.co.uk/Phoenix-Project-DevOps-Helping-Busi...

The DevOps Handbook is a sister book to The Phoenix Project which is more technically oriented around the practicalities of closer integration between Dev and Ops.

https://www.amazon.co.uk/DevOps-Handbook-World-Class-Reliabi...

DevOps is a such a broad term and can mean lot of things. If you are looking for something related to orchestration, I am putting together some Ansible recipes specific to AWS. It is here at https://github.com/gshakir/ansible-recipes

> - a status page (can't give you a decent example; you can build your own, but host it somewhere else than your main "app")

Does statuspage.io have free trial accounts? Integrate with them for your demo/trial using API calls. Bonus points if you pull in applications metrics to your status page (response time, etc).

Where do you live? If you'd like to meet up, I'd be happy to braindump as much as possible on you.

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.