-1

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:

12
  • 1
    ... Note also: questions asking for third party resources (like articles) are off-topic for this site, and questions which ask for pros/cons are prone to be closed as "not focussed enough"
    – Doc Brown
    Aug 29, 2021 at 6:52
  • 1
    ... but as I already wrote in my answer: updating files incrementally or in full is mainly an implementation detail of one step in the process, the steps around stay the same.
    – Doc Brown
    Aug 31, 2021 at 6:12
  • 1
    @ThorbjørnRavnAndersen: when you have tools like rsync available, there is no need to have a justification like "this has been the procedure for a long time". Of course, when you have to implement and maintain your own incremental updater, maybe on top of some ftp protocol, things will look differently.
    – Doc Brown
    Aug 31, 2021 at 10:49
  • 1
    @ThorbjørnRavnAndersen: my point is: based on the information provided in the question, there is no need to to assume the method of "incremental updates" is something only in place for legacy reasons - in the case described of the OP, it is perfectly possible the friend's company has tools and some infrastructure available where incremental updates work as smooth as full updates.
    – Doc Brown
    Aug 31, 2021 at 11:35
  • 1
    @DocBrown yes - there may be many things that have changed over the years. Based on the information in the question we cannot say why they haven't changed. My guess would be sheer inertia, or a boss not wanting to waste time on non-billable hours (or to waste time on billable hours). Not everything has a technical reason. Aug 31, 2021 at 12:08

1 Answer 1

3

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.