Anyone familiar with the Java ecosystem will immediately recognize Ant, the stalwart task automation and build tool. While other tools such as Gradle, Maven, and Ivy have recently eclipsed it in popularity, it is an incredibly powerful tool, not just for deploying Salesforce metadata, but also for automating continuous integration builds, packaging, and general workflow automation. Ant is both the name of the tool as well as the language used to define tasks. As crazy as it sounds, Ant is an XML-based programming language, and automated tasks are defined in an XML file. Traditionally, this is called build.xml. The migration toolkit from Salesforce is distributed as a .jar file and defines tasks such as <sf:retrieve> and <sf:deploy>. Salesforce tasks rely on two other files that you must also create. The build.properties file contains information like your username, password, and instance URL. The package.xml file contains the information related to the files and kind of metadata you want to retrieve or deploy from Salesforce. This package.xml file is the heart of the Ant migration toolkit, and it is where most of the work of deploying via Ant takes place. You might end up editing the package.xml file every time you deploy. Conversely, the build.xml and build.properties files, unless your password changes, are generally configured once per-project. Here is a diagram of the tools and files and their uses:

If all this seems daunting and complex, you're not alone. One of the Ant migration toolkit's biggest weaknesses is the sheer number of moving parts that all need to come together. Mix in handwritten, wall sized XML files and it can be very daunting indeed. Because the lion's share of work for an individual Ant deploy is in editing the package.xml file this method's greatest weakness is also its greatest strength. XML files are not only machine readable, they are also machine-writable. The built-in ability of most systems and development platforms to create XML makes this the best deployment option for continuous integration systems. Continuous integration systems can therefore dynamically create the package.xml files on the fly. A CI system can run all the unit tests in your sandbox and if they pass, build a package.xml specifying only the git files identifies as having changed. Deployment via Ant will always force all unit tests to run, but each deployment still has to parse and manipulate your uploaded metadata. Dynamic generation of package.xml files from git data is a nice enhancement, since fewer metadata components means a (admittedly slightly) faster deploy process.

Let's take a look at each of the three main files used in an Ant deployment. First, let's take a look at the build.xml file:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns:sf="antlib:com.salesforce" 
name="Salesforce Deploy Build Script" 
basedir=".">

  <property file="build.properties" />
  <property environment="env" />

  <!-- Include the ant salesforce migration toolkit -->
  <path id="classpath">
    <fileset dir="${build.dir}/build/lib" includes="*.jar" />
  </path>

  <!-- retrieve files from the source org and place them 
in the build/src directory -->
  <target name="retrieve" 
description="Clean the source directory and retrieve 
metadata from source org" 
depends="cleanSourceDirectory">
    <echo>Logging into ${sfsource.serverurl}</echo>
    <echo>With username: ${sfsource.username}</echo>
    <sf:retrieve username="${sfsource.username}"
        password="${sfsource.password}" 
        serverurl="${sfsource.serverurl}" 
        retrieveTarget="${source.dir}" 
        unpackaged="${source.metadata}" />
  </target>
  




  <!-- Clean (remove all files) from the build/src directory -->
  <target name="cleanSourceDirectory"
description="Clean all metadata and directories in source directory">
    <echo>Cleaning directory: ${source.dir}</echo>
    <delete includeEmptyDirs="true">
      <fileset dir="${source.dir}" 
includes="**/*" 
excludes="destructiveChanges.xml" />
    </delete>
  </target>

  <!-- Retreives latest code into src direct and 
 deploys the items from package.xml 
 into the target org -->
  <target name="retrieveAndDeploy" 
description="Clean, retrieve code from source org, 
and deploy metadata to target org" 
depends="retrieve,deploy" />
  
  <target name="deploy" 
description="Deploy metadata from source dir
to target org">
    <echo>Deploying code from ${source.dir}</echo>
    <echo>Deploying code to ${sftarget.serverurl}</echo>
    <echo>Deploying code with username:${sftarget.username}</echo>
    <echo>Runing All Tests: ${sftarget.runAllTests}</echo>
    <echo>Deploy Root: ${source.dir}</echo>

    <sf:deploy username="${sftarget.username}" 
         password="${sftarget.password}" 
         serverurl="${sftarget.serverurl}" 
         deployroot="${source.dir}" 
         runAllTests="${sftarget.runAllTests}" />
  </target>

  <macrodef name="git">
    <attribute name="dir" default="" />
    <attribute name="branch" default="master" />
    <sequential>
      <exec executable="git" dir="@{dir}">
        <arg value="pull" />
        <arg value="origin" />
        <arg value="@{branch}" />
      </exec>
    </sequential>
  </macrodef>

  <target name="checkoutFromGit">
    <echo>Issuing git pull from directory: ${git.dir}</echo>
    <echo>Pulling from branch: ${git.branch}</echo>
    <git dir="${git.dir}" branch="${git.branch}" />
  </target>

  <target name="checkoutFromGitAndDeploy" 
 description="Checkout from Git and deploy to server" 
 depends="checkoutFromGit,deploy" />
</project>

Let's break this down a bit and look at what's going on. This is a pretty boilerplate build.xml file for Salesforce deployment. First, we have a standard XML schema definition tag, followed by a project tag. Our project tag not only serves as our root node, but also specifies some project information like name and, crucially, the namespace. Ensure that your project namespace matches the one listed, or you'll have issues with Salesforce-specific tasks. Just inside our project node, we have tags for setting environment and build properties. We'll look at the build.properties files in a minute. Crucial to the success of your build.xml file is the path tag. Because Ant is a Java-based tool, you can extend your classpath with additional JAR files, and this path node does just that, loading all the .jar files in build/lib/ and its subdirectories. Ensure that wherever you have saved the .jar file, which Salesforce distributes, is mentioned in the path node. I like to keep mine in build/lib/.