0

My team is working on a project that will likely take over 6 months. We are making edits to Site pages, classes, fields, flows, etc. Part of this process involves staging changes in a partial sandbox from a developer sandbox for testing before we actually push to Production. We are using Github to manage branches/stages, doing deployments through the CLI directed by Github, and are in need of information regarding best practices.

In particular, with the new Winter 2023 update, we've got a number of questions after we noticed hundreds of files got changed for some reason. For example, files related to Sites we are editing mention the fonts that are available related to the theme showed up as a changed file awaiting push.

  1. Considering we are not making changes to the theme, do these files even need to be in Github in the first place? Or only Site files we anticipate will need changing?
  2. Where are these changes coming from? Is it indeed the Winter release?
  3. When these changes happen in the Sandbox, do we need to push them into production?

I've tried looking into general best practices, but have not seemed to find anything particular to these Salesforce-release-related questions. Thank you.

Improve this question

1 Answer 1

Reset to default
1

This is one of those scenarios where Sandboxes should be considered unreliable relative to Scratch Orgs. When you use Sandboxes, you have to pay attention to the Sandbox Refresh schedule, or you might end up on different versions of Salesforce during the release window.

When you use Scratch Orgs, you can specify which version you want to work with during the release window, and therefore keep your files in sync. Ultimately, if the files in question don't matter, you can keep them out of the repo, but for many builds, they are indeed necessary, and the best way to keep everything in sync is a planned version upgrade all at once.

Sometime after the preview becomes available, create a preview Scratch Org, deploy everything into it, bump up the API version for your package to the next version, and then pull everything back down again. Doing a planned version change keeps the chaos to a minimum, and using Scratch Orgs ensures that everyone's on the same API version and release.

If you haven't yet seen or heard, the mantra with "Salesforce DX" is that the "repo is the source of truth." This means you shouldn't have to worry about which release an org is on, everything should just work. Of course, that comes with caveats (you obviously can't install 57.0 metadata into a 56.0 org), but managing your versions and org's release version should be exceptionally easy with a bit of discipline.

Considering we are not making changes to the theme, do these files even need to be in Github in the first place? Or only Site files we anticipate will need changing?

You should strive to be able to recreate an entire org, even if those files won't change. That's how Scratch Orgs are meant to work.

Where are these changes coming from? Is it indeed the Winter release?

Without seeing it, I have do idea. But you should commit those files anyways, once you confirm they work in a Scratch Org.

When these changes happen in the Sandbox, do we need to push them into production?

If they are API-version-related, you'll have to wait until Production is upgraded. You might not need to push them, but the changes should be harmless.

Improve this answer

You must log in to answer this question.