“Non-contributing zero.” That’s how Louis C.K. referred to the guy next to him on the airplane who griped about the Wi-Fi going out only two minutes after he found out the plane even HAD Wi-Fi.
It’s funny and it’s sad and it’s true. Customers expect awesome things all the time and right away, and it doesn’t take long for the awesome to become commonplace.
That’s why now more than ever, the ability to turn an idea into working software in short order is your competitive advantage. Even when you’re way ahead of the competition, faster time to delivery on software projects means you capitalize more quickly on market trends, customer desires and even fix security issues faster.
Imagine if you could innovate and deliver software to your customers in weeks rather than months. Now, imagine if your competition could, and you couldn’t?
Companies that are taking on the challenge of moving to a Continuous Delivery model are finding it easier than ever before to deliver innovation and value quickly, but Continuous Delivery is neither the end, nor the beginning of the journey.
What is Continuous Delivery?
The term continuous delivery refers to a set of practices that make it possible to rapidly, reliably and repeatedly release software to customers with low risk and with minimal manual intervention. These practices include automated regression testing, automated build integration, configuration management and continuous deployment.
Companies that seek to implement Continuous Delivery will have some significant obstacles to overcome in the process. In fact, they are the very reason you need Continuous Delivery. Obstacles like long, complicated testing and release processes, low code-confidence and tightly coupled architectures all work together to perpetuate longer-than-necessary software delivery cycles.
In many organizations, releasing software to production is a big, monthly event that is the culmination of weeks of planning, meetings and coordination. Because there are so many integration points and so much that can go wrong, every precaution is taken to make sure that the software to be deployed not only works, but that it won’t break something else that was already working. These can be long, stressful days of error-prone, manual processes even when nothing goes wrong.
Continuous Delivery, on the other hand, makes releases to production much easier, faster and less risky because you’ve automated nearly everything about your build, testing and deployment processes. The repeatability that this automation provides helps to ensure that new code works, existing code still works, environments are configured correctly and that your applications and services still play well together.
This is possible because with a good Continuous Integration and Configuration Management system in place, every time a developer checks code in to source control, that code is verified against a suite of new and existing automated tests. You’ll know within minutes (not days) if the code would have not worked in production.
However, any Continuous Integration system will be only as valuable as your automated tests are well-written and adequately exercise the right areas of your code. The right combination of different types of automated (and manual) tests is fundamental to the success of Continuous Delivery. But how do you ensure your automated regression tests are reliable enough?
This is where Test-Driven Development (TDD) enters the picture. TDD is the software development practice in which developers write automated tests before writing any production code. Although the practice has been around for over a decade, it is still the focus of much confusion and debate. However, when done properly, the many benefits of TDD pay off. One of those benefits is a reliable set of automated regression tests…another important step on the path to Continuous Delivery.
Getting your projects on the path to Continuous Delivery is not a quick fix. It requires a commitment to incremental improvements to your project life cycle management, developers’ skills, cross departmental communication and organizational culture. Thankfully, these challenges have been met and overcome time and again. The solutions engineers at AIM Consulting have the skill and experience it takes to get your organization “continuously delivering” innovative and valuable software solutions to your customers, so you’ll never be accused of being a zero.