The pros and cons of incremental update/deployment on granularity of *files* (not on *services*)

Question

My friends' company is using the incremental method to update/deploy a new version of their app to the customer site. But what kind of surprises me is their update/deployment is on granularity of files, not the services.

For example, suppose the finally built app in version 1 consists of two files A and B:

web_app (version 1):
- file A
- file B1

They will deploy all the files to the customer site. When the version 2 is built and the file B is modified:

web_app (version 2):
- file A
- file B2

They will only send and deploy file B2 to the customer site. If version 3 has file B2 deleted and file C added:

web_app (version 3):
- file A
- file C

They will also delete file B2 on the customer site and deploy C there. Because file A has never changed during the three versions, it is not touched in the second and the third deployments.

I haven't learned exactly why they are doing this way. I asked, but they haven't responded yet. But their way of deployment is so different from what I have seen around in the industry. Maybe they have some special reasons so they must do it this way.

So I did some search and wanted to find articles/information to discuss the pros and cons of this deployment. However, when I tried to use keywords such as "incremental deployment" to search, most of the articles are about incremental deployment on granularity of services (see [1][2][3][4]), not on files. I did find the article Incremental deployment vs full deployment, but I'm also wondering if there is any other literature that discusses this topic further in depth in the history of software engineering.

A second question is: Are there valid scenarios that such incremental deployment is indeed a good choice?

References:

• [1] Six Strategies for Application Deployment
• [2] Best Application Deployment Strategies in 2021
• [3] Intro to Deployment Strategies: Blue-Green, Canary, and More
• [4] Red Hat OpenShift: Deployment Strategies

Answer 1

The four articles you mentioned talk about deploying new versions of services "as a whole" because services must obviously be updated completely - or not - with all their files, otherwise they won't work any more. However, if such a deployment uses incremental / differential file updates "under the hood", or if the existing files are deleted and replaced by a fresh copy is simply an "implementation detail" - this is quite irrelevant in the context of those articles, it should finally just end up in the same result: either a new version of the service runs after the process, or the old version is still in place in case the update fails.

So what are the benefits of incremental file updates, and what the drawbacks? A service in one version usually consists of several files which must all match a certain revision. Updating the files of such a service incrementally

1. has the major benefit that it (usually) saves network traffic, especially when only a few files in a larger set has changed,

2. has the major drawback that it is more complex and introduces a certain risk of the "destination" not fully matching the "source" after an update operation.

To make incremental updates work reliably, one needs a robust method of determining which file revisions are already on the destination side, and compare it to the revisions on the source side. Note this method must not cause even more network traffic than the amount of traffic one wants to save, so transferring all of the data from the destination to the source side first for comparison purposes is usually not an option (except for the cases where the network speed is very asymmetric for uploads vs downloads).

Hence, to make incremental updates work efficiently, one can take attributes like time stamps, file sizes, or hash values of the files into account (and that is where the risk of overlooking necessary file updates comes in). A well-known program (and protocol) which works this way and is widely used for file-based incremental updates is rsync (it actually goes a step further and can update single files incrementally, by transferring only changed parts of the file). However, rsync is not available on every network and web server, and it has certain requirements for the file system time stamps.

Hence, before deciding for incremental updates, one should always check if the extra complexity is really worth the hassle. Ultimately, this depends on the frequency of the updates, the size of the files involved, the speed of the network, the traffic costs and the tools available. For example, when you are going to send updates to multiple mobile phones where networks may be slow and costly, incremental updates will obviously pay off way sooner than on the high-speed local intranet of your company. The typical way to make a decision here is start with the simpler approach (full updates) first, and when it turns out not to be sufficient, switch to a more sophisticated incremental approach.