6
There is --validatedeployrequestid or -q flag for force:mdapi:deploy
-q, --validateddeployrequestid=validateddeployrequestid request ID of the validated deployment to run a Quick Deploy
To run quick deploy of a recently validated package, use -q with the validated ID.
sfdx force:mdapi:deploy -q <validationRequestId> -w -1
...
3
Yes, all tests will be forced to run, since the code base is being altered. In addition, all classes will be recompiled to ensure that nothing is broken as a result of the deployment.
2
In my experience, most of destructive changes can go through post destructive. Pre destructive is only needed when you want to make changes inside your deploy and you have some reference that isn't going to allow it.
For instance, if you want to change some custom field type to another type that isn't allow you will need to delete it and all its references ...
2
Something that is related, but not exactly the same as how MavensMate allowed you to deploy Metadata is the VSCode Org Browser.
Open Org Browser
Refresh available metadata types in the org
Default org
Metadata type
Metadata component
Refresh components for metadata type
Retrieve source for metadata component
It is currently in Beta and ...
2
There isn't such a feature in the core bundle, nor does there need to be. VS Code handles multiple orgs without any problems, it's just different. You don't need to select individual files, because you can have as many folders as you need to organize your metadata. You no longer have a single src/classes folder, you can instead have core/classes, marketing/...
2
Custom settings act like sObjects and therefore the fields Values you're talking about are just like any other record of any other Object, since on the change sets you're only deploying metadata, there's no records there, so the values of instances of Custom settings will not be populated by any deploy.
1
Should be. I use a deployment tool which simplifies this for me, but if you're looking to pull it you might want to check workbench --> Info --> Metadata Types & Components --> ProfileSessionSetting.
What's highlighted in blue is just the profile name.
This'll give you the name to include in your package.xml to pull/deploy.
https://developer....
1
In addition to all of the above, https://marketplace.visualstudio.com/items?itemName=VignaeshRamA.sfdx-package-xml-generator gives you a simple GUI for adding items to your manifest/package.xml.
1
The sfdx structure is meant to be used in a repo. The folder structure is not uploaded to Salesforce during sfdx deployments, and thus cannot later be retrieved. You can deploy the same code to multiple orgs using sfdx, and can even push/pull from multiple scratch orgs, as the metadata is saved per org in the sfdx configuration files.
1
Have you tried this inside your YAML file?
task: Ant@1
inputs:
workingDirectory: ''
Options: -verbose -Dsalesforce.url=$(sf.url),Dsalesforce.password=$(sf.password),Dsalesforce.username=$(sf.username)
Check out the following video because it is using Ant Migration Tool with AzureDevOps as well and the YAML had the variable group options mentioned above.
...
1
Use namespace__ApexClass as the apexClass format in PermissionSetApexClassAccess for Apex Classes belonging to a managed package or in a namespaced org. (Rather than namespace.ApexClass used in all other managed Apex references.)
The only documentation I can find regarding PermissionSetApexClassAccess says the following which isn't helpful.
apexClass: ...
Only top voted, non community-wiki answers of a minimum length are eligible
