U.S. patent application number 15/860574 was filed with the patent office on 2019-07-04 for updating program packages at distribution endpoint.
This patent application is currently assigned to Microsoft Technology Licensing, LLC. The applicant listed for this patent is Microsoft Technology Licensing, LLC. Invention is credited to Cory Alan HENDRIXSON, Andy LIU, Jason Ghssane SALAMEH, John James VINTZEL.
Application Number | 20190205112 15/860574 |
Document ID | / |
Family ID | 67058929 |
Filed Date | 2019-07-04 |
![](/patent/app/20190205112/US20190205112A1-20190704-D00000.png)
![](/patent/app/20190205112/US20190205112A1-20190704-D00001.png)
![](/patent/app/20190205112/US20190205112A1-20190704-D00002.png)
![](/patent/app/20190205112/US20190205112A1-20190704-D00003.png)
![](/patent/app/20190205112/US20190205112A1-20190704-D00004.png)
![](/patent/app/20190205112/US20190205112A1-20190704-D00005.png)
![](/patent/app/20190205112/US20190205112A1-20190704-D00006.png)
United States Patent
Application |
20190205112 |
Kind Code |
A1 |
SALAMEH; Jason Ghssane ; et
al. |
July 4, 2019 |
UPDATING PROGRAM PACKAGES AT DISTRIBUTION ENDPOINT
Abstract
A computing system is provided that includes a distribution
endpoint including one or more processors configured to receive a
request from a developer computing device to update a program
managed by the distribution endpoint, the program being previously
packaged and signed. The one or more processors of the distribution
endpoint are further configured to receive a code file including a
change to the program, retrieve a package of the program that has
not been updated with the change to the program, generate an
updated package of the program by adding the code file to the
retrieved package of the program such that the updated package of
the program logically represents a package of the updated program,
and distribute the updated package of the program to an end user
computing device.
Inventors: |
SALAMEH; Jason Ghssane;
(Bothell, WA) ; LIU; Andy; (Redmond, WA) ;
VINTZEL; John James; (Redmond, WA) ; HENDRIXSON; Cory
Alan; (Sammamish, WA) |
|
Applicant: |
Name |
City |
State |
Country |
Type |
Microsoft Technology Licensing, LLC |
Redmond |
WA |
US |
|
|
Assignee: |
Microsoft Technology Licensing,
LLC
Redmond
WA
|
Family ID: |
67058929 |
Appl. No.: |
15/860574 |
Filed: |
January 2, 2018 |
Current U.S.
Class: |
1/1 |
Current CPC
Class: |
G06F 8/65 20130101; G06F
8/30 20130101; G06F 8/658 20180201 |
International
Class: |
G06F 8/65 20060101
G06F008/65 |
Claims
1. A computing system, comprising: a distribution endpoint
including one or more processors configured to: receive a request
from a developer computing device to update a program managed by
the distribution endpoint, the program being previously packaged
and signed; receive a code file including a change to the program
and a footprint file that tracks the change to the program from the
developer computing device, the footprint file including an updated
map of units of code in an updated version of the program and a
hash value for each unit of code; retrieve a package of the program
that has not been updated with the change to the program; generate
an updated package of the program based on the footprint file by
comparing hash values of each unit of code in the updated map to
hash values of corresponding units of code in a previous map of
units of code of the retrieved package to identify units of code
that have changed in the updated version of the program and
updating the identified units of code by adding the code file to
the retrieved package of the program such that the updated package
of the program logically represents a package of the updated
program; and distribute the updated package of the program to an
end user computing device.
2. The computing system of claim 1, wherein to add the code file to
the retrieved package of the program, the one or more processors of
the distribution endpoint are further configured to: identify one
or more unchanged code files of the program from the retrieved
package; and generate a new package that includes the one or more
unchanged code files of the program identified from the retrieved
package and the code file including the change to the program.
3. The computing system of claim 1, wherein to add the code file to
the retrieved package of the program, the one or more processors of
the distribution endpoint are further configured to add the code
file to the retrieved package of the program without repackaging
the program.
4. The computing system of claim 1, wherein the retrieved package
of the program includes a plurality of subpackages, and wherein the
one or more processors of the distribution endpoint are configured
to add the code file to one or more of the plurality of subpackages
based on the change to the program.
5. The computing system of claim 1, wherein the change to the
program is determined by a developer side application executed on
the developer computing device.
6. The computing system of claim 5, wherein the developer side
application is configured to generate the footprint file that
tracks the change to the program, and send the footprint file to
the distribution endpoint with the code file.
7. The computing system of claim 6, wherein the footprint file is
programmatically generated by the developer side application.
8. The computing system of claim 6, wherein the footprint file is
generated via user input.
9. The computing system of claim 1, wherein the program is
previously packaged and signed by a developer side application
executed on the developer computing device.
10. The computing system of claim 1, wherein the program is
previously packaged and signed by the distribution endpoint based
on code files of the program received from the developer computing
device.
11. A method comprising: at a processor of a distribution endpoint
of a computing system: receiving a request from a developer
computing device to update a program managed by the distribution
endpoint, the program being previously packaged and signed;
receiving a code file including a change to the program and a
footprint file that tracks the change to the program from the
developer computing device, the footprint file including an updated
map of units of code in an updated version of the program and a
hash value for each unit of code; retrieving a package of the
program that has not been updated with the change to the program;
generating an updated package of the program based on the footprint
file by comparing hash values of each unit of code in the updated
map to hash values of corresponding units of code in a previous map
of units of code of the retrieved package to identify units of code
that have changed in the updated version of the program and
updating the identified units of code by adding the code file to
the retrieved package of the program such that the updated package
of the program logically represents a package of the updated
program; and distributing the updated package of the program to an
end user computing device.
12. The method of claim 11, wherein adding the code file to the
retrieved package of the program further comprises: identifying one
or more unchanged code files of the program from the retrieved
package; and generating a new package that includes the one or more
unchanged code files of the program identified from the retrieved
package and the code file including the change to the program.
13. The method of claim 11, wherein adding the code file to the
retrieved package of the program further comprises adding the code
file to the retrieved package of the program without repackaging
the program.
14. The method of claim 11, wherein the retrieved package of the
program includes a plurality of subpackages, and wherein the method
comprises adding the code file to one or more of the plurality of
subpackages based on the change to the program.
15. The method of claim 11, wherein the change to the program is
determined by a developer side application executed on the
developer computing device.
16. The method of claim 15, wherein the method further comprises,
at the developer side application, generating the footprint file
that tracks the change to the program, and sending the footprint
file to the distribution endpoint with the code file.
17. The method of claim 16, wherein the footprint file is
programmatically generated by the developer side application.
18. The method of claim 11, wherein the program is previously
packaged and signed by a developer side application executed on the
developer computing device.
19. The method of claim 11, wherein the program is previously
packaged and signed by the distribution endpoint based on code
files of the program received from the developer computing
device.
20. A computing device comprising a processor configured to:
receive an update to a program stored on the computing device, the
program being previously packaged and signed; determine a code file
including a change to the program and a footprint file that tracks
the change to the program from the developer computing device, the
footprint file including an updated map of units of code in an
updated version of the program and a hash value for each unit of
code; retrieve a package of the program that has not been updated
with the change to the program; and generate an updated package of
the program without repackaging the program based on the footprint
file by comparing hash values of each unit of code in the updated
map to hash values of corresponding units of code in a previous map
of units of code of the retrieved package to identify units of code
that have changed in the updated version of the program and
updating the identified units of code by adding the code file to
the retrieved package of the program and updating a manifest of the
retrieved package to point to the added code file for the
identified units of code such that the updated package of the
program logically represents a package of the updated program.
21. The computing system of claim 1, wherein updating the
identified units of code further includes updating a manifest of
the retrieved package to point to the added code file for the
identified units of code.
Description
BACKGROUND
[0001] Developers perform a packaging process on their applications
to make guarantees about the state of the application and its
integrity. The complexity of the packaging process has adapted to
meet increasingly complex scenarios needed to fit consumer and
developer requirements, such as disjoint sets of packages that
operate as a single unit allowing for code or content to be created
and distributed separately from the application.
SUMMARY
[0002] A computing system is provided that may include a
distribution endpoint including one or more processors configured
to receive a request from a developer computing device to update a
program managed by the distribution endpoint, the program being
previously packaged and signed. The one or more processors of the
distribution endpoint may be further configured to receive a code
file including a change to the program, retrieve a package of the
program that has not been updated with the change to the program,
generate an updated package of the program by adding the code file
to the retrieved package of the program such that the updated
package of the program logically represents a package of the
updated program, and distribute the updated package of the program
to an end user computing device.
[0003] This Summary is provided to introduce a selection of
concepts in a simplified form that are further described below in
the Detailed Description. This Summary is not intended to identify
key features or essential features of the claimed subject matter,
nor is it intended to be used to limit the scope of the claimed
subject matter. Furthermore, the claimed subject matter is not
limited to implementations that solve any or all disadvantages
noted in any part of this disclosure.
BRIEF DESCRIPTION OF THE DRAWINGS
[0004] FIG. 1 is a schematic view of a computing system including a
distribution endpoint, a developer computing device, and one or
more end user devices, according to one implementation of the
present disclosure.
[0005] FIG. 2 shows a packaging and signing process using the
computing system of FIG. 1.
[0006] FIG. 3 is a schematic view of the distribution endpoint and
developer computing device of FIG. 1.
[0007] FIG. 4 shows a program updating process using the computing
system of FIG. 1.
[0008] FIG. 5 is a flowchart illustrating a method for updating
packages implemented by the computing system of FIG. 1.
[0009] FIG. 6 is a schematic view of an example computing
environment in which the computing system of FIG. 1 may be
enacted.
DETAILED DESCRIPTION
[0010] FIG. 1 illustrates a schematic view of a computing system 10
that processes code files of a developer's changes to their program
and a package of an older version of that program to generate an
updated package of the program that may be deployed to end user
devices. As shown, computing system 10 includes a distribution
endpoint 12 configured to communicate with a developer computing
device 14 and one or more end user computing devices 16 to deploy a
package 18 of a program 20 to the one or more end user computing
devices 16. In one example, the developer computing device 14 may
take the form of a desktop computing device. However, it will be
appreciated that the developer computing device 14 may take other
forms, such as, for example, a tablet computing device, a mobile
computing device, a laptop computing device, etc. Similarly, the
end user computing devices 16 may take the form of a desktop
computing device, a tablet computing device, a mobile computing
device, a laptop computing device, a gaming console computing
device, and/or another type of computing device.
[0011] In the illustrated example, the distribution endpoint 12
includes a plurality of server devices 12A that operate in a cloud
computing configuration. However, it will be appreciated that the
distribution endpoint 12 may take other forms, such as a single
server device or a remote computing device configured to perform
the processes and methods described herein. The distribution
endpoint 12 stores and manages the package 18 of the program 20 for
the developer computing device 14, such that changes to the program
20 may be received from the developer computing device 14 and
utilized to update the package 18 of the program 20 stored on the
distribution endpoint 12 without requiring the developer computing
device 14 to reupload the entire updated program. The updated
package may be made available to the one or more end user computing
devices 16 via the distribution endpoint 12 or databases/servers
associated with the distribution endpoint 12.
[0012] The program 20 may be created via a developer side
application executed on the developer computing device 14. The
developer side application may, for example, take the form of an
integrated development environment (IDE) or another type of
software development platform. After the developer has reached a
version of the program 20 that the developer intends to make
available to end users, that version of the program 20 may be
packaged, signed, and deployed to the one or more end user devices
16 via the distribution endpoint 12.
[0013] FIG. 2 shows an example program 20 developed and stored on
the developer computing device 14. In the illustrated example, the
program 20 takes the form of a simple game, and includes a MAIN.EXE
code file, an ENGLISH resources code file that includes several
LEVEL.FILEFORMAT files, and a SCALE-150 code file that includes
several IMAGE.FILEFORMAT files. The program 20 may also have other
additional resources, such as a footprint file 22 that may include
certificates, a manifest, a concept group map, a blockmap, code
integrity files, and other types of files related to packaging and
deploying the program 20. For example, the manifest may take the
form of a document that contains information an end user computing
device may need to deploy, display, or update the program 20. This
information may include package identity, package dependencies,
required capabilities, etc. Typically, the manifest is digitally
signed during a signing process of the package 18 of the program
20. After the manifest has been digitally signed, the manifest
typically cannot be modified without invalidating the package
signature. The blockmap may take the form of a document that
contains a list of the program 20 files along with indexes and
cryptographic hashes for each block of data that is stored in the
package 18 of the program 20. Typically, the manifest, the
blockmap, code integrity files, and other packaging resources are
generated during the packaging process, and are contained in the
resulting package 18 of the program 20.
[0014] It will be appreciated that the example program 20
illustrated in FIG. 2 is merely exemplary, and that the types of
programs and the content of program 20 that may be processed
according to the methods described herein are not limited to the
example program 20 of FIG. 2.
[0015] When the developer intends to make the example program 20
available to end users, the program 20 is put through a packaging
and signing process which allows the developer side application and
the distribution endpoint 12 to make certain guarantees about the
state of the program 20 and its integrity. Thus, as shown in FIG.
2, the program 20 is sent to a packaging module 24. At step (1) the
packaging module 24 may be configured to package the program 20
based on instructions included in the footprint file 22. For
example, the footprint file 22 may indicate the developer's intent
regarding whether the program 20 should be packaged in a package
bundle format 25A that includes a plurality of subpackages, or as a
monolithic package format 25B that includes all of the code files
of the program 20 in a single package container. In another
example, the footprint file 22 may convey the developer's intent
for the code files of a loose directory structure of the program 20
(e.g. this code file is an asset, this code file is a resource,
this code file should cost money and be deployed separately, etc.).
In this example, the packaging module 24 may be configured to take
in as input both the loose directory structure of the program 20
and the footprint file, and perform the packaging process on the
program 20 based on the footprint file 22 to produce a package 18
of the program 20.
[0016] The packaging module 24 may be further configured to
generate footprint file 22 including the manifest, code integrity
files, and the V1BLOCKMAP 23A. As discussed previously, the
V1BLOCKMAP 23A may contains a list of the program 20 files for this
initial version of the program 20, as well as indexes and
cryptographic hashes for each block of data that is stored in the
package 18 of the program 20.
[0017] The package 18 of the program 20 is further processed by a
signing module 26. At step (2) the signing module 26 may be
configured to perform a signing process on the package 18 based on
the package format. The signing module 26 may be configured to
digitally sign the manifest included in the footprint file 22 of
the package 18. For example, the package bundle format 25A includes
a plurality of subpackages, and the signing module 26 may be
configured to perform the signing process on each subpackage and
the container B which contains and references the plurality of
subpackages MAIN, EN, and 150. As another example, the monolithic
package format 25B may only include a single package for all of the
code files in the program 20. Thus, the signing module 26 may be
configured to perform the signing process on the entire monolithic
package of program 20.
[0018] It will be appreciated that the packaging module 24 and the
signing module 26 may utilize any suitable packaging and signing
methods. Typical packaging and signing methods may each take about
one minute per gigabyte to process a program.
[0019] After the program 20 has been packaged and signed by the
packaging module 24 and the signing module 26, the resulting
package 18 of the program may be stored on the distribution
endpoint 12. In some examples, the distribution endpoint 12 may
perform other processes on the package 18 of the program 20, such
as, for example, performing a validation process to ensure that the
program 20 meets suitable quality standards. The package 18 of the
program 20 may then be deployed to the one or more end user
computing devices 16.
[0020] In one example, the packaging module 24 and the signing
module 26 may be included in the developer side application
executed on the developer computing device 14. In this example, the
developer computing device 14 may package and sign the program 20,
and upload the complete package 18 of the program 20 to the
distribution endpoint 12. In another example, the packaging module
24 and the signing module 26 may be included in software executed
by one or more processors of the distribution endpoint 12. In this
example, the developer computing device 14 may be configured to
upload a loose directory of code files of the program 20, and a
footprint file 22 that indicates how the developer intends the
program 20 to be packaged. After receiving the loose directory of
code files of the program 20 and the footprint file 22, one or more
processors of the distribution endpoint 12 may be configured to
package and sign the program 20 for the developer based on the
footprint file 22.
[0021] On typical software development and deployment platforms, to
deploy a new version of the program 20 to the end user computing
devices 16, the developer computing device 14 must upload the
entire updated program 20 to the distribution endpoint 12 even
though only a portion of the program 20 may have been changed.
[0022] FIG. 3 illustrates a schematic view of the developer
computing device 14 and the distribution endpoint 12 that processes
code files of a developer's changes to their program and a package
of an older version of that program to generate an updated package
of the program that may be deployed to end user devices. As shown,
the distribution endpoint 12 may include a plurality of server
devices 12A, each server device including a processor 28,
non-volatile memory 30, volatile memory 32, and other suitable
computing components. As shown, one or more processors 28 of the
server devices 12A of the distribution endpoint 12 are configured
to execute instructions for a server side application 34 of a
software development and deployment platform.
[0023] Similarly, the developer computing device 14 may also
include a processor 36, non-volatile memory 38, volatile memory 40,
user input device 42 and other suitable computing components. As
shown, the processor 36 of the developer computing device 14 is
configured to execute instructions for a developer side application
44 of the software development and deployment platform. The
developer side application 44 is configured to communicate with the
server side application 34 over a network 46, which, for example,
may be a wide area network.
[0024] As discussed previously, the developer side application 44
may take the form of an IDE, and provides software tools to develop
the program 20. To deploy the program 20 to end users, the program
20 may be packaged and signed according to the processes and
methods described regarding FIG. 2. In one example, the developer
side application 44 may include a developer side packaging module
24A and a developer side signing module 26A, and may be configured
to package and sign the program 20 before uploading the resulting
package 18 of the program 20 to the distribution endpoint 12 over
the network 46.
[0025] In another example, the server side application 34 may
include a server side packaging module 24B and a server side
signing module 26B, and may be configured to package and sign the
program 20 for the developer of the developer computing device 14.
In this example, the developer side application 44 may be
configured to upload, to the distribution endpoint 12, a loose
directory of code files 48 of the program 20 and a footprint file
22 that includes instructions regarding how the program 20 is to be
packaged.
[0026] After the program 20 has been packaged, signed, and
validated, the package 18 of the program 20 may be stored on the
distribution endpoint 12 and/or a database or other server
associated with the distribution endpoint 12. The stored package 18
of the program 20 may then be deployed to one or more end user
computing devices 16.
[0027] As discussed previously, the developer of the program 20 may
continue to update and make changes to code files of the program
20. After the developer of the has updated the program 20 to a new
version that the developer intends to deploy to the end users, the
developer computing device 14 may be configured to send a request
50 to the distribution endpoint 12 to update the package 18 of the
program 20. In turn, the one or more processors 28 of the plurality
of server devices 12A of the distribution endpoint 12 may be
configured to receive the request 50 from the developer computing
device 14 to update the program 20 managed by the distribution
endpoint 12, the program 20 being previously packaged and signed.
As discussed previously, in one example, the program 20 is
previously packaged and signed by the developer side application 44
executed on the developer computing device 14. In another example,
the program is previously packaged and signed by the distribution
endpoint 12 based on code files 48 of the program 20 received from
the developer computing device 14. In either example, after the
program 20 has been packaged, signed, and stored on the
distribution endpoint 12, the package 18 of the program 20 may be
subsequently updated in response to the request 50 received from
the developer computing device 14.
[0028] Alongside or subsequently to the request 50, the server side
application 34 executed by the one or more processors 28 of the
distribution endpoint 12 may be further configured to receive a
code file 52 including a change to the program 20. The code file 52
may include one or more code files that contain the code changes to
the program 20 since the last update to the package 18 of the
program 20 managed by the distribution endpoint 12. In one example,
the code file 52 may be a loose code file that is unpackaged and
unsigned. The distribution endpoint 12 may be configured to perform
other verification processes to guarantee that the code file 52 was
sent by the developer computing device 14. In another example, the
code file 52 may be packaged and signed by the developer side
application 44 executed on the developer computing device 14 before
being sent to the distribution endpoint 12 to provide guarantees
for the code integrity and authenticity of the code file 52.
[0029] In one example, the change to the program 20 is determined
by the developer side application 44 executed on the developer
computing device 14. As illustrated in FIG. 3, the developer side
application 44 may further include a change determining module 54
configured to track each change made to the code of the program 20.
The developer may continue to make iterative changes to the program
20 including compiling and testing those changes, until the
developer has reached an updated version of the program 20 that the
developer intends to deploy to the end user computing devices.
Next, the change determining module 54 of the developer side
application 44 may be configured to determine a code difference
between the updated version of the program 20 and the previous
version of the program 20, and generate the code file 52 of changes
to the program 52 based on the determined code difference.
[0030] In one example, the developer side application 44 may be
configured to package the updated program including generating a
new blockmap for the package of the updated program. The blockmap
may contain a list of files for the updated version of the program
20, as well as indexes and cryptographic hashes for each block of
data that is stored in the new package for the updated program. To
determine the code difference between the previous version and the
updated version of the program 20, the change determining module 54
may be configured to compare the updated blockmap of the updated
program package to the previous blockmap of the previous program
package. In particular, the change determining module 54 may,
block-by-block, compare the cryptographic hash determined for each
file. If the cryptographic hash value is different for a particular
block between the updated and previous blockmaps, then the change
determining module 54 may determine that the associated file of
program 20 has been changed. Thus, the change determining module 54
may be configured to select that particular file of the updated
program to be uploaded to the distribution endpoint 12. In this
manner, each code file that has been changed since the previous
iteration of program 20 may be detected by the change determining
module 54 and uploaded to the distribution endpoint 12 as the code
file 52 of changes to the program 20.
[0031] The change determining module 54 is further configured to
generate a footprint file 22B that tracks the change to the program
20 in addition to the code file 52 of changes to the program 20.
The footprint file 22B may indicate which code files of the program
20 were changed, and/or indicate how the code changes affect the
program 20. Particularly, the footprint file 22B may be generated
to include the updated blockmap for the updated program package
discussed above.
[0032] In one example, the footprint file 22B is programmatically
generated by the change determining module 54 of the developer side
application 44. That is, the change determining module 54 may be
configured to track which code files of the program 20 have been
changed by the developer, and programmatically generate the
footprint file 22B to include metadata indicating which code files
of the program 20 have been updated and/or the updated
blockmap.
[0033] In another example, the footprint file 22B is generated via
user input. The developer computing device 14 may be configured to
received user input via the user input device 42, which, for
example, may take the form of a mouse and keyboard. In particular,
the developer side application 44 may be configured to allow the
developer to author the footprint file 22B via user input to the
user input device 42. Through the footprint file 22B, the developer
may indicate which code files of the program 20 are being updated
in this new version of the program 20. The developer side
application 44 may generate the footprint file 22B based on the
user input received by the user input device 42 according to
standards expected by the distribution endpoint 12. In either
example, after the footprint file 22B has been generated, the
developer side application 44 may be configured to send the
footprint file 22B to the distribution endpoint 12 with the code
file 52 of the changes to the program 20.
[0034] As illustrated in FIG. 3, the one or more processors 28 of
the distribution endpoint 12 are configured to receive the code
file 52 of the changes to the program 20 and the footprint file 22B
from the developer computing device 14. Next, the server side
application 34 executed by the one or more processors 28 may be
configured to retrieve a package 18A of the program 20 that has not
been updated with the change to the program. That is, the server
side application 34 retrieves the previous package 18A of the
program 20 that is stored on the distribution endpoint 12 or an
associated database or server.
[0035] As illustrated, a package updating module 56 of the server
side application 34 is configured to take as input, the code file
52 of the changes to the program 52, the previous package 18A of
the program 20 that has not yet been updated, and the footprint
file 22B. The package updating module 56 is configured to generate
an updated package 18B of the program 20 based on the code file 52
of the changes to the program 20, the previous package 18A of the
program 20, and the footprint file 22B. In particular, the package
updating module 56 may be configured to generate the updated
package 18B of the program 20 by adding the code file 52 to the
retrieved package 18A of the program 20 such that the updated
package 18B of the program 20 logically represents a package of the
updated program. That is, the updated package 18B logically
represents the updated version of the program 20 that has been
packaged according to the methods described above.
[0036] In one example, to add the code file 52 to the retrieved
package 18A of the program 20, the package updating module 56 may
be configured to add the code file 52 to the retrieved package 18A
of the program without repackaging the program 20. For example, the
package updating module 56 may determine which code files within
the previous package 18A were changed during the update based on
the footprint file 22B. The package updating module 56 may be
configured to add the code file 52 of the changes to the program 20
to the retrieved package 18A of the program 20, and modify metadata
of the retrieved package 18A to reference the added code file 52 as
well as instructions on deploying the package with the added code
file 52 of the changes to the program 20 such that a package
management system on the end user computing devices 16 may
appropriately install the updated version of program 20 via the
updated package 18B. In this manner, the package updating module 56
may update the previous package 18A to reflect the new changes to
the program 20 without rebuilding the entire package.
[0037] In one specific example, the package updating module 56 may
be configured to extract a previous blockmap from the previous
package 18A of the program 20, and an updated blockmap from the
footprint file 22B received from the developer computing device 14.
Next, the package updating module 56 may be configured to,
block-by-block, compare the cryptographic hashes of the previous
blockmap to the updated blockmap. Upon detecting a difference, the
package updating module 56 may append an associated code file from
the code file 52 of changes to the program 20 to the retrieved
package (previous package) 18A, and update footprint files and
metadata of the retrieved package (e.g. blockmap, manifest, etc.)
to reference the appended code file. In this manner, each file in
the code file 52 of changes to the program 20 is appended to the
retrieved package 18A, and appropriately referenced/indexed by the
updated footprint files and metadata (e.g. blockmap, manifest,
etc.), to generate the updated package 18B which may be deployed on
end user computing devices 16.
[0038] In another example, to add the code file to the retrieved
package 18A of the program 20, the package updating module 56 may
be configured to generate a new package for the updated version of
the program 20. That is, the updated package 18B is a rebuilt
package for the updated version of the program 20. To generate the
new package, the package updating module 56 may be configured to
identify one or more unchanged code files of the program from the
retrieved package (previous package) 18A. The package updating
module 56 may identify the one or more unchanged code files based
on the footprint file 22B received from the developer computing
device 14. In one specific example, the package updating module 56
may be configured to extract a previous blockmap from the previous
package 18A of the program 20, and an updated blockmap from the
footprint file 22B received from the developer computing device 14.
Next, the package updating module 56 may be configured to,
block-by-block, compare the cryptographic hashes of the previous
blockmap to the updated blockmap. For each block that has matching
hash values in both block maps, the package updating module 56 may
determine that the code file associated with that block is
unchanged. In this manner, the package updating module 56 may
identify each code file in the retrieved package (previous package)
18A that was not changed in this update.
[0039] After identifying the one or more unchanged code files, the
package updating module 56 may be configured to generate a new
package that includes the one or more unchanged code files of the
program identified from the retrieved package 18A and the code file
52 including the change to the program. That is, the package
updating module 56 identifies and selects only the unchanged code
files from the retrieved package 18A, and copies those unchanged
code files into the new package alongside the code files 52 of the
changes to the program 20 to generate the updated package 18B. In
this manner, the updated package 18B does not include any
out-of-date code files from the previous versions of the program
20. Lastly, the package updating module 56 may update the footprint
files and metadata (e.g. manifest, blockmap, etc.) of the updated
package 18B to appropriately reference/index the contained code
files.
[0040] As illustrated in FIG. 3, after the updated packaged is
generated by the package updating module 56, the updated package
18B may be sent to a package deployment module 58 which may be
configured to distribute the updated package 18B of the program 20
to an end user computing device 16, or otherwise handle deployment
of the updated package 18B to one or more of the end user computing
devices 16. In one example, deploying the updated package 18B may
include making the updated package 18B available for download from
a download server. Deploying the updated package 18B may further
include updating metadata on the download server that is readable
by the one or more end user devices 16 to indicate that the program
20 has been updated by the developer and that an updated package
18B is available for download.
[0041] FIG. 4 shows the example program 20 of FIG. 2 being updated
by the developer. In this example, at step (5), the developer makes
a change to the LEVEL2.FILEFORMAT code file of the simple game of
the example program 20. When the developer makes the change, the
change determining module 54, at step (6), identifies the change
and generates a code file 52 of the changes to the program 20 and a
footprint file 22B as discussed regarding FIG. 3. In one specific
example, the change determining module 54 may be configured to
compare, block-by-block, the V2BLOCKMAP 23B of the updated
footprint file 22A for the updated program to the previous
V1BLOCKMAP 23A. Any differences between hash values for a
particular block in the V2BLOCKMAP 23B and the V1BLOCKMAP 23A
indicates that the associated code file for that particular block
has been changed.
[0042] At step (7), the code file 52 of the changes to the program
20 and the footprint file 22B, which may include the V2BLOCKMAP
23B, are uploaded to the distribution endpoint 12. It will be
appreciated that the total payload of the code file 52 and the
footprint file 22B will typically be much smaller than the total
size of the program 20, thus reducing the amount of data that is
required to be uploaded to the distribution endpoint 12.
[0043] At step (8), the package updating module 56 updates a
previous package 18A based on the code file 52 of the changes to
the program 20 and the footprint file 22B. As illustrated, the
package updating module 56 may be configured to update the previous
package 18A differently depending upon the package format. In one
example, the previous package 18A was packaged in a monolithic
package format 25B, and the entire monolithic package is updated by
the package updating module 56.
[0044] In another example, the previous package 18A was packaged in
the package bundle format 25A that includes a plurality of
subpackages. In the illustrated example, the plurality of
subpackages include a container for the whole bundle B, a container
for the MAIN.EXE, a container for the EN resources, and a container
for the SCALE 150 resources. To update the previous package 18A in
the package bundle format 25A, the package update module 56 may be
configured to add the code file 52 to one or more of the plurality
of subpackages based on the change to the program. In the
illustrated example, the developer changed the LEVEL2.FILEFORMAT
code file of the EN resources. Thus, based on the footprint file
22B which includes metadata that indicates the changes to the
program 20, the package update module 56 adds the code file 52 to
the subpackage container for the EN resources. The package update
module 56 does not add the code file 52 to the MAIN.EXE subpackage
container nor the SCALE 150 subpackage container, as no changes
were made to code files within those containers in the illustrated
example. Additionally, as one of the subpackages has been modified,
the package update module 56 may be configured to also update the
container for the whole package bundle B to reference the updated
subpackage container for the EN resources.
[0045] After generating the updated package 18B according to the
steps discussed above, the distribution endpoint 12 may be
configured to distribute the updated package 18B to one or more end
user computing devices 16.
[0046] In one example, the developer computing device 14 may be
configured to distribute the package 18 of the program 20 rather
than using the distribution endpoint 12. In this example, the
developer side application 44 may be further configured to perform
the functions of the server side application 34. That is, the
developer side application 44 may further include the package
updating module 56 and the package deployment module 58, and may be
configured to perform their functions described above. The
developer side application 44 may take the form of an IDE or other
type of software development platform which provides tools for the
developer to update their program 20. For example, the processor 36
of the developer computing device 14 may be configured receive an
update to a program stored on the computing device, the program
being previously packaged and signed. After the developer has made
a change to the program 20 using the developer side application 44,
the processor may determine a code file including a change to the
program. The change to the program may be determined as the code
difference between the current version of the program and the
previous version of the program 20 that was packaged as the
previous package. Next, the processor may retrieve the previous
package of the program that has not been updated with the change to
the program, and generate an updated package of the program without
repackaging he program by adding the code file to the retrieved
package of the program such that the updated package of the program
logically represents a package of the updated program.
[0047] FIG. 5 is a flowchart illustrating a method 500 for updating
packages of an older version of a program, the method 500
implemented by the computing system of FIG. 1. At 502, the method
500 may include determining a change to a program, wherein the
change to the program is determined by a developer side application
executed on a developer computing device. In one example, the
developer side application is an IDE or other type of software
development platform that provides tools for the developer to make
changes to a program. The developer side application may further
include a change determining module which tracks each change the
developer makes to the program. Once the developer has reached an
updated version of the program that the developer intends to
deploy, the change determining module of the developer side
application may determine a code difference between the old version
of the program and the updated version of the program.
[0048] At 504, the method 500 may include generating a footprint
file that tracks the change to the program. In one example, the
change determining module of the developer side application may be
further configured to generate a footprint file that includes
metadata indicating which code files of the program have been
changed. In this example, the change determining module may
programmatically generate the footprint file as the developer makes
changes to the program. In another example, the developer side
application may provide tools that allow the developer to author
the footprint file to indicate which code files have been
changed.
[0049] At 506, the method 500 may include sending a request to a
distribution endpoint to update the program. At 508, the method 500
may include, at the distribution endpoint, receiving the request
from the developer computing device to update a program managed by
the distribution endpoint, the program being previously packaged
and signed. In one example, the program may be previously packaged
and signed by the developer side application executed on the
developer computing device. That is, the developer computing device
may have packaged and signed an initial version of the program, and
uploaded the package to the distribution endpoint at a prior time.
In another example, the program is previously packaged and signed
by the distribution endpoint based on code files of the program
received from the developer computing device. In this example, the
developer computing device may be configured to upload a loose
directory of code files of the program to the distribution endpoint
along with a footprint file that conveys the developer's intent for
each code file. The distribution endpoint may package and sign the
program for the developer based on the loose directory of code
files and the footprint file.
[0050] At 510, the method 500 may include, at the developer
computing device, sending a code file of the change to the program
and the footprint file to the distribution endpoint with the code
file. At 512, the method 500 may include, at the distribution
endpoint, receiving a code file including a change to the program.
In one example, the code file may be a loose code file that is
unpackaged and unsigned. In another example, the code file may be
packaged and signed at the developer computing device before being
uploaded to the distribution endpoint. At 512, the method 500 may
further include receiving the footprint file.
[0051] At 514, the method 500 may include retrieving a package of
the program that has not been updated with the change to the
program. In one example, the server side application 34 executed on
the distribution endpoint retrieves an older package of the
previous version of the program that was previously packaged,
signed, and stored on the distribution endpoint 12 or an associated
database or server.
[0052] At 516, the method 500 may include generating an updated
package of the program by adding the code file to the retrieved
package of the program such that the updated package of the program
logically represents a package of the updated program. In one
example, the server side application 34 executed by the
distribution endpoint is configured to take as input, the code file
and footprint file received at 512, and the previous package of the
program retrieved at 514, and generate an updated package of the
program 20.
[0053] In one example, at 516, the method 500 may further include
determining an updated version of the program that includes the
code file, and generating a new package for the updated version of
the program. To generate the new package, the method 500 may
include identifying one or more unchanged code files of the program
from the retrieved package (previous package) 18A. For example, the
one or more unchanged code files may be identified based on the
footprint file 22B received from the developer at step 508. In one
specific example, the method 500 may include extracting a previous
blockmap from the previous package 18A of the program 20, and an
updating blockmap from the footprint file 22B received from the
developer computing device 14. Next, the method 500 may include,
block-by-block, comparing the cryptographic hashes of the previous
blockmap to the updated blockmap. For each block that has matching
hash values in both block maps, the code file associated with that
block may be determined to be unchanged. In this manner, each code
file in the retrieved package (previous package) 18A that was not
changed in the update may be identified.
[0054] After identifying the one or more unchanged code files, at
516, the method 500 may further include generating a new package
that includes the one or more unchanged code files of the program
identified from the retrieved package 18A and the code file 52
including the change to the program. That is, the unchanged code
files from the retrieved package 18A may be identified and
selected, and copied into the new package alongside the code files
52 of the changes to the program 20 to generate the updated package
18B. In this manner, the updated package 18B does not include any
out-of-date code files from the previous versions of the program
20. Lastly, at 516, the method 500 may include updating the
footprint files and metadata (e.g. manifest, blockmap, etc.) of the
updated package 18B to appropriately reference/index the contained
code files.
[0055] In another example, at 516, the method 500 may include
adding the code file to the retrieved package of the program
without repackaging the program. For example, the package updating
module 56 may determine which code files within the previous
package 18A were changed during the update based on the footprint
file 22B received at 512, and the method may include updating the
previous package 18A retrieved at 514 to reflect the new changes to
the program 20 without rebuilding the entire package.
[0056] At 518, the method 500 may include distributing the updated
package of the program to an end user computing device. In one
example, at 518, the method 500 may include making the updated
package generated at 516 available for download from a download
server. The distribution endpoint implementing 518 of method 500
may be configured to update metadata on the download server that is
readable by the one or more end user devices 16 to indicate that
the program 20 has been updated by the developer and that an
updated package 18B is available for download.
[0057] In some embodiments, the methods and processes described
herein may be tied to a computing system of one or more computing
devices. In particular, such methods and processes may be
implemented as a computer-application program or service, an
application-programming interface (API), a library, and/or other
computer-program product.
[0058] FIG. 6 schematically shows a non-limiting embodiment of a
computing system 600 that can enact one or more of the methods and
processes described above. Computing system 600 is shown in
simplified form. Computing system 600 may embody the computing
system 10 described above, including the developer computing device
14 and the one or more server devices 12A of the distribution
endpoint 12. Computing system 600 may take the form of one or more
personal computers, server computers, tablet computers,
home-entertainment computers, network computing devices, gaming
devices, mobile computing devices, mobile communication devices
(e.g., smart phone), and/or other computing devices, and wearable
computing devices such as smart wristwatches and head mounted
augmented reality devices.
[0059] Computing system 600 includes a logic processor 602 volatile
memory 604, and a non-volatile storage device 606. Computing system
600 may optionally include a display subsystem 608, input subsystem
610, communication subsystem 612, and/or other components not shown
in FIG. 6.
[0060] Logic processor 602 includes one or more physical devices
configured to execute instructions. For example, the logic
processor may be configured to execute instructions that are part
of one or more applications, programs, routines, libraries,
objects, components, data structures, or other logical constructs.
Such instructions may be implemented to perform a task, implement a
data type, transform the state of one or more components, achieve a
technical effect, or otherwise arrive at a desired result.
[0061] The logic processor may include one or more physical
processors (hardware) configured to execute software instructions.
Additionally or alternatively, the logic processor may include one
or more hardware logic circuits or firmware devices configured to
execute hardware-implemented logic or firmware instructions.
Processors of the logic processor 602 may be single-core or
multi-core, and the instructions executed thereon may be configured
for sequential, parallel, and/or distributed processing. Individual
components of the logic processor optionally may be distributed
among two or more separate devices, which may be remotely located
and/or configured for coordinated processing. Aspects of the logic
processor may be virtualized and executed by remotely accessible,
networked computing devices configured in a cloud-computing
configuration. In such a case, these virtualized aspects are run on
different physical logic processors of various different machines,
it will be understood.
[0062] Non-volatile storage device 606 includes one or more
physical devices configured to hold instructions executable by the
logic processors to implement the methods and processes described
herein. When such methods and processes are implemented, the state
of non-volatile storage device 604 may be transformed--e.g., to
hold different data.
[0063] Non-volatile storage device 606 may include physical devices
that are removable and/or built-in. Non-volatile storage device 604
may include optical memory (e.g., CD, DVD, HD-DVD, Blu-Ray Disc,
etc.), semiconductor memory (e.g., ROM, EPROM, EEPROM, FLASH
memory, etc.), and/or magnetic memory (e.g., hard-disk drive,
floppy-disk drive, tape drive, MRAM, etc.), or other mass storage
device technology. Non-volatile storage device 606 may include
nonvolatile, dynamic, static, read/write, read-only,
sequential-access, location-addressable, file-addressable, and/or
content-addressable devices. It will be appreciated that
non-volatile storage device 606 is configured to hold instructions
even when power is cut to the non-volatile storage device 606.
[0064] Volatile memory 604 may include physical devices that
include random access memory. Volatile memory 604 is typically
utilized by logic processor 602 to temporarily store information
during processing of software instructions. It will be appreciated
that volatile memory 604 typically does not continue to store
instructions when power is cut to the volatile memory 604.
[0065] Aspects of logic processor 602, volatile memory 604, and
non-volatile storage device 606 may be integrated together into one
or more hardware-logic components. Such hardware-logic components
may include field-programmable gate arrays (FPGAs), program- and
application-specific integrated circuits (PASIC/ASICs), program-
and application-specific standard products (PSSP/ASSPs),
system-on-a-chip (SOC), and complex programmable logic devices
(CPLDs), for example.
[0066] The terms "module," "program," and "engine" may be used to
describe an aspect of computing system 600 typically implemented in
software by a processor to perform a particular function using
portions of volatile memory, which function involves transformative
processing that specially configures the processor to perform the
function. Thus, a module, program, or engine may be instantiated
via logic processor 602 executing instructions held by non-volatile
storage device 606, using portions of volatile memory 604. It will
be understood that different modules, programs, and/or engines may
be instantiated from the same application, service, code block,
object, library, routine, API, function, etc. Likewise, the same
module, program, and/or engine may be instantiated by different
applications, services, code blocks, objects, routines, APIs,
functions, etc. The terms "module," "program," and "engine" may
encompass individual or groups of executable files, data files,
libraries, drivers, scripts, database records, etc.
[0067] When included, display subsystem 608 may be used to present
a visual representation of data held by non-volatile storage device
606. The visual representation may take the form of a graphical
user interface (GUI). As the herein described methods and processes
change the data held by the non-volatile storage device, and thus
transform the state of the non-volatile storage device, the state
of display subsystem 608 may likewise be transformed to visually
represent changes in the underlying data. Display subsystem 608 may
include one or more display devices utilizing virtually any type of
technology. Such display devices may be combined with logic
processor 602, volatile memory 604, and/or non-volatile storage
device 606 in a shared enclosure, or such display devices may be
peripheral display devices.
[0068] When included, input subsystem 610 may comprise or interface
with one or more user-input devices such as a keyboard, mouse,
touch screen, or game controller. In some embodiments, the input
subsystem may comprise or interface with selected natural user
input (NUI) componentry. Such componentry may be integrated or
peripheral, and the transduction and/or processing of input actions
may be handled on- or off-board. Example NUI componentry may
include a microphone for speech and/or voice recognition; an
infrared, color, stereoscopic, and/or depth camera for machine
vision and/or gesture recognition; a head tracker, eye tracker,
accelerometer, and/or gyroscope for motion detection and/or intent
recognition; as well as electric-field sensing componentry for
assessing brain activity; and/or any other suitable sensor.
[0069] When included, communication subsystem 612 may be configured
to communicatively couple various computing devices described
herein with each other, and with other devices. Communication
subsystem 612 may include wired and/or wireless communication
devices compatible with one or more different communication
protocols. As non-limiting examples, the communication subsystem
may be configured for communication via a wireless telephone
network, or a wired or wireless local- or wide-area network, such
as a HDMI over Wi-Fi connection. In some embodiments, the
communication subsystem may allow computing system 600 to send
and/or receive messages to and/or from other devices via a network
such as the Internet.
[0070] The following paragraphs provide additional support for the
claims of the subject application. One aspect provides a computing
system, comprising a distribution endpoint including one or more
processors configured to receive a request from a developer
computing device to update a program managed by the distribution
endpoint, the program being previously packaged and signed, receive
a code file including a change to the program, retrieve a package
of the program that has not been updated with the change to the
program, generate an updated package of the program by adding the
code file to the retrieved package of the program such that the
updated package of the program logically represents a package of
the updated program, and distribute the updated package of the
program to an end user computing device. In this aspect,
additionally or alternatively, to add the code file to the
retrieved package of the program, the one or more processors of the
distribution endpoint may be further configured to identify one or
more unchanged code files of the program from the retrieved
package, and generate a new package that includes the one or more
unchanged code files of the program identified from the retrieved
package and the code file including the change to the program. In
this aspect, additionally or alternatively, to add the code file to
the retrieved package of the program, the one or more processors of
the distribution endpoint may be further configured to add the code
file to the retrieved package of the program without repackaging
the program. In this aspect, additionally or alternatively, the
retrieved package of the program may include a plurality of
subpackages, and the one or more processors of the distribution
endpoint may be configured to add the code file to one or more of
the plurality of subpackages based on the change to the program. In
this aspect, additionally or alternatively, the change to the
program may be determined by a developer side application executed
on the developer computing device. In this aspect, additionally or
alternatively, the developer side application may be configured to
generate a footprint file that tracks the change to the program,
and send the footprint file to the distribution endpoint with the
code file. In this aspect, additionally or alternatively, the
footprint file may be programmatically generated by the developer
side application. In this aspect, additionally or alternatively,
the footprint file may be generated via user input. In this aspect,
additionally or alternatively, the program may be previously
packaged and signed by a developer side application executed on the
developer computing device. In this aspect, additionally or
alternatively, the program may be previously packaged and signed by
the distribution endpoint based on code files of the program
received from the developer computing device.
[0071] Another aspect provides a method comprising, at a processor
of a distribution endpoint of a computing system, receiving a
request from a developer computing device to update a program
managed by the distribution endpoint, the program being previously
packaged and signed, receiving a code file including a change to
the program, retrieving a package of the program that has not been
updated with the change to the program, generating an updated
package of the program by adding the code file to the retrieved
package of the program such that the updated package of the program
logically represents a package of the updated program, and
distributing the updated package of the program to an end user
computing device. In this aspect, additionally or alternatively,
adding the code file to the retrieved package of the program may
further comprise identifying one or more unchanged code files of
the program from the retrieved package, and generating a new
package that includes the one or more unchanged code files of the
program identified from the retrieved package and the code file
including the change to the program. In this aspect, additionally
or alternatively, adding the code file to the retrieved package of
the program may further comprise adding the code file to the
retrieved package of the program without repackaging the program.
In this aspect, additionally or alternatively, the retrieved
package of the program may include a plurality of subpackages, and
the method may comprise adding the code file to one or more of the
plurality of subpackages based on the change to the program. In
this aspect, additionally or alternatively, the change to the
program may be determined by a developer side application executed
on the developer computing device. In this aspect, additionally or
alternatively, the method may further comprise, at the developer
side application, generating a footprint file that tracks the
change to the program, and sending the footprint file to the
distribution endpoint with the code file. In this aspect,
additionally or alternatively, the footprint file may be
programmatically generated by the developer side application. In
this aspect, additionally or alternatively, the program may be
previously packaged and signed by a developer side application
executed on the developer computing device. In this aspect,
additionally or alternatively, the program may be previously
packaged and signed by the distribution endpoint based on code
files of the program received from the developer computing
device.
[0072] Another aspect provides a computing device comprising a
processor configured to receive an update to a program stored on
the computing device, the program being previously packaged and
signed, determine a code file including a change to the program,
retrieve a package of the program that has not been updated with
the change to the program, and generate an updated package of the
program without repackaging he program by adding the code file to
the retrieved package of the program such that the updated package
of the program logically represents a package of the updated
program.
[0073] It will be understood that the configurations and/or
approaches described herein are exemplary in nature, and that these
specific embodiments or examples are not to be considered in a
limiting sense, because numerous variations are possible. The
specific routines or methods described herein may represent one or
more of any number of processing strategies. As such, various acts
illustrated and/or described may be performed in the sequence
illustrated and/or described, in other sequences, in parallel, or
omitted. Likewise, the order of the above-described processes may
be changed.
[0074] The subject matter of the present disclosure includes all
novel and non-obvious combinations and sub-combinations of the
various processes, systems and configurations, and other features,
functions, acts, and/or properties disclosed herein, as well as any
and all equivalents thereof.
* * * * *