This repository has been archived by the owner on Oct 16, 2024. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
ELIZABETH DEGROOT
committed
Jul 24, 2019
1 parent
839114f
commit faf6917
Showing
1 changed file
with
54 additions
and
50 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -1,58 +1,62 @@ | ||
# Salesforce App | ||
<h1 align="center">Trailhead Packaging Permission Sets Project</h1> | ||
This project contains the sample custom objects and custom tab for the Trailhead project 'Packaging Permission Sets with Salesforce DX'. | ||
|
||
This guide helps Salesforce developers who are new to Visual Studio Code go from zero to a deployed app using Salesforce Extensions for VS Code and Salesforce CLI. | ||
=========================== | ||
### Contents: | ||
- [Tool Versioning](#tool-versioning) | ||
- [Resources](#resources) | ||
|
||
## Part 1: Choosing a Development Model | ||
=========================== | ||
### Tool Versioning | ||
| Tool: | Version: | | ||
| ------------ | ---------- | | ||
| **SFDX-CLI** | ![npm](https://img.shields.io/npm/v/sfdx-cli.svg?label=SFDX-CLI&logo=Salesforce&style=Popout) | | ||
|
||
There are two types of developer processes or models supported in Salesforce Extensions for VS Code and Salesforce CLI. These models are explained below. Each model offers pros and cons and is fully supported. | ||
=========================== | ||
### The Project Overview | ||
|
||
### Package Development Model | ||
|
||
The package development model allows you to create self-contained applications or libraries that are deployed to your org as a single package. These packages are typically developed against source-tracked orgs called scratch orgs. This development model is geared toward a more modern type of software development process that uses org source tracking, source control, and continuous integration and deployment. | ||
|
||
If you are starting a new project, we recommend that you consider the package development model. To start developing with this model in Visual Studio Code, see [Package Development Model with VS Code](https://forcedotcom.github.io/salesforcedx-vscode/articles/user-guide/package-development-model). For details about the model, see the [Package Development Model](https://trailhead.salesforce.com/en/content/learn/modules/sfdx_dev_model) Trailhead module. | ||
|
||
If you are developing against scratch orgs, use the command `SFDX: Create Project` (VS Code) or `sfdx force:project:create` (Salesforce CLI) to create your project. If you used another command, you might want to start over with that command. | ||
|
||
When working with source-tracked orgs, use the commands `SFDX: Push Source to Org` (VS Code) or `sfdx force:source:push` (Salesforce CLI) and `SFDX: Pull Source from Org` (VS Code) or `sfdx force:source:pull` (Salesforce CLI). Do not use the `Retrieve` and `Deploy` commands with scratch orgs. | ||
|
||
### Org Development Model | ||
|
||
The org development model allows you to connect directly to a non-source-tracked org (sandbox, Developer Edition (DE) org, Trailhead Playground, or even a production org) to retrieve and deploy code directly. This model is similar to the type of development you have done in the past using tools such as Force.com IDE or MavensMate. | ||
|
||
To start developing with this model in Visual Studio Code, see [Org Development Model with VS Code](https://forcedotcom.github.io/salesforcedx-vscode/articles/user-guide/org-development-model). For details about the model, see the [Org Development Model](https://trailhead.salesforce.com/content/learn/modules/org-development-model) Trailhead module. | ||
|
||
If you are developing against non-source-tracked orgs, use the command `SFDX: Create Project with Manifest` (VS Code) or `sfdx force:project:create --manifest` (Salesforce CLI) to create your project. If you used another command, you might want to start over with this command to create a Salesforce DX project. | ||
|
||
When working with non-source-tracked orgs, use the commands `SFDX: Deploy Source to Org` (VS Code) or `sfdx force:source:deploy` (Salesforce CLI) and `SFDX: Retrieve Source from Org` (VS Code) or `sfdx force:source:retrieve` (Salesforce CLI). The `Push` and `Pull` commands work only on orgs with source tracking (scratch orgs). | ||
|
||
## The `sfdx-project.json` File | ||
|
||
The `sfdx-project.json` file contains useful configuration information for your project. See [Salesforce DX Project Configuration](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_ws_config.htm) in the _Salesforce DX Developer Guide_ for details about this file. | ||
|
||
The most important parts of this file for getting started are the `sfdcLoginUrl` and `packageDirectories` properties. | ||
|
||
The `sfdcLoginUrl` specifies the default login URL to use when authorizing an org. | ||
|
||
The `packageDirectories` filepath tells VS Code and Salesforce CLI where the metadata files for your project are stored. You need at least one package directory set in your file. The default setting is shown below. If you set the value of the `packageDirectories` property called `path` to `force-app`, by default your metadata goes in the `force-app` directory. If you want to change that directory to something like `src`, simply change the `path` value and make sure the directory you’re pointing to exists. | ||
|
||
```json | ||
"packageDirectories" : [ | ||
{ | ||
"path": "force-app", | ||
"default": true | ||
} | ||
] | ||
# Set Up the Salesforce DX Project | ||
Our first goal is to set up a developer project which we'll use to modify our application. It starts by cloning the repository. Use the command ... | ||
``` | ||
git clone https://github.com/developerforce/sfdx-package-profiles-to-permsets | ||
``` | ||
… or ... | ||
``` | ||
git clone [email protected]:developerforce/sfdx-package-profiles-to-permsets | ||
``` | ||
… to clone the repository. Then, open the directory. | ||
``` | ||
cd sfdx-package-profiles-to-permsets | ||
``` | ||
# Authorize Dev Hub in your Trailhead Playground | ||
Log into your Dev Hub org. | ||
``` | ||
sfdx force:auth:web:login -d -a "Hub Org" | ||
``` | ||
Proceed to log in with your dev hub credentials. | ||
|
||
## Part 2: Working with Source | ||
|
||
For details about developing against scratch orgs, see the [Package Development Model](https://trailhead.salesforce.com/en/content/learn/modules/sfdx_dev_model) module on Trailhead or [Package Development Model with VS Code](https://forcedotcom.github.io/salesforcedx-vscode/articles/user-guide/package-development-model). | ||
|
||
For details about developing against orgs that don’t have source tracking, see the [Org Development Model](https://trailhead.salesforce.com/content/learn/modules/org-development-model) module on Trailhead or [Org Development Model with VS Code](https://forcedotcom.github.io/salesforcedx-vscode/articles/user-guide/org-development-model). | ||
|
||
## Part 3: Deploying to Production | ||
If you already have an authorized Dev Hub, set it as the default: | ||
``` | ||
sfdx force:config:set defaultdevhubusername=<username|alias> | ||
``` | ||
|
||
Don’t deploy your code to production directly from Visual Studio Code. The deploy and retrieve commands do not support transactional operations, which means that a deployment can fail in a partial state. Also, the deploy and retrieve commands don’t run the tests needed for production deployments. The push and pull commands are disabled for orgs that don’t have source tracking, including production orgs. | ||
# Create a scratch org | ||
``` | ||
sfdx force:org:create -s -f config/project-scratch-def.json | ||
``` | ||
|
||
Deploy your changes to production using [packaging](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_dev2gp.htm) or by [converting your source](https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference_force_source.htm#cli_reference_convert) into metadata format and using the [metadata deploy command](https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference_force_mdapi.htm#cli_reference_deploy). | ||
If you want to use an existing scratch org, set it as the default: | ||
``` | ||
sfdx force:config:set defaultusername=<username|alias> | ||
``` | ||
# Push the source to your scratch org | ||
``` | ||
sfdx force:source:push | ||
``` | ||
# Open the scratch org. | ||
``` | ||
sfdx force:org:open --path one/one.app | ||
``` | ||
=========================== | ||
### Resources | ||
For details on using sfdx-simple, please review the [Salesforce DX Developer Guide](https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev). |