I am wondering if there are any use cases for using Ant specifically over all other deployment methods and tools?
It seems Eclipse, changesets and packages have all the functionality you need.
Salesforce Stack Exchange is a question and answer site for Salesforce administrators, implementation experts, developers and anybody in-between. It only takes a minute to sign up.Sign up to join this community
We use ANT in our automated build process because we can invoke it programmatically (with SH/Jenkins, etc.) to move code between orgs and run tests without having to open an IDE, create a change-set etc.
This helps our development process because we need to move code between non-namespaced and namespaced orgs and do some tweaking to it before we can successfully deploy from development/test to packaging.
Maybe checkout this github repo, it's a lot more specific and has an App built into it and I'll be adding the preconfigured AMI in a few days prior to presenting it at DF:
I agree with Jordan - Ant allows you to publish a completed build
Changesets and Eclipse will always publish the latest version of the code. A complex project usually requires the ability to use a code configuration tool (such as Git) that allows managing code versions, which can then be deployed using Ant
in Other words, you can take a snapshot of your development org when it is stable, then continue experimenting, and when deployment time comes you can deploy the stable snapshot.
Ant also gives you an automated method of deploying the same code version to multiple environments
Ant allows running validation only deployments to target environments on a regular basis (for example to test code coverage)
AutoRABIT has the best matured deployment solution for Salesforce , where you can deploy automatedly from your Jira or any ALM User Story status , directly from a Sandbox or from your version control system like SVN , TFS , GIT or Perforce.
You can check it here for more details.
Ant used to be a good way of publishing a complete build, but it takes a while to setup and getting the right metadata. In addition to Guy's comment regarding the automation of build to multiple environments, I would recommend looking at a tool called Copado Deployer. It is available on the AppExchange (native Salesforce App) and can perform everything that ANT, Eclipse or Change Sets do but in a much more efficient and quicker way. https://appexchange.salesforce.com/listingDetail?listingId=a0N3000000B3dgGEAR
I found some videos that help getting started with the app. https://www.youtube.com/channel/UC8te3UIYjrDftwNPx_5ZpYg
A short list of the features is below: - Super fast search of all meta data - Deploy to multiple orgs at the same time. - Full Profile deployments (we handle any errors and remove unnecessary metadata not compatible with the destination org). - Full User deployments (with related roles, profiles, territories, permission sets, managers, delegated approvers). - Full Translation deployments (just select the language and we handle the rest). - Org differences (and add them to deployment) - Scheduled deployments - Scheduled Git backups - Scheduled Apex tests - Copado tips - when you get errors in deployments, Copado will search the database of resolutions and advise you on how you can avoid getting the error. Or for example when you deploy a profile the field level security for the What field is reset on tasks and events. For those that don't know how to resolve the issue, Copado adds a tip to the deployment result.
An old colleague of mine has used it and said that they were able to perform a deployment 2 times faster (500+ metadata components) over the use of change sets, or 3 times faster for smaller deployments (5-30 metadata components).
If you perform many small Change Sets are not very efficient because of the selection process.
Adding to Jordan's comment a tool like Jenkins is a good idea to have especially if you have multiple developers working on a project. Automated tests and Git backups are important if you want to deploy something only to find that there are errors in the ApexTests because someone has changed the metadata of your destination org. The Copado App also allows you to schedule Apex Tests and Git backups.
hope this helps..