Lightning Communities Developer Guide

Get Up to Speed with Lightning Communities
Develop Lightning Communities: The Basics
Customize the Look and Feel of a Lightning Template
Example: Build a Condensed Theme Layout Component
Develop Secure Code: Lightning Locker and CSP
Analyze and Improve Community Performance
Use a CMS with Your Community
Report on Deflections: The Deflection Signals Framework
Deploy a Community from Sandbox to Production
Deploy Your Community with Change Sets
Deploy Your Community with the Metadata API
ExperienceBundle for Lightning Communities
PDF

Newer Version Available

This content describes an older version of this product. View Latest

Deploy a Community from Sandbox to Production

We recommend creating, customizing, and testing your community in a test environment, such as a sandbox, before deploying it to your production org. When testing is complete, you can use change sets or Metadata API to migrate your community from one org to another. Deciding whether to use change sets or MD API depends on several factors. Some things to consider are the complexity of the changes that you’re migrating, your level of comfort with developer tools, and the application lifecycle management (ALM) model that you’re using.
Available in: Salesforce Classic (not available in all orgs) and Lightning Experience
Available in: Enterprise, Performance, Unlimited, and Developer Editions

To learn more about the ALM models and development options available to you, check out Determine Which Application Lifecycle Management Model Is Right for You on Trailhead.

Tip

Lightning Bolt Solutions aren’t suitable for deploying communities between your orgs. Use a Lightning Bolt Solution to share or sell a solution on AppExchange or implement a community with a turnkey solution or new look.

Note

Change Sets

If you’re more comfortable working with point-and-click tools, change sets are your deployment friend. A change set represents a set of customizations in your org (or metadata components) that you can deploy to a connected org.

You can manage your application using declarative tools. You don’t have to use a command-line interface or a version control system to meet your customization needs. You use the Setup menu to create changes in a development environment. You then migrate the changes between environments as you work through the ALM steps.

Your release artifact is a set of metadata changes relative to what’s in the production org. What gets released is only metadata that has been added or changed—if it doesn’t change, it’s not in the release.

Metadata API

If you’re up to speed on Metadata API and more comfortable in the world of code, use Metadata API to deploy changes programmatically. You can retrieve, deploy, create, update, and delete customization information for your org, such as communities, custom object definitions, and page layouts.

Using Metadata API is ideal when your changes are complex or when you need a more rigorous change management process and an audit process (or version control system) to manage multiple work streams.

As with the change set process, the release artifact that you create is a set of metadata changes relative to your production org.

Some Communities settings and features aren’t yet supported in Metadata API, so you have to migrate them manually between environments. Remember to track these changes so that you don’t forget to migrate them.

Tip