We recently had the fortune of conducting a webinar – “How one of the 15th safest banks in the world out-competes the tech disruptors” -- with our customer Rabobank, a leading financial services company.Sander Ettema, Manager, Linux Infrastructure Services at Rabobank and Andrew Phillips, our VP of Products, discussed how Rabobank transformed its software delivery by implementing Agile development, Continuous Integration and Continuous Delivery. Listen to the entire webinar here: "Continuous Delivery and DevOps at Rabobank" At the end we fielded questions from the audience. Here's what we learned...
Q: To succeed in Agile Development, Continuous Integration and Continuous Delivery, what is more important -- process/culture or tooling?
[caption id="attachment_9116" align="alignright" width="220"]
[caption id="attachment_10353" align="alignnone" width="221"]
: Rabobank has leveraged Continuous Delivery for DevOps -- a process that is transparent, whereby infrastructure is fixed and thus developing/building/testing code can be repeatable -- so that Rabobank can create, try and test quickly new applications to meet the banking customer’s demand for more online banking capabilities.
If the process is always the same – fixed – you can focus your attention on the code. Everything is built in the code, and there are virtually no manual processes. Via this dynamic, you can deploy the code in one environment, and you can try it in others. By having repeatable infrastructure, we achieve repeatable application development and deployment. The code can be transported quickly through the pipeline from development to production – a nice flow.
In this process we gain knowledge. It gives us transparency into where the code works, doesn’t work, performs or doesn’t perform how we expect. We have vision into the code and we use this vision to learn – not blame. Because we have this feedback early on in the code development and build processes, we can quickly learn and go back and re-create without feeling like we need to blame anyone for creating a code that doesn’t perform as expected. We can afford to learn because we have repeatable infrastructure and much is automated to move things from code to build to production -- quickly.Andrew
: Before, when manual processes ruled the day, going from code dev to build to production would take much longer. Thus when something might go wrong it might be discovered after much time had transpired, and thus re-creating the code or developing fixes would involve more pressure, more cost. When you have a flow in which you have time to learn – time to make mistakes and correct them – the pressure of the “we’ve got to find someone to blame and fire someone” dynamic no longer exists.
With Agile Development, Continuous Integration and Continuous Delivery, you can afford to develop code, build it, test it and learn in the process and be all the better as a result.