Project Packages
- Chandresh Patel
- Emily Simon
- Jay-Ar Brouillard
Package definitions define lists of files for use during builds and deploys and in release definitions. Package details can change during the development life cycle as necessary.
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. |
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.
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-Managed packages, 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 Issues to a Package
Packages typically correlate to a smaller subset of work which more often than not relates to an issue in an Issue Tracking System like Jira. Packages that fall in this bucket can link the relevant issues directly to the Package. Doing this saves the hassle of having to mention the issue number in the commit message or manually specifying on the build request form.
Before Issues can be linked to a Package the Project must inherit or specify its own ITS Configuration.
To associate Issues to a package, Edit the Package as demonstrated above and in the Related Issues field you can manually enter Issue Numbers. You will also be shown previously linked Issues that FlexDeploy is aware of.
Once associated (1), Issues will be automatically associated during the build process (2).
Add File(s) from Change Logs
When user clicks on Add File(s) from Change Logs button, the search and select file revision screen is displayed, as show 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 which 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.
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.
Package Editable
Packages 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 Completed or Inactive.
Related content
- style