You can do this using just the out-of-the-box Force.com Migration Tool.
As you noted, destroying metadata components is achieved with a destructiveChanges.xml definition. However this differs from package.xml in that it doesn't support wildcards (*) - so the intermediate hurdle is the generation of an explicit definition containing the names of all the ...
In API version 30.0 and later, permissions for required fields can’t be retrieved or deployed. So make sure your profiles/permission sets don't reference any required fields.
See "ProfileFieldLevelSecurity" in the Metadata API Developer's Guide: http://www.salesforce.com/us/developer/docs/api_meta/Content/meta_profile.htm
See "fieldPermissions" under "...
It appears that the deploy package to package.xml validation is case sensitive. If you get a is not in package.xml, double check the case of the object or field in your package.xml.
The tricky part about this is that ant retrieve will work just fine, the validation only occurs when doing ant deploy or ant test
You have a few options. My recommendation however, will be to use ANT and destructiveChanges.xml contrary to your post. It might take a few hours to set ANT up in your environment and in your support team's environment, but it is a repeatable process you can run on multiple orgs if need-be.
Running the ANT script (can) be easier for your support team ...
from Setup > Create > Packages, create a new Package in your org
add the components to it using the UI
run ant pull -Dsf.firstname.lastname@example.org -Dsf.password=secret
update EachOfYourClasses.cls-meta.xml to read <status>Deleted</Status>, eg:
<?xml version="1.0" encoding="UTF-8"?>
Inspired by bigassforce's answer, my preference for platform neutral Ant scripts and wanting to see if I could get the Tooling API working from Ant, I've worked up this solution. Its taken quite a while actually, but I've enjoyed it and it has shown some great possibilities for calling Salesforce REST API's from Ant. Anyway, first the data we want to assert ...
There are some goodies in version 34.0 that should help you out. As you already noticed 196 added the concept of FlowDefinition that should allow you to activate/deactivate processes (flows) via the MD API. 196 also solve the problems around continuous integration by adding a permission you can turn on: FlowMdOverwriteEnabled. Flip this perm on and you will ...
You will be able to pull/push the approval process using a the following package.xml. The ApprovalProcess element will pull down the Approval Process and the Workflow element will pull down any of the actions that are referenced in the Approval Process for that action. Replace CustomObject__c with whatever object(s) your approval processes are on, this will ...
adding password manually after retrieve and before deploy worked :
<?xml version="1.0" encoding="UTF-8"?>
Edit: Summer '15 made this "all better". If you upgrade your ant-salesforce.jar to one that supports API version 34, you can now pass a "testLevel=RunLocalTests" attribute to sf:deploy like so:
Your package.xml needs to include the "Layout" type. It is usually best to explicitly name the layouts where the syntax is objectname-layoutname e.g.:
<members>Account-Claims Account Layout</members>
<members>Contact-Claims Contact Layout</members>
I'm pretty familiar with the Metadata API and deletion of Package 'definitions' is not supported presently it appears. The only thing i can think is accessing the Delete action via the page URL's, which is not ideal of course since its not supported.
I did also try this in destructiveChanges.xml, it did not work sadly. I should clarify, it did not error, ...
The migration tool doesn't provide this functionality directly, but it can be built on top of the migration tool. We've built and open sourced our build and automation scripts used at the Salesforce Foundation at https://github.com/SalesforceFoundation/CumulusCI
Assuming you already have a repository with your metadata contained in the src directory, you ...
I wrote an ant target to help with the deployment of flows.
Before deploying flows, I fetch the flow definitions, then only deploy flows that are newer than the currently active version.
This assumes that you keep your metadata in a directory named src, so your flows are in src/flows and flow definitions in src/flowDefinitions. Deployment is done from a ...
I just had some invisible character ( ​ Unicode Character 'ZERO WIDTH SPACE' (U+200B) http://...
These settings are stored in the CustomObjectTranslation metadata object, and you can deploy them in any tool that uses the metadata API. (You can make this change by using the metadata APIs either using ANT and manually building a package.xml, or by writing a custom script to do it using SOAP.)
You can also use Gearset to make this change*. To do this ...
We recently ported the famous Java Static code analyzer PMD to Apex. We also ported many of the original Java rules and created a few Apex specific to showcase how to write language-specific rules (e.g. AvoidSoqlInLoops, AvoidLogicInTriggers,...).
Other than CodeScan, our effort is open source and was merged back into the original PMD repository on Github (...
I think from 37 Api ver picklists are replaced with Valuesets in metadata definitions and it causes an error when You try to deploy 'old' metadata with higher Api Version. To get rid of this error, change your metadata file Api Version in Your package.xml file to 36.0 .
Another option is to export objects from Your ...
Your first requirement (uploading static resources) is all within the capability of the Ant Tool:
In your build.xml use the deploy command:
<project default="usage" basedir="." xmlns:sf="antlib:com.salesforce">
<taskdef uri="antlib:com.salesforce" classpath="ant-salesforce.jar" />
<target name="push" description="Uploads your static ...
It's not possible with that method. The InstalledPackage metadata type requires a namespace and unmanaged packages don't have one.
What you can do is install the unmanaged package into an org and then do a retrieve of the package's metadata. You can use the retrieved package metadata to deploy into any other org via ant or any other deployment tool. It ...
DOH! It was a PEBKAC error.
The 4 metadata XML files were indeed missing from source control and my local src folder that the Force.com migration tool was pointed at. I was getting confused with MavensMate pointing at a different directory that had directly pulled metadata from the project rather than source control.
I'll leave this Q&A here as there ...
You could do some sort of encryption that you can decrypt as an ant target task - like a base64 decode or something.
The problem with that is anyone who's savvy enough to be able to look in the configuration files for your password is probably savvy enough to simply decrypt it themselves.
What I do - and would recommend - is pass the password, and maybe ...
When you add fullName to a package.xml, the metadata API assumes you're trying to insert/update a package instead of deploying unpackaged metadata. You must not specify fullName when deploying components that cannot be packaged.
Was able to do this using ant's scripting capability. Now you can do ant deploy -Ddir=src -Dtests=Class1,Class2,Class3
var deployTask = project.createTask('antlib:com.salesforce:deploy');
I have found some custom way, how you can detect your API version of ant-salesforce.jar. jar is an archive file, so it is possible to restore this file into components. Use WinRar or another archiver-program to do it.
After restoring you will see the following structure of folders:
open next file META-INF\maven\com.force.api\force-wsc\pow.properties with ...
While deploying the code to Production all tests except of Managed
Package will be executed regardless of the "runalltests" value, is
this not the case with Sandbox?
That is not correct. All unmanaged tests will run when deploying to a production org, regardless of the runalltests flag. The managed package tests only run if runalltests is set to true.
In the Setup UI you will see that custom fields (that are presented for Task) are added under the "Activities" heading and this is also reflected in the package.xml that the Ant tools use.
So your package.xml will need entries like these:
As per the documentation the CustomField metadata type does not support wildcards sadly. You can access Custom Fields on Standard Objects by using the CustomObject metadata type as described here against specific Standard Objects. Then parse the .object file to build your destructiveChanges.xml file. Finally you can also use the sf:listMetadata task to ...