May 11, 2020
- A famous thespian, or perhaps it was a Salesforce visionary, once said, “All the world’s an org.”
- In the org-based model, your production org is the source of truth for all your code, configuration, and customization.
- Even if you have multiple teams working on separate development projects, they develop and release their updates with the same deployment. Everything goes into one package.xml.
- Package Development : Instead of building code and customizations for the org, you create a package (a logical set of code). A package is a release artifact that is a group of related code and customizations.
- With this new process, you’re able to organize your org into a set of packages.
- You store all source for your packages in a source control repository, where the source of truth is maintained.
- You build scratch (development) orgs from that source, so you can work specifically on your package.
- Package development gives you more flexibility in managing your teams and releases. You can assign teams to own a particular package. Development teams can develop separately and build toward a release of the package, and not a release of updates to the org. With this agile model, you can have more frequent, independent releases, as you can see in the development, build, and deploy flow.
- For our enterprise customers, we have a special package type, called unlocked packages (GA), which are especially suited for internal business apps.
- Source : https://trailhead.salesforce.com/en/content/learn/modules/sfdx_dev_model/sfdx_dev_model_neworganization?trail_id=sfdx_get_started
Tools which helps in Package Development Model
- Salesforce CLI –> You can script everything from the creation of orgs to the import and export of data–everything required to manage the full development life cycle.
- Developers can use it to manage their DX projects, create scratch orgs, push and pull metadata to and from a scratch org, and run unit tests.
- DevOps can use it as part of build automation scripts: to create and access environments, to deploy source, to install packages, and to run tests.
- Salesforce Extensions for VS Code
- Scratch Orgs -> And you can share the scratch org configuration file with other team members.
- Scratch orgs don’t have the capacity to contain the entire happy soup of metadata contained in your production org. Also, they weren’t meant to replace sandboxes either.
- Align source development use cases to your scratch orgs, and align release and deployment testing to your sandboxes.
- Scratch Org is a dedicated and disposable salesforce environment for a developer and their project
- Source : https://trailhead.salesforce.com/content/learn/modules/sfdx_dev_model?trail_id=sfdx_get_started
Source – Driven Development
- The Salesforce DX project reflects this package-based approach to organizing your source.
- A Salesforce DX project is a local directory structure of your metadata in source format. It lets you develop and test with Salesforce DX tooling.
- It contains configuration files for creating scratch orgs. It can contain data to be loaded into orgs for development or testing. It also contains tests that you rely on to validate your package.
- At a minimum, the project manages the source for one package. That being said, if multiple packages get built and released together, you can organize these packages into a single DX project. Each of your packages aligns to a package directory defined in the project configuration file.
- After you create a scratch org, you still have some setup tasks to complete. You push all source from the project to the scratch org, set up permissions, and create or load any test data that your package requires.
- While the IDE or text editor is available for programmatic (code-based) development, you can use the scratch org for declarative (point-and-click) development. This process is similar to what you do in your sandbox or production org. What’s different in the source-driven model is that you synchronize any development you did in the scratch org with your local project. This synchronization lets you commit changes made in the Setup pages alongside changes made in your local IDE.
- A key feature of Salesforce DX is that you can easily keep your project and scratch org in sync. So you can put away those sticky notes! You no longer have to jot down what you changed in your local file system, IDE, or editor, or what you changed in your org.
- Salesforce DX tracks any change you make locally in the project and any changes you have made in your scratch org.
- Before you push source changes to the scratch org, or pull changes to your local project, you can view a list changes you’ve made. That’s the power of the Salesforce CLI in action.
- DX project format breaks down large source files to make them more digestible and easier to manage with a version control system. For example, Salesforce DX transforms custom objects and custom object translations into multiple files and directories. This source structure makes it much easier to find what you want to change or update. Smaller files in source control mean fewer merge conflicts during team development. Say bye-bye to messy merges!
- Source : https://trailhead.salesforce.com/content/learn/modules/sfdx_dev_model/sfdx_dev_model_sdd?trail_id=sfdx_get_started
Start
- At the start of a project, you can retrieve metadata source from an org and convert it to source format, then store it in a VCS. Once you’ve created and tested your app or customizations, you’re ready to create the deployment artifact. You can convert from source format back to metadata format, and then all your source is ready to deploy to a scratch org. You can deploy all the source, and the deploy operation takes care of updating the files that have changed. You can omit certain files from the deployment, and construct exactly what to deploy by modifying the package.xml file created during the convert process.
Scratch Orgs
- Setup -> DevHub -> Enable
- install CLI
- enter SFDX into CLI
- to authenticate an Devhub org: sfdx force:auth:web:login -d -a DevHub
- Adding the -d flag sets this org as the default Dev Hub. Use the -a to set an alias for the org (something catchy like DevHub). An alias is much easier to remember than the unique Dev Hub username.
- sfdx force –help
- sfdx force:doc:command:list
- sfdx force:org:list
- sfdx force:org:open -u DeHub