Continuous Delivery (CD) is a method of software development in which software teams shorten their development cycles to produce production releases on a more frequent basis.
While more frequent production releases can provide value in many ways (such as a shorter time period between conception and release for new features, as well as fewer bugs making their way into production), it is important to also be aware of the potential pitfalls of releasing new functionality and improvements on an accelerated basis.
One of the biggest potential pitfalls is the alienation of customers due to major interface changes occurring too often, or without warning—not to mention the distinct possibility that a potential improvement to the current product may not be an improvement when made hastily. In this article, we’ll take a look at how to avoid this issue and ensure that CD remains customer-centric.
What is Customer-Centric Continuous Delivery?
Customer-centric CD is a DevOps team’s effort to be mindful of how customers will be affected by the impacts of each production release. This is especially important when an organization employs continuous delivery tactics that lead to more frequent production releases. With focus, a DevOps team can help to mitigate potential backlash against their product and organization when less-than-ideal features or UI changes are pushed into production. Failure to make your continuous delivery pipeline as customer-centric as is reasonable can cost your organization dearly in the long run.
Why is Customer-Centric CD So Important?
Have you ever heard the saying “all publicity is good publicity”? While this saying may hold true in some cases, it does not hold up in the world of software development. Bad publicity with a piece of software can lead to a drop in usage, and the potential ruin of what was once considered a successful project.
Let’s say, for instance, that your product is a website that has maintained the same general look and feel over the past couple of years, and customers seem to be enjoying the product as it stands. But in your next release, major UI changes are made without any warning. These UI changes significantly affect the user experience in ways that you believe are good for the web application, but they are so different that the customer feels as if they are using a completely different product. For the sake of argument, let’s say that a few minor bugs were introduced by the deployment. While this may just be part of the growing pains for your website, the unfamiliar and buggy experience for your customers may lead them to use your product less frequently, or worse, abandon your product. It may even lead to a few critical blogs being written about your organization’s customer focus. This can all have a very negative affect on your product and organization as a whole. Fortunately, making a few small efforts toward mindfulness of the customer experience and employing a few customer-centric best practices can help you avoid these problems altogether.
Putting a “Customer-Centric” Mindset to Use in CD
So how can we make our continuous delivery pipeline as “customer-centric” as possible? The truth is that it is just a matter of putting to use some best practices that may resolve the issue, ensuring that the customers remain happy through frequent production releases. These best practices include the following:
- A/B Testing: A/B Testing can be really useful when it comes to identifying if a change you made to your application is effective and an improvement, or if it is really just a hindrance on the user experience as a whole. A/B Testing is the process by which two versions of an application feature are deployed. A subset of users utilizing the application fall into the bucket with feature version “A” and a subset fall into the bucket with feature version “B.” This gives the development team time to analyze and monitor the user experience for both versions. Consider the case where version “B” is the newly introduced feature, while version “A” is the stable feature from previous releases. If version “B” results in customer pushback and poor performance, the DevOps team can simply revert to version “A,” and only a portion of users were ever exposed to the flawed version “B.” From there, the development team can go back to the drawing board for the feature. On the other hand, if version “B” works as desired and turns out to have a positive effect on user experience, then the organization can go ahead and turn off the A/B test, removing version “A,” and exposing the remainder of the audience to version “B” permanently.
- Opting In: Consider the case where many features are adjusted and a seemingly brand-new interface will be introduced in the next release. One option to consider when deploying these changes is allowing customers to opt-in to using the new interface before forcing them to abandon the older, more stable version of the application. In providing this option, the development team will gain some goodwill with customers by giving them the option to continue using the older version they are comfortable with for a period of time. Concurrently, the team can continuously monitor customer feedback from users willing to try out the new version, and deal with any issues that may arise from its use, such as application performance, or an element customers don’t care for that may have been overlooked by those in charge of the new look and feel of the app.
- Continuous Testing: One big step for any organization that utilizes a continuous delivery pipeline is to make every effort to institute continuous testing as well. Continuous testing is the process of employing automated testing as often as possible throughout any phase in the development cycle where it is reasonable to do so. The benefits of continuous testing are numerous, but simply put, it leads to fewer bugs making their way into production. By continuously testing your application throughout the entire development process, you ensure the release candidate is of high quality. And a high-quality release with few to no bugs is less likely to be subject to customer discontent.
Conclusion
In many cases, continuous delivery does not always mean continuous improvement—and for a development team that releases code frequently, continuously improving the product is the goal. Through the use of the tips mentioned above for deploying new features in a customer-centric fashion, you can take a major leap towards making your continuous delivery pipeline as customer-centric as possible, and ensuring that your application improves with each release.
