0

At the moment our developer workflows uses Sandbox as development branches and from Sandboxes developers push straight to production. We have now additional requirements:

  • Have a QA environment
  • Have a DEMO environment which replicates production

For the first issue, we could simply force all developers to push from branch instances to QA instance and then to production, while for DEMO environment we could simply "refresh" a sandbox.

The problem we have, however, is that we would need to preserve the data in the instances, while upgrading the metadata, therefore Sandbox refresh doesn't really work. What way we have to copy ALL the production metadata to other instances?

2 Answers 2

0

In my company we have Developpers pushing to QA sandbox and then to Preproduction and then production environnement.

One big issue we have, when the "sprint" is finished, and all the "sprint" content is on the production organization, we start refreshing all sandboxes.

Developpers like me are bored because each time we have a refresh, we loose our tests records etc...

At this time, the only way I found to keep some data is to create a "custom anonymous code" that create multiple record. In one execution I have some records with datas. It's the fast way I found. (As a developer, I update my script each time I add some fields, object etc...). This is the fastest way I found ! In one copy/paste on the developer console and...voila :)

The other way is to load data via Data Loader (extract and import). Extract from your QA environnement and load it to other sandboxes.

Good luck :)

2
  • Did you try solutions like Flosum? Using the Force Migration tool?
    – Edmondo
    Commented Nov 2, 2017 at 9:15
  • No, we are building our proper continuous integration tool :D I'm using Ant migration tools who runs some schedulable scripts etc... #backtobasics :p
    – FabienHuot
    Commented Nov 2, 2017 at 9:50
0

The new way to do this is to use Salesforce DX. You can quickly spin up an org using a shell script that would look something like this:

sfdx force:org:create -f definitions/enterprise.json -s -a $1
sfdx force:src:push
sfdx force:data:tree:import -p data/data-plan.json

Which you would then call from your terminal:

./sfdx-create-org some-org-alias

You'll want to read the documentation for full details, of course, but the idea is that you can quickly spin up orgs for development, QA, and UAT.

If you want to use DX with Sandboxes, you can still take advantage of force:data:tree:import to quickly regenerate your data after you refresh by using something like the following:

sfdx force:org:web:login -r https://test.salesforce.com/ -s
sfdx force:data:tree:import -p data/data-plan.json

You can, of course, make them more or less complicated as you desire, but this should help you with your problem.

7
  • This is true up to a certain point, creating a scratch org which replicates from production requires almost half an hour for us. We have several managed and unmanaged packages installed
    – Edmondo
    Commented Nov 2, 2017 at 16:56
  • @Edmondo1984 There's a lot of factors involved. I've found that even if fully spinning up a scratch org takes 30 minutes, even a dev sandbox can easily take an hour or longer to be available, which is one reason why I end up refreshing only when synchronizing becomes unbearable; it often takes me several hours to get back up and running when I refresh my dev sandbox, and DX significantly reduces that time.
    – sfdcfox
    Commented Nov 2, 2017 at 17:12
  • by the way, how this would keep the metadata synced between the three instances?
    – Edmondo
    Commented Nov 2, 2017 at 17:16
  • @Edmondo1984 That's what force:src:push and/or force:mdapi:deploy is for. You can deploy any branch to any org using a simple command. DX makes it a lot easier to get your orgs up to date without ant scripts or other complicated mechanisms. If you haven't tried it yet, it's at least worth going through the trailhead for it and see if it can help you.
    – sfdcfox
    Commented Nov 2, 2017 at 18:13
  • 1
    @Edmondo1984 I've used mdapi to deploy seven managed package at once in a single deploy. It's not really as bad as it seems. I have a simple package.xml (<?xml version="1.0" encoding="UTF-8" standalone="yes"?><Package xmlns="http://soap.sforce.com/2006/04/metadata"><types><members>*</members><name>InstalledPackage</name></types><version>36.0</version></Package>), with an installedPackages folder that contains all the packages I want to install. The docs say this isn't allowed, but it seems to work fine for now.
    – sfdcfox
    Commented Nov 2, 2017 at 18:22

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .