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 Stricter CSP
Analyze and Improve Community Performance
Connect Your Community to Your Content Management System
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 (Developer Preview)
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 first, before you deploy it to your production org. When testing is complete, you can use change sets or the Metadata API to migrate your community from one org to another. Both options are ideal for building and testing a community in a test environment, such as sandbox, and then deploying to another org, such as production.
Available in: Salesforce Classic (not available in all orgs) and Lightning Experience
Available in: Enterprise, Performance, Unlimited, and Developer Editions

Lightning Bolt Solutions can combine custom Lightning apps, business process flows, and Lightning Community templates and pages in an easy-to-build and distributable form. However, they’re not suitable for deploying communities between your orgs. Instead, 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

So how do you decide which deployment option best suits your need? Well, that depends on several factors, including the complexity of the changes you’re migrating, your level of comfort with developer tools, and the application lifecycle management (ALM) model you’re using.

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

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

    With change sets, 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, and migrate these 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—Up to speed on the Metadata API and more comfortable in the world of code? Then use the Metadata API to deploy changes programmatically. The Metadata API lets you retrieve, deploy, create, update, or delete customization information for your org, such as communities, custom object definitions, and page layouts.

    This option 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 help manage multiple work streams. Alternatively, perhaps you’re running up against limitations of what you can do using change sets. For example, you can add but not delete fields (destructive changes).

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

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

Tip