[sdc-support]

Creating Delta Packs

Optimized Delivery of New Software Versions Via SDC

Abstract
Delta packs allow you to efficiently ship bug fixes and small feature releases of your software without shipping the entire pack. The mechanism requires that users have a base version of your pack installed. Validation of pack installs uses the normal pack dependency mechanism, guaranteeing that your users get the correct version of your software.

Target Uses for Delta Packs
Delta packs are best applied when large sections of your code base remains constant and you release changes or additions to a few bundles. This is usually the case for bug fix releases and new feature additions which do not require rebuilding your base software.

The technology looks for bundles that have changed, so it is best if you can assemble your application using older versions of bundles that you do not need to change.

Building Delta Packs
To build a delta pack you need a base version of your pack, a new build of your software, and a small modification to your pack.build.xml file.

Modifying Your Pack Build File
Enabling delta pack builds is as simple as adding a <buildDeltaAgainstPackUsingLinuxInstaller> element as a child of your main <packBuild> element. This element must contain the path to the linux installer of the base version of your pack. For example:

<buildDeltaAgainstPackUsingLinuxInstaller>/mnt/pack-installers/mypack-3.0.0-linux.run</buildDeltaAgainstPackUsingLinuxInstaller>

Using this information, SDC injects the dependency information needed by your delta pack to ensure it will be installed correctly and that the user has installed the base version before the delta pack.

You can specify a delta pack as your base version, building a chain of dependency that requires the user to install your base pack version as well as all intermediary delta packs.

Running a Build
Once you have a modified pack build file, you can update the branding in your pack definition file, export or build your product, and run a pack build like you normally do.

During the build, you should see a message stating the following, which indicates the build is a delta pack build and not a normal base version build:

Performing pack delta optimizations…

SDC determines which pieces of your software have remained the same and excludes them from the installer.
Verifying Results
You should see a dramatic decrease in the size of your new pack installer compared with the base version of your pack. This is the first sign you have built a delta pack correctly.

Once you install your pack, do a promote of a package that is tracking to the latest version of your software. After an install or upgrade of this software, you should see just the small set of changes you have made to your software.

Potential Pitfalls
As with any technology, there are some pitfalls to watch out for.

Inconsistent Compilation
Some technologies, e.g. Groovy, will inject instrumentation into your class files. Depending on the technology, this could produce slightly different class files each time a build is run. If you use these types of tools, creating delta packs is not going to produce a build with any size gain as the delta pack calculation will see all class files as changed.

Unnecessary Changes
Changing the version number of a plugin because you’re doing a new build is a common practice; however, this will produce larger than optimal delta packs.

[Author]

Posts