Artifact Preparation and Deployment Process
This document outlines the process of preparing an artifact ZIP based on selected revisions, along with an example for better understanding.
Example Scenario
Git Logs: (A is the latest revision)
A → B → C → D → E → F → G → H → I → J
Selected Revisions: B, C, F, G, J
Artifact Creation Process
Ensure Revision XML Files For each selected revision, ensure the presence of a corresponding revision XML file containing:
Commit details
List of added, modified, or deleted files If any XML file is missing, it is dynamically generated.
Gather Changed Files Collect all added, modified, or deleted files from the selected revisions (
B, C, F, G, J
) using the XML files.Checkout the Latest Revision Switch to the latest selected revision (e.g.,
B
).Copy Files to Package Directory Copy all gathered files into a package directory from the checkout of the latest selected revision.
Prepare Deployment Files Generate
package.xml
anddestructiveChanges.xml
within the package directory.Create the Artifact ZIP Archive the package directory, which includes the selected files and metadata files. This ZIP file is used for custom deployments.
Deployment Process
1. Full Deployment
Retrieve the artifact ZIP from:
.rabit → scm → changelabel → {repo_id} → {release_label_id}.zip
Deploy the ZIP as-is.
2. Selective Deployment
For selective deployments:
Retrieve
package.xml
anddestructiveChanges.xml
from:scm → scmcommithistory → {repo_id} → {branch_name} → {release_label_name}
Display metadata components in the UI for user selection.
Based on selection, extract corresponding files from the artifact ZIP for deployment.
If deployment issues occur, these paths serve as the source of truth for verification.
Implementation Considerations
Consideration 1: Potential Missing Files in the Artifact ZIP
Scenario: Files may be missing from the ZIP even if their revisions were selected.
Example:
Git Log: A → B → C → D
Changes:
A
:A.cls
modifiedB
:C.cls
deletedC
:C.cls
modifiedD
:D.cls
modified
Selected Revisions: A, C, D
Result:
The ZIP contains A.cls
and D.cls
, but not C.cls
.
Reason:
The latest selected revision is A
. Since C.cls
was deleted in B
, it doesn’t exist in the checkout of A
, and thus is excluded.
Consideration 2: No Delta Support for Release Labels
Scenario: Release labels do not currently support delta metadata logic, which may result in:
Unintended inclusion of extra metadata
Missing specific modifications
Example:
Adding a CustomLabel
results in the entire CustomLabels.labels
file being included, even if only one label was changed.
Repository Type Exceptions
1. Non-DX Repositories
Modifying a CustomField
includes the entire CustomObject
file, which contains all child metadata (e.g., CustomField
, RecordType
).
2. DX Repositories
Only the specific CustomField
file is included, as metadata is stored modularly.
Summary
These behaviors are a result of the system's current file-level change tracking and repository structure. Supporting delta-level preparation would require significant architectural changes, particularly in how the system identifies and retrieves file differences.
Last updated
Was this helpful?