On our recent webinar Modern App Dev: Modular Development Strategies, we saw lots of great questions come in from our (wonderful and super sharp) attendees. We’re tackling the most common ones (that we didn’t get to during the webinar) here.
What tools were you all using?
We showed you a few different tools:
- VS Code (the IDE we both used)
- Salesforce CLI
- Salesforce Extensions for VS Code (find installation instructions here)
- If you scroll down on the Marketplace Extensions site to the Documentation for Included Extensions section you can dig into the different extensions that are part of the extension bundle and their corresponding documentation. You can also check out the GitHub repository of the extensions, as it is an open-sourced project.
If you’re new to these tools, make sure to check out the resources at the end of this post.
Do we have to have use Salesforce DX or enable anything to get started? Can we just use sandboxes?
As we mentioned, Salesforce DX itself includes lots of tools and new features to help you build and deliver Salesforce apps. The Salesforce CLI, sandboxes, scratch orgs, Change Sets and unlocked packages could all be considered part of Salesforce DX.
So if you’re building and delivering apps on Salesforce (and not just building directly in production!), you’re already using pieces of Salesforce DX. But if you want to start building your apps and deploying changes in more modular, focused ways — yes, you’ll want to look at using more of the tools and features offered by Salesforce DX. But no, you don’t have to use every part of Salesforce DX in order to get started.
So what tools do you need to use to get started?
The real answer is the Salesforce CLI. You can install the CLI and use it to work with any kind of Salesforce org. If you want to get powerful connections to the Salesforce CLI from within your IDE, then you should also check out VS Code and the Salesforce Extensions for VS Code. Plus, there’s LOTS of other awesome stuff in those extensions.
As you work, you may find that you have to connect to a Dev Hub org in order to execute some CLI commands. We’ll talk more about that below.
Where can we activate a Dev Hub? Can sandboxes be Dev Hubs? Is there a cost to activating a Dev Hub?
Dev Hub functionality can only be enabled in production orgs and Developer Edition orgs. You can not use a sandbox as a Dev Hub org. There is no cost to enabling a dev hub functionality in an org. If you want to explore without enabling your production org as a Dev Hub, that’s fine. As of the Winter ’19 release, you can enable Dev Hub functionality in any Developer Edition org. (No more special sign-up!)
Be aware of that the type of org you use as your dev hub will determine the limits you’ll need to plan for as you work.
Do developers have to have access to Production to use Salesforce DX?
Developers on your team do not have to have access to your production environment to use VS Code + Salesforce Extensions, or the Salesforce CLI. They do need to be able to authenticate into any orgs you expect them to build in, fetch metadata from or deploy changes to. Also refer to the Modify Metadata Permission (in beta), which allows you to give access to an orgs Metadata only.
If you’ve enabled a production org as a Dev Hub, then you’ll want to figure out how you want developers authenticating into that org. There are a few options for managing this. In our demo, we used the force:auth:web:login command to authenticate into to an org with a username/password combination in a browser window. That’s just one of the different ways you can use the CLI to authenticate against orgs. Check out the CLI Command Reference for more.
We’re a new team moving to Salesforce and Salesforce DX. How should we get started?
You should check out our Getting Started with Salesforce DX series. You should make sure you get set up with the Salesforce CLI, VS Code + Salesforce Extensions. Also, look at choosing a source control system, if you don’t already have one set up.
Start thinking now about how you might want to organize your metadata into units within source control. You can check out this post on using deployment dependencies to structure metadata into units for ideas.
How do we get started pulling stuff out of our org and into source? How can we start managing dependencies?
You should start small. As you start to pull metadata out of your org (maybe by using the new ‘force:source:retrieve’ Salesforce CLI command), you’ll want to work with a targeted set of metadata. Starting small not only lets you work more quickly (i.e. how long it takes to pull things down to your machine and send them back up to the server), it will also help you begin to get a better handle on your dependencies.
You can use a package.xml file to tell the CLI what metadata it should pull down from your org. If you’re not as familiar with package.xml files, check out the ‘Building your Package.xml’ section in this blog post about metadata retrieval. If you use tools that help you create a package manifest, like Mavensmate or the Force.com IDE, you can also use them to help you generate a package.xml file.
If we’re not supposed to try and grab everything from our org in one package, how should we organize our different apps in source?
The fast answer here is that you should choose a source control strategy that makes the most sense for your team. The longer answer involves a couple things: 1) making sure you and your team have a solid understanding of source control, 2) understanding how to control dependencies in your Salesforce DX projects (and unlocked packages, if you’re moving in that direction).
If you’re brand new to source control, check out the Git and GitHub Basics module on Trailhead. If you want to get a better understanding of patterns for your repos and managing package versions, check out this post on branching strategies and package versioning. If you want to get a better understanding of ways you can organize your metadata into modules, check out the Trailhead resources at the end of this post (and the post about organizing metadata we mentioned above). You can also see these concepts in action in our Easy Spaces Sample App.
Can we put the same piece of metadata in multiple unlocked packages?
You can, but as a general rule you shouldn’t. It not only pretty much defeats the purpose of packaging (i.e. stable, clearly versioned units of metadata), it’s not even letting you get the full benefit of building good, modular units. It’s also not taking advantage of what unlocked packaging already lets you do to declare and manage dependencies. Last, but not least, you cannot install packages that contain the same piece of metadata into the same org.
If some particular metadata, like an object and fields, are key to multiple packages, you should instead consider whether you can create a base or shared package with just that kind of important metadata. You can then make other unlocked packages ‘dependent’ on whatever combination of shared packages you might need.
Wait. What was with that ‘-w’ parameter for package versioning? How do we know what number to put in there?
When you issue a command to create a package version ‘sfdx force:package:version:create’, you’ll want to get into the habit of adding the ‘-w’ parameter. This optional parameter tells the Salesforce CLI to wait for the results of your package version create request for an amount of time you specify. You’ll provide an integer (i.e. whole number) as a part of the -w parameter, to control the number of minutes the CLI should wait for results. The amount of time a package version request takes will depend on lots of factors: what’s in your package, how many other requests for package versions are queued at any given time, etc. We’ve found 10 minutes (‘-w 10’) to be a reasonable default value.
Having the CLI wait for results lets you take advantage of the new capabilities in the CLI to update the packageAliases information in a Salesforce DX project, which makes managing your packages and package versions much simpler.
What OTHER tools were you all using?
Two things were also asked quite a bit: How can I get autocompletion for the Salesforce CLI? And how can I get information like the current git branch into my shell?
Autocompletion is currently not out-of-the-box implemented into the Salesforce CLI. The engineering team is working on that (safe harbor) for next year. Meanwhile, if you’re using bash or zsh, you can check out Wade Wegner’s repos for zsh autocompletion and bash autocompletion.
For getting additional information like the current git branch, the default username for your scratch org, and many more things we’re using Oh My Zsh, which provides tons of customization options for users of the zsh shell.
Awesome resources
Webinar recording: VS Code for Salesforce Developers
Blog: VS Code for Salesforce Developers: Your Questions Answered
Trailhead Module: Application Lifecycle and Development Models
Trailhead Module: Package Development Readiness
About the authors
René Winkelmeyer works as Principal Developer Evangelist at Salesforce. He focuses on enterprise integrations, Lightning, and all the other cool stuff that you can do with the Salesforce Platform. You can follow him on Twitter @muenzpraeger.
Zayne Turner is a Developer Evangelist with Salesforce. Most recently, she’s been focused on Salesforce DX and ways to adopt modular development and working on the new Trailhead Sample App Gallery, which provides reference architectures and best practices for building apps on the Salesforce platform. You can find her on Twitter @zaynelt.