Delivering Updates with the Least Amount of Effort: A View from the Inside

Be it a major functionality release within a product’s core evolution or a security issue fix, frequent delivery of updates to all corporate clients is fraught with risks and almost implausible without continuous delivery tools and proper mindset. My goal for this article is to share some best practices for establishing effective updates during the delivery process on an as-needed basis with as little pain as possible.

Not a Mass Market Story

Let’s take a look at a real world example. Consider a situation where we have an industry-specific, large-scale data processing product delivering market analytics. The platform is modified to a varying extent for each particular corporate client – more than 15 of them in all.

The development team extends the application core, and customizes data presentation and connection to specific data sources for each particular client. The scope of their tasks is further complicated by new feature requests every 1-3 months, support for the older versions, elimination of defects, and issues and risks popping up in the production environment. Schematically, things look as follows:

Development and updates delivery process

An important clarification in this respect: the development team should consist of five people at most. Just five people in charge of development of the new functionality of the system’s core, custom-tailored functionality as per specific clients’ requests and marrying together the core and custom platform parts. Impossible? Not necessarily. 

How it Works

To ship working software to production at any point, proper process establishment is everything. Therefore, the team should take an iterative approach to development and operations based on version control and deployment automation. The principle process establishment highlights are:

• Having one feature released at a time makes detection of the problem source much quicker and the decision over either to roll back or not much easier;
• The release pipeline is fairly flexible, and the overall release delivery strategy dwells on the product evolution planning. A new feature/functionality request every 1-3 months initiates a re-usable iterative process of one-week sprints to deliver a new patch of updates;  
• Team effort allocation is organized as follows: two software developers are tasked with the software product core evolution and two developers customize the product for specific clients, while a build integrator is appointed to deploy the software builds to the pre-production server;
• A quality assurance team comes into play to test the software as soon as automatic unit tests and integration tests have been run;
• As soon as the updates are proven ready for delivery, the final updates patch is made available for customers to download on an as-needed basis, with proactive customization of the tailored solution functionality that is affected in one way or another by the new update release.

Not by Automation Alone…

Automation of build, test and deployment processes can really work wonders, enabling the deployment of code more frequently with fewer failures. Deployment automation eliminates susceptibility to human error. Ironically, success lies not only with taking people out of the process, but also with engaging more people and creating a culture of shared responsibility needed to prevent low-quality releases.

In this respect, customers have a role to play, too. In an ideal world, the testing environment mimics the production environment in every slightest respect. But in real world, the pre-production environment can never recreate every scenario that can go wrong.  The surest way to prove software is ready for production is to deploy it into production right away. An interim (or beta) release is delivered to the customers who realize it is fraught with possible, unchecked glitches or usability inconsistencies. Such people are innovators by nature; they volunteer to beta-test the newly developed functionality and to report on the possible glitches and deal with them. As soon as you detect the avant-garde tier among your customers, make sure to automate notifications to beta users when a new release is ready, and incorporate tools enabling them to send feedback with a click of the button.  

Author’s Bio

Sergey Sinkevich is a senior developer with Itransition. Having taken part in a dozen projects in this position, Sergey specializes in Web Applications Development with Microsoft .NET (News - Alert) Framework 4. Sergey graduated from the Belarusian State University of Informatics and Radioelectronics in 2009 with a specialist degree in Radiophysics and Computer Science.