Page Comparison

...

• Update your production org’s package.xml to the latest version and ensure that you can do a retrieve from production under the latest API version. Ensure your Source is up to date.

• Commit your production source to your repo, just to back it up.

• Save that whole folder as a new folder.

• Refresh your sandbox or create a new sandbox (developer or developer pro)

• Authorise the sandbox from that new folder.

• (optionally) run sfdx force:source:tracking:reset I’m not quite sure yet if it is needed if you do these steps.

• Commit your sandbox to your repo.

• Start a new branch in your repo.

• Of course add your data in whatever way you add data to your non-data filled Sandbox.

• Start making some changes in your org or the metadata.

• Push and / or pull as required.

Make Some Changes

...

Make changes by changing things in the org. Then pull the changes into source.

Code Block
sfdx force:source:pull

Or make changes to the metadata then push the changes into the org.

Code Block
sfdx force:source:push

Tip
See Getting Started with Powershell in VS Code for some tips to set up Powershell to make regularly used DX commands easier to use.

Query what changes there are

...

SELECT MemberName, MemberType, ChangedBy, RevisionCounter FROM SourceMember

But use the Tooling API.

If you get stuck

There are two new commands

sfdx force:source:tracking:reset
sfdx force:source:tracking:clear

Use with care. But if you mess things up, you may use reset first, then clear at the last resort, to start again. But have your changes committed to your source tracking first before you do that.

Org Structure

There is a new feature to use different folders in your VS Code project to push and pull into different folders. So maybe if you are working on a new feature you can use that different folder to collect all your changes in there, and then use DX for Deployments to deploy that folder to production. I need to check this out.

But in the worst case use the SOQL statement above, using the tooling API and it will tell you which metadata has changed so you could put it in a Change Set. But no, we don’t want to use Change Sets anymore, so you could at least put that metadata into a separate folder and deploy from there?

With the new feature of multiple folders, any changes to where you move files is not tracked in force:source:status, so you have to use your git tracking to work out where files and folders have moved to. I dunno, is this too hard. It is something I need to work on. YOU have to track your own dependencies and work out your own folder structure. It’s a lot of work to set up these different folders so it may not be worth it?

More work to be done on this to decide which is the best and easiest way for Admins to deploy.

Packages

No you do NOT need to use packages to use DX. But there may be some benefit to creating org-dependent unlocked packages (in beta as of Summer '20). But there is a LOT of metadata that can NOT be in unlocked packages. So check the Metadata Coverage API documentation, and for example, if your solution includes simple things like Picklists or Assignment Rules or Auto Response Rules and many other things, then it might not be right to be packaged.

It’s all about knowing your org’s metadata, and that is the first step to becoming successful with DX.