Use Development and Application Lifecycle Workflow
As you develop a Function, you'll need to integrate your Function code into your development and application lifecycle workflow. This can include tasks like:
- Collaborating on Function development with other developers on your team.
- Adding Functions to your application lifecycle management process to ensure Functions are properly verified in a sandbox environment before being deployed to production.
- Automating parts of your workflows, such as using automated testing and deployment of Functions.
Because Functions do not get deployed directly to your org, you need to use additional DX tools and commands to integrate Functions in your workflow.
Because Function code isn't deployed or saved to your org, you'll need to save your Function project in a source code control system. You can use git repos on github.com to save your Function code, along with the rest of your DX project. Once your Functions project is in GitHub, you can use git branches, merges, and pull requests to track and safely merge development changes across your team.
To add an existing Salesforce Functions project to github.com, see Add Project to github.
When making Salesforce Functions project changes, always start by creating a branch in your git repo. Work in this branch as you make changes to your Functions code, or org-side changes like permission set changes. Once you're ready to test in a scratch or sandbox org, be sure to commit first. Once you've verified your changes, you push merge your project commit, create a pull request for review, and merge your reviewed changes back to your repo.
To integrate your Functions development and deployment in your application lifecycle management (ALM) process, you'll need to:
- Plan your Functions development. Understand what compute work your Function will be doing, what permissions your Function will need, and where a user will be invoking your Function from. Determine what language-specific packages beyond the Salesforce SDKs your Function might need. Understand which development, test, and integration orgs you'll need to create.
- Develop your Function. Develop and debug Functions locally using VS Code. Use git and GitHub to track Functions project changes and coordinate changes across your development team. Develop your Apex code and any org-side changes needed to invoke the Function.
- Test your Function in a development org. Test your Function locally and then deploy and test in your development (scratch or sandbox) orgs. Use scratch orgs to test just your changes, or use development sandbox orgs to coordinate testing with others on your team.
- Deploy your Function to your integration sandbox orgs. Create compute environments based on your preferred set of sandbox orgs used for testing.
- Test your Function in your integration sandbox orgs.
- Release (deploy) your Function to your production org.
Here's a simplified example walkthrough of some of the above steps for a developer on a team developing Functions. This walkthrough assumes that the development team already has a DevHub org with Functions enabled, and each team member has the appropriate DX tools installed.
- For initial planning, the team determines that a new development sandbox and integration sandbox will be needed, so the developer creates these, either via the Salesforce UI, or via CLI commands like the following:
- The developer logs into the Dev Hub and dev and integration sandbox orgs. The developer also authenticates the Salesforce CLI to Salesforce Functions:
The developer creates a new project and commits it to git for everyone to work on:
Now, the developer can create a branch and develop Function code, Apex code, etc:
At this point the developer can also run the Functions locally using a scratch org.
- The developer has done some local testing using scratch orgs, and now wants to test in the development sandbox. They need to first ensure they've done a git commit for their project:
Next they need to create a compute environment for their developer sandbox. This only needs to be done once, and other developers on the team can deploy to the same compute environment:
The developer can then deploy the Functions project to the compute environment connected to the development sandbox for testing:
And finally the developer pushes whatever org-side changes, such as Apex classes, to the development sandbox directly:
At this point the developer can test the Functions and org-side changes in the development sandbox.
- Once testing has been completed, the developer wants to deploy and test in the integration sandbox. First, the developer pushes their git branch to GitHub:
The developer uses the github web UI to create a pull request and get a review from someone on the team before merging into the integration branch. Once the changes are merged, the developer pulls the integration branch to make sure he has all the latest changes for that branch before he deploys:
Next the developer creates a compute environment for the integration sandbox. Again, this needs to be done once:
The developer is ready to deploy his Functions to the integration sandbox compute environment, and any org changes to the integration sandbox:
The developer can now test and validate the Functions and org-side changes in the integration sandbox.
Once all the testing and validation is complete, a user with production access (either Salesforce or Functions admin user) can deploy this Function to a production org:
- Clone the GitHub project and switch to the correct branch.
- Navigate to the correct branch.
- Log into the production org.
- Log into functions.
- Create a compute environment for the production org.
- Deploy your function to the compute environment and push source files to the production org.
- Invoke your function as needed by your workflow.
See Deploy a Function for details.
Bring your own Continuous Integration/Continuous Deployment (CI/CD) service and automatically deploy code using the Salesforce CLI. The general process is as follows:
- Enable functions in the production org. In Setup > Functions, click Enable Production. For more information see Configure Orgs for Functions.
- Create a Connected App in the production org and copies the keyfile to the CI/CD server. For more information see Create a Connected App.
- Set your JWT authentication variables to work with your CI/CD configuration.
sf login functions jwtto authenticate. The
jwtoption uses a single command to log into both the org and functions, instead of two commands. For example:
This example references the private key in a separate file. Since the private key is a multiline file, the shell interpretation may misread the file and throw the following error:
Error: error:0909006C:PEM routines:get_name:no start line Code: ERR_OSSL_PEM_NO_START_LINE. You can use different strategies depending on your environment to reference the private key in other ways. For example, quote the file contents or base-64 encode the file and use it as an environment variable.
- In GitHub, a pull request is approved and merged into main. The CI/CD server detects the change to main, then executes the required CLI commands to test and deploy the changes to the production environments.
For an example project that uses CircleCI and github to automate testing of a Function, see Example of testing Functions with CircleCI.
For more information on continuous integration, see Continuous Integration in the Salesforce DX Developer Guide.