longpelaexpertise.com.au/ezine/DevOpsTools.php?ezinemode=printfriend

LongEx Mainframe Quarterly - November 2017

opinion: Do We Need All These DevOps Tools?

DevOps is one of the latest big terms in computing, designed to improve software development and deployment. If you believe much of what you read on the internet, DevOps is all about tools. Install the right tools, hit the big, green button, and DevOps is magically up and running. But it's not that simple, is it?

Taking a Step Back

Let's take a step back, and take a realistic look at DevOps. First proposed by Patrick Debois in 2009, I'd summarise it as using two things to improve software development and deployment:
  1. Better collaboration between applications development, testing, operations and others
  2. Adopting an agile-like mindset to both applications and operations

And the basic idea is great. When developers, testers and operations work more closely together, you'll get better code to market faster. So why all the tools?

Tools, Tools, Tools

Well, the fact is that you don't need tools to implement DevOps. There are no standards, or even best practices that dictate that DevOps tools are required. But they sure can help. Let's look at some examples, and how important they are to DevOps.

  • Code: It still amazes me that some sites don't have a source code management (or more correctly, software configuration management or SCM) tool. I think this is essential for anyone developing code: DevOps or not. DevOps is all about collaboration, so multiple people working on the same set of source code must be managed, and this is what SCM is all about. Essential.
  • Software Development: many believe that GUI software development tools are a requirement for DevOps. Although they can aid in software development and improve productivity, they're not a prerequisite for DevOps.
  • Build: DevOps champions the Agile idea of regular, automated builds (even if modules have not changed). This can certainly be done manually, but DevOps tools will make it easier. Many SCM provide features that could be used.
  • Test: Moving on from the regular builds are corresponding regular, automated testing. Again, this testing could be done manually, however tools to perform testing and evaluate outputs for a systems with 1000 modules are certainly useful.
  • Package: SCMs not only look after source code, but are invaluable for other artifacts such as test scripts, JCL, DDL SQL and configuration files. Add staging and release management, and automation.
  • Configure: this is an interesting area: treating configuration parameters in the same way as code. This assists in deployment, and helps control configuration parameters.
  • Collaboration: DevOps is all about collaboration and communication between groups. Today there are many collaboration tools that can help out here, making communication easier – particularly with groups in different geographical locations or countries. Useful.
  • Monitoring: Continuous monitoring is a key aspect of DevOps.

So Are These Tools Really Needed?

The reality is that most sites I work on have all the tools they need to start implementing DevOps. They have SCM software for source code that could easily be expanded to other artefacts if they're not already doing so. This SCM software can often be used for automating builds, or at the last form the basis of such automation.

They have email, chat, telephones and shared folders/libraries for collaboration and communication. They have monitoring tools that can be configured to automatically alert when key indicators go outside of pre-defined values or errors and abends occur. Sure, there are some excellent tools out there, but I'm not convinced they're a requirement to get DevOps benefit.

I think that the single biggest benefit that DevOps provides is collaboration and communications. Getting different groups such as database, operations and security into the project from the beginning, rather than at the end. Breaking down the barriers and weakening silos. And the benefits of this are not just in development: application support and problem determination also win. To achieve this, a change in workplace culture and thinking is needed. This in turn requires strong management buy-in. No additional tools required.


David Stephens