It’s taken a little while for the software development world to realise what manufacturing industry has known for some time…finding faults and fixing problems at the end is far more expensive than building in quality throughout the process.
According to The Puppet 2016 State of DevOps Report high performing organisations spend 22% less time on unplanned work and re-work. As a result they are able to spend 29% more time on new work, such as new features or code. To give that some context, an IBM Systems Sciences Institute survey calculated that fixing software faults at the testing phase costs 15 times as much as finding them and fixing them during the design phase. That can rise to as much as 100 times more expensive during maintenance, i.e. live running. If you want to see that in real money terms you might want to check out the Sonatype State of the Software Supply Chain Report. Their research highlights that an organisation with a portfolio of 500 applications, focusing resource on remediating 15% of their defective software components, spent $1,800,000 annually that could have been more productively used elsewhere.
In order to eliminate this waste and deliver software applications that work right first time, quality needs to be built in from the start. Rather than having a software testing team that takes delivery of large batches of code late in the development cycle, you need to embed software testers into teams, right at the start of the design and development phase. Small batches of code are tested as you go along and remediated “in-line”. This is known as shifting left and is a key element in delivering the speed and volume of delivery that is seen in DevOps environments.
We’ve talked about application development being like a production line. The best production lines are highly automated. Removing manual functions is absolutely key to delivering the productivity and quality promised by DevOps. Continuous Integration (CI) is the application development equivalent of that production line. CI is an automated process for assembling and testing products. There are a number of CI tools out there. Perhaps the most widely used is the open-source tool Jenkins, commercially supported by CloudBees, that allows organisations to begin automating the whole build and test process.
Another technology that aids shift-left significantly is Containers. By allowing multiple applications and their dependencies to be bundled together and enabling the creation of standardised application environments, more integration and advanced testing routines can be run much earlier in the development lifecycle. Similarly, cloud sandboxing enables developers to create and test complex application and, crucially, infrastructure environments. Traditionally this has been challenging to deliver early in the development cycle, particularly when it has involved hybrid and legacy systems. Furthermore, tools like Jenkins interface to some sandboxes reducing further the need for new automation routines.
As most commentators and analysts have pointed out DevOps is as much an organisational culture shift as a pre-defined process and set of tools. Choosing the right new tools and understanding what of your existing test and development tools can be integrated in to a single continuous integration and delivery production line is important. But we know from experience that ensuring buy-in from the top and managing your team through the process of change, is every bit as important in making a success of the shift to the left.
If you want to keep up-to-date with the latest development in DevOps sign up for our monthly newsletter. All new registrations will receive a copy of the Percipience DevOps white paper. In our next blog we will be looking at how important it is to make security an integral part of continuous delivery.