sfdk-deploy

Deploy using a specified method (pkcon, rsync, sdk, zypper, zypper-dup or manual)

$ sfdk deploy --[method]

$ sfdk deploy --[method] [[-n|--dry-run]]

$ sfdk deploy --[method] "+package*"

$ sfdk deploy --[method] "-ignore*"

$ sfdk undeploy --[method]

sf deploy source [--source-dir <path> | --manifest <path> | --metadata <string>]
[--api-version <string>] [--async] [--check-only] [--dry-run] [--ignore-warnings]
[--json] [--max-poll <integer>] [--test-level <string>] [--target-org <string>]

--source-dir
    Specifies the local directory containing the source to deploy. Ideal for deploying changes from a specific project path or workspace.

--manifest
    Points to a manifest file (package.xml) that explicitly lists the metadata components to be deployed. Useful for precise and controlled deployments.

--metadata
    Provides a comma-separated list of specific metadata component names or types to deploy. Allows targeted deployment of individual components directly.

--api-version
    Sets the API version for the deployment operation. Ensures compatibility with the target org's current API version.

--async
    Executes the deployment operation asynchronously, allowing the CLI to return control to the terminal while the deployment proceeds in the background.

--check-only
    Performs a validation deployment without actually saving any changes to the target org. Critical for pre-deployment checks and validating metadata dependencies.

--dry-run
    An alias for --check-only, offering a clearer indication of its validation-only purpose, simulating a deployment without actual changes.

--ignore-warnings
    Allows the deployment to proceed even if warnings are encountered, preventing the command from failing due to non-critical issues during deployment.

--json
    Outputs the command results in JSON format, facilitating programmatic parsing and integration with automated scripts or CI/CD pipelines.

--max-poll
    Defines the maximum number of minutes to wait for the deployment command to complete before timing out. Defaults to 360 minutes.

--test-level
    Determines which Apex tests run during deployment (e.g., NoTestRun, RunSpecifiedTests, RunLocalTests, RunAllTestsInOrg). Essential for code coverage and validation.

--target-org
    Specifies the username or alias of the Salesforce org to which the source will be deployed. This is a crucial parameter for directing deployments.

The command `sfdk-deploy` is assumed to refer to the Salesforce CLI's modern `sf deploy source` (or its predecessor `sfdx force:source:deploy`) command. It is used to transfer local Salesforce metadata and source code, such as Apex classes, Lightning web components, and custom objects, from a development environment to a Salesforce org (e.g., sandbox, production, or scratch org). This command is fundamental for Salesforce development workflows, enabling developers to push their changes for testing, integration, or release. It supports deploying from a specified directory, a manifest file (package.xml), or individual metadata components, offering flexibility for various deployment strategies and CI/CD pipelines.

The command `sfdk-deploy` is not a standard Linux command; this analysis assumes it refers to the Salesforce CLI command `sf deploy source` (or its predecessor `sfdx force:source:deploy`).
Users must have the Salesforce CLI installed and be authenticated to a Salesforce org.
Deployment operations require stable network connectivity to Salesforce servers.
Some metadata types may have limitations or specific requirements when deployed via the Salesforce Metadata API, which this command leverages.

This command is highly versatile, supporting various deployment scenarios: from pushing incremental changes to scratch orgs during active development, to deploying validated feature sets to sandboxes for testing and UAT, and finally to production environments for release. It scales to different project sizes and complexities.

Upon completion, the command provides comprehensive success or failure messages. In case of errors, it offers detailed reports, including compilation issues, missing dependencies, validation rule failures, or insufficient code coverage. This robust feedback mechanism is vital for efficient troubleshooting and debugging deployment issues.

Initially, Salesforce deployments were primarily managed via the Metadata API (e.g., using the Ant Migration Tool). With the advent of Salesforce DX, `sfdx force:source:deploy` emerged as a foundational command for source-driven development, particularly with scratch orgs. More recently, Salesforce unified its CLI under the `sf` executable, streamlining command syntax. `sfdx force:source:deploy` was simplified to `sf deploy source`, offering a more intuitive and consistent experience while maintaining its core functionality for deploying source code and metadata.

sf retrieve source(1), sf project deploy start(1), sf deploy mdapi(1), sf validate deploy(1)