Hey @SBasile, great question, there are a few paths and it ultimately depends on your situation.
If you’re working on templates or building a new module, and you need to work with real data a simple way of doing it is to use Content Staging.
- Stage a page that you will be redesigning/updating.
- Create your new module/new template or clone of a template you plan to change.
- in your staged page set your page to use the new template, or add the module you’re planning to develop. You can access all of the live data from the account, but the page you have is on a staging website. It’s not going to affect the live site until you publish from staging.
Learn more about content staging.
Additionally you may have heard of the enterprise feature Sandboxes, not to be confused with CMS sandbox accounts. Basically it’s a copy of your production portal. Currently today when you create a sandbox you can sync everything in your developer file system to the sandbox, forms, the schema/structure of your CRM data, and more. As of this posting the feature does not currently have the ability to sync page content. That said having all of the rest of the data enables you to use that environment as a testing/development area.
Sandboxes are a new feature and we’re continuing to add functionality to it over time. Learn more about Sandboxes.
If you do not have an enterprise hub and subsequently don’t have the sandbox functionality, you can use a CMS Sandbox. The trade off right now is that you would need to use your CLI or the design manager to transfer your development assets to that account, and the sandbox account won’t have any of your production accounts data. A workaround is to simply make sure your default values in your templates and modules reflect a similar experience to what’s on your live site.
Once you have one of those account types (CMS Sandbox or enterprise Sandbox) you can do a more traditional git based workflow by taking advantage of our GitHub Deploy Action. Effectively if you were following the traditional git-flow method where you have a feature branch, develop branch, and main branch. You can set it up so that merges to your develop branch will automatically result in the files being deployed to your CMS Sandbox or enterprise Sandbox account. Then set it up so that any merges into your main branch, get deployed directly to your production account.
This enables you to have 1 account for safely working on your feature branch, 1 (CMS Sandbox or enterprise Sandbox) for your develop branch which you’d share with any colleages developing. then your main production account.
That workflow is ideal for teams that actively work on the same sites at the same time. You can alter the workflow, say skipping the sandbox for your feature branch based on how you or your team work.
We realize that having a lot of options and some having trade-offs can be daunting. We’re actively thinking about ways we can make it easier and while we may not always be able to respond, we are watching for feedback and iterating based on that feedback from our community around the development workflow.
Additionally we have some more tips on creating an efficient development workflow.