Skip to main content
DevOps Image

This post is from the XebiaLabs blog and has not been updated since the original publish date.

Last Updated Jul 29, 2015 — DevOps Expert

What’s more important – Process or Tooling?

DevOps

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"]AndrewPhillips (1) Andrew Phillips[/caption] [caption id="attachment_10353" align="alignnone" width="221"]sander Sander Ettema[/caption]  Sander: 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.  

More from the Blog

View more
Jun 10, 2021

Desilo DevOps: The power of bringing all your tools and data into one view

DevOps
When discussing value stream management (VSM), our resources talk a lo ...
Read More
Jun 07, 2021

"How do I get started?" Key steps to improving your end-to-end DevOps process

DevOps
There is an extraordinary variety of DevOps solutions available on the ...
Read More
May 24, 2021

Integrate your DevOps toolchain, simplify your life

DevOps
Organizations can view the entirety of the tools and platforms they us ...
Read More
May 17, 2021

Why Companies in Competitive Industries Adjusted Better During COVID-19

DevOps
As we continue to assess the dramatic effects of the global COVID-19 p ...
Read More
Contact Us