Build a Package from Salesforce
Last updated
Was this helpful?
Last updated
Was this helpful?
Create a package from a Salesforce org based on a "Start Date" and deploy or validate the same package onto a different . Configure the job to run functional test cases from version control.
Log in to your ARM account.
From the top navigation pane, navigate to Create New > New CI Job.
Choose the tile: Package from Salesforce
On the next screen, give the job a descriptive name in the Job Name field.
Add a brief description of the current CI job.
To group your CI job for easier identification, choose the group from the dropdown. You can create a new group using the "+" symbol and assign your current and further CI jobs to such a group.
Here, the user interface is separated into different sections, we will cover each one of them separately.
Under the Build section, fill in the below details:
Select the Package type to retrieve and bundle the changes from a source sandbox.
Unpackaged Mode: This fetches the metadata members in your org that have got modified from the last ARM cycle. On selection, specify a date in the Start Date field from which changes in Salesforce Org will fetch. If a date is not specified, then the project creation date will become the start date and changes will get fetched.
Managed packages: Salesforce partners use these packages to distribute and sell applications to their users. These packages get created from a Developer Edition organization. For more information, refer to the link below:
Additional Build options
Auto switch to bulk retrieve service, if job is hitting metadata retrieving governor limit: This option is useful in running large jobs that would exceed normal processing limits. As per the Salesforce governor limit, you can deploy or retrieve up to 10,000 files at once or a max size of 39 MB. Using Batch Size, you can process metadata in batches to stay within platform limits. If you do not have a lot of metadata, processing records through batches are your best solution. Specify the batch size for both profile and remaining components to retrieve metadata types. 10 K is the max batch size that you can set per batch.
Exclude Installed (Managed) components and changes: This option will exclude any Managed packages that the user may have installed.
Exclude all manually created components: All manually added components in the installed (managed) package will also get excluded.
Generate Code Coverage Report: This option generates a code coverage report. This has info about the apex tests run, the classes covered, and the assertions that have failed.
Run Static Analysis Report: This will identify potential software quality issues before code moves to production.
For ApexPMD and Salesforce Scanner: ARM allows you to set the criteria for running the ApexPMD SCA tool. This means running for all the apex classes or stating the period from where it will run. Also, you can set the priority, which means if the priority set is not achieved, the current build is unstable. This helps us in reporting the code quality of the developer team.
Run on all supported Metadata types: Analysis is performed on all the supported metadata types. For example, if the build includes 2 classes and 2 triggers, then the analysis will run on all the supported components that are retrieved for these 2 classes and 2 Triggers in the build.
Run on Newly added supported Metadata types: Analysis is performed only on those components which are received during build retrieval. For example, if there are added as well as modified components in the build, then the analysis runs on the newly added components, not on the modified components.
Additional Profile Packaging Options:
Remove login IP Ranges: If you want to log in with a Salesforce org, you have an option to restrict IP ranges. Upon selection, login IP details will not be deployed to Salesforce Org.
Remove System and User Permissions: System permissions control a user’s ability to perform tasks that apply to their VCS or Org. To not deploy this permission, select this option.
Exclude Metadata Types: These exclude the metadata no longer required for build/deployment. To avoid fetching unwanted metadata types during a CI job, ensure that you have excluded them. If the 'Exclude Metadata Types' checkbox is not checked, all metadata types will get chosen. That globally excluded metadata will be auto-populated if you select this option.
Send email notifications to selected users email on the success or failure of a build.
Allows you to schedule the process at which it must run.
Daily: The process will run every day at the scheduled time or time interval set.
Weekly: The process will run weekly on the scheduled day and time.
No schedule: The process will only get saved, and you can run it when required.
Select the source .
Unmanaged packages: These provide developers with basic building blocks for an application as application templates. The user can edit the components after installing this package in a .
Include Picklist modifications: Whenever a picklist value gets altered or deleted, SF will not update the picklist's last altered date. Whether the picklist value gets altered or not, it will pull all the picklist fields into the source org. This option is available only if the source is a .
For and SonarQube: Set the criteria for running the CodeScan or SonarQube tool, whether to run on the supported metadata types from the full source or to run on the newly added components. This means running for all the apex classes or stating the period from where it will run. Also, you can set the priority, which means if the priority set is not achieved, the current build is unstable. This helps us in reporting the code quality of the developer team.
For more information on running Static Code Analysis in CI Jobs, refer .
Important Note: To set this option at a global level, go to the 'My Salesforce Settings' section on the page. Next, select the metadata types to exclude. This reflects in all CI jobs that get created henceforth and across other modules as well.
For more information on Credential Usage for different types of CI jobs, refer .
Once you filled in all the details for your CI job, you will be redirected to the page where you can trigger a build for your CI job.
