So we’ve shipped our software. IT’S ALIVE! But DevOps work is never done. In fact, the old Ops part started here, and if there’s any point of having live software in the hands of the customer, this is where we need help. For example, we need to think of are the first seconds, minutes, hours
So we now have tested software, yippee! Which means nothing if we don’t get it to actual customers, so let’s talk about shipping to production. Like everything we discussed until now, automation lowers the risk of manual errors, and saves time. But even deploying to production has to have some kind of method to it.
Last time, we’ve looked at how “regular” development practices have made sure that things worked at the development team level. It’s time to move on. Because, as we know, it’s not working software unless it’s tested. Let me tell you a story, sonny. When I was young, we built the software on my machine. Compiling, testing
This series is about DevOps and how it fits into the agile world. I’ve given this as a workshop at Lean Agile Scotland (slides). Let’s start with what DevOps is. I went to the source of all knowledge, Wikipedia, and the definition goes like this: “A culture, movement or practice that emphasizes the collaboration and communication of both software