Development Lifecycle

A typical environment may consist of three Salesforce Orgs:

Development Org - primarily used for writing code
User Acceptance Testing (UAT) or Staging - primarily used for testing completed sites, processes and applications
Production - used for user or customer-facing sites, processes and applications

OrchestraCMS consists of three layers in relation to this type of environment:

The OrchestraCMS application
The code for page templates, content templates, static resources and JavaScript Remoting
The pages, content and media within OrchestraCMS

OrchestraCMS Application

The OrchestraCMS application can be installed into any of the Salesforce Orgs listed. However, if you first install OrchestraCMS into your production Org and then refresh a sandbox from production that is not a full sandbox, the OrchestraCMS application in the refreshed sandbox will not be functional unless you use the SandboxCleaner Apex class when refreshing the sandbox. There are supporting records and settings that do not get copied from production to any sandbox that is not a full sandbox so the sites, content, media and pages will not get copied to the sandbox. Instead any non full sandbox will essentially be a brand new installation of OrchestraCMS.

When performing a refresh from a Production Org, OrchestraCMS will only be functional when refreshed to a Full Sandbox Org unless the SandboxCleaner Apex class is specified to be run at refresh time of any non full sandbox.

OrchestraCMS Code

The code created for your page templates, content templates, static resources and JavaScript Remoting are all code at the Salesforce level and can be moved between Orgs using standard Salesforce code management techniques (e.g. changes sets or code pushes using development tools). Stantive recommends:

The use of a code repository for change management (e.g. BitBucket, ProjectLocker, etc.)
Testing your code in the development Org using representative sample pages and content

Pages, Content and Media

Due to the template nature of most OrchestraCMS code, pages and content in OrchestraCMS are not files that can be moved between Orgs using changes sets or stored in code repositories. OrchestraCMS pages, content and media are stored as a series of Salesforce records with complex relationships. Stantive provides a tool called OrchestraCMS Shift to move pages, content and media files from one Salesforce Org or OrchestraCMS site to another. To get a copy of this tool please send a request to customer-support@stantive.com.

Recommended Approach

Stantive recommends the following approach for the development and testing of the site:

Install and configure OrchestraCMS in a developer sandbox

When configuring OrchestraCMS, whether or not to enable or disable the Disable Superfluous Span Tags checkbox should be determined early in the development lifecycle. For more information see Superfluous Span Tags. For any new implementations, the Disable Superfluous Span Tags checkbox should be checked.

Create your template code and static resources in the developer sandbox
Create only test pages and content in the developer sandbox, enough to test the functionality of your code
Store your code in a code repository for change management
Install OrchestraCMS in production
Push the code from the repository to production
Build out your site, pages, content and media in production

You do not need to activate the site or publish the pages and content after this step until you are ready to go live.

Create a full sandbox for use as UAT
Keep a change log of all changes made in UAT to be replicated manually in production
When UAT is complete, go live in production