Package definitions define lists of files for use during builds, deploys, and in release definitions. Package details can change during the development life cycle as necessary.
| Table of Contents | ||||
|---|---|---|---|---|
|
Overview
Packages are uniquely defined in each package-based project so you can have a package with the same name in multiple projects if necessary. The package list is shown on the Packages tab.
The Package list displays all packages for the project. On page load, the filter will be defaulted to show only "Active" packages with the most recently modified on top.
On the package list screen, there are several actions available.
Action | Notes |
|---|---|
Create (1) | Create new package. |
Edit / View (2) | Click on package name to edit or view package details. |
Delete (3) | Delete selected package. Executions for the package will not be deleted. If package is configured in Release, delete is not allowed. |
Update Status | Inactivate, Activate, or mark the package complete. |
There are dynamic columns "Latest Version" and environment based columns afterwards. Latest version displays the latest successful build for the given package and a link to the execution. Similarly, the environment based columns between "Latest Version" and "Updated On" show the latest deployment version to each environment for that given package. Every environment associated to this projects deployment target group(s) will display a column with the environment name as its column header. These dynamic columns are sorted by the sort order defined in Topology → Environment. Clicking on these links for latest version or deployment version will navigate to the corresponding project workflow execution details.
When a user clicks on the package name button, the package execution screen appears.
Click Edit Package to make changes if necessary.
Only Salesforce projects have the Test Level and Tests settings.
Package Statuses
A Package can have multiple statuses that represent where it happens to be in its lifecycle.
Active
Active packages are packages that are actively being built and deployed. This is the default status for any new Package.
Inactive
Inactive packages can no longer be built or deployed. They can however be moved back into an Active status at any point.
Completed
Completed packages, like Inactive, cannot be built or deployed. Unlike Inactive, Completed packages remain in a completed state indefinitely.
| Note |
|---|
Only mark a package Completed when you are certain it is no longer required. |
Package Types
The package type can be defined as User Managed or Dynamic.
User Managed
With User-Managedpackages, the user manages the content and sort order.
Dynamic
With dynamic packages, the content and sort order are managed dynamically based on an include path and/or exclude path. The include/exclude paths are regular expressions matching the project file path to determine which project files should be included or excluded from the package. More than one include or exclude path can be defined by adding that new path on the next line. By default, new packages are set to User Managed type, as well as for Salesforce DX packages created from the SFDX.json file.
Note that when new files are populated from Project Files tab all dynamic packages are updated accordingly. This can be a big productivity gain when the contents of the package can be derived according to some rules.
Below is an example of a dynamic package that includes all the .profile files of the project.
Include/Exclude Examples
Include | Exclude | Description |
|---|---|---|
| Include all | |
| Include any file ending in a | |
| Include any file as long as it is somewhere under a folder named | |
|
| Include all |
| Include all files except files ending in Alternative it can be written as a single exclude: |
Building a Package
To build a package, go to the execution screen and click Build.
Associating Work Items to a Package
Packages typically correlate to a smaller subset of work which more often than not relates to a work item in an Issue Tracking System like Jira. Packages that fall in this bucket can link the relevant work items directly to the package. Doing this saves the hassle of having to mention the work item number in the commit message or manually specifying it on the build request form.
| Warning |
|---|
Before work items can be linked to a package, the project must inherit or specify its own ITS Configuration. |
To associate work items to a package, edit the package as demonstrated above, and in the Related Work Items field, you can search and select or manually enter work item numbers. For instances using FlexDeploy ITS, Jira, or Azure Boards, all external tickets are searchable in the list. For other ITS providers, the list will only display previously built/linked work items that FlexDeploy is aware of, but the full work item number can still be entered to link work items not displayed.
Once associated (1), work items will be automatically associated during the build process (2).
Add File(s) from Change Logs
When the user clicks on Add File(s) from the Change Logs button, the search and select file revision screen is displayed, as shown below. Clicking a revision will add all files that were changed in that commit to this package.
Click on the down arrow to show the files that were in the commit. Click on the commit row to prepare to add all the files in that commit to the package.
Click Add to add the files.
View Dependencies
If the project's type supports dependencies, you will see an additional View Dependencies button on this edit package screen. When the user clicks the View Dependencies button, FlexDeploy will show all dependencies that have been analyzed for the files in the package. From this popup, you can select any dependent files to add to your package and re-analyze dependencies. Note that files that haven't been committed to source control or discovered for this project cannot be added to your package.
Add Subcomponents
If the project's type supports subcomponents you will see an additional Add Subcomponents option for file types that support subcomponents. When you click the Add Subcomponents option, FlexDeploy will find all supported subcomponents for the selected file. This allows users to build and deploy only certain parts of a specific file. From this popup, you can preview and select any subcomponents to add to your package. You are able to select the branch that the selected files are sourced from if the project uses an SCM, or the Salesforce Org account if the project type is Salesforce and SCM type is set to NONE. When selecting a Salesforce Org from the drop down, FlexDeploy will attempt to source the specified files from that Salesforce Org and break the files down into subcomponents based on the content of the file from the Salesforce Org.
Support of Destructive Packages
If the project's type supports Destructive feature, you will see this option. This functionality aids in maintaining the cleanliness of your Salesforce Org by facilitating the removal of retired or unnecessary components. You can mark one or multiple files in any package as destructive. The migration of these deletions involves appropriate approvals, ensuring visibility and auditability. To mark a file as destructive, simply right-click on it within your package and select the "Destructive" option.
Copy to Package / Move to Package
When a user selects one or more files and right clicks, Copy/Move Files to Package and Remove are available action options.
Search for existing packages in the project to copy files to or create a new package to copy files to. Note that your current context will not change.
| Info |
|---|
Package EditablePackages with a status of Completed or Inactive cannot be built or deployed. Once a package becomes Completed, it can no longer be edited. Packages that are a part of an active release cannot be set to Inactive. Since FlexDeploy 8.0, Completed packages can be made Active. |