First things first. What is it? The Migration Tool is just a library that you can embed into your Ant distribution, or that you can reference from the commandline. This library calls Force.com's web services to accomplish its work. For more discussion on this, reference the afore mentioned article by Mr. Mountjoy. I also will not talk about all of the available targets. This will be a use case study.

We use the tool to deploy code to production and to our sandbox. We sometimes deploy small portions of code and sometimes all of it. We also use it to deploy metadata changes.You can view our build.xml in the attached files.zip.

It's pretty simple. The first thing to notice about it is that we have two targets called 'use_prod_environment' and 'use_test_environment'. These targets depend on properties. The use_prod_environment will be invoked if the property use_prod_env is set. We do this from the commandline by specifying -Duse_prod_env=true when we invoke Ant. The same is true for the test (sandbox) environment -- this is actually the default, so if we specify nothing on the commandline the Sandbox environment will be used.The next thing to notice is that we have only 2 other targets retrieveUnpackaged and deploy. These targets depend on the environment targets above which set properties for the Force.com URL, username and password. retrieveUnpackaged always retrieves code from the specified environment to a single location unpackaged under our src directory. deploy depends on another environment variable called deploy.root. This variable tells the Tool what set of resources (code and/or metadata) are going to be pushed to Force.com.

Deploying is the only activity we do that cares about dealing with subsets of files. So to do that we have created more directories along-side the unpackaged directory: limitedRelease, apex, and objects. Each of these directories includes a package.xml that specifies what metadata and/or code is to be pushed (telling the Tool what directories to look for). In truth, you can have the same package.xml for any of these directories (just copy it from the unpackaged directory). What really matters is the directory structure underneath. If you have a classes directory the Tool will deploy whatever classes are there. If you have a triggers directory it will deploy whatever triggers are there. The same goes for objects, applications, letterhead, pages, profiles, scontrols, staticresources, and tabs -- all directories within this directory.

Our 'limitedRelease' directory is a testing ground for new changes. We hard-copy classes and triggers into its subdirectories (along with their associated '-meta.xml' files). We work on that set of code and deploy it to the Sandbox as we test (test-first mind you, which is a little more of a hassle with Force.com, but still doable).

Our 'apex' directory is for all classes, pages, triggers and staticresources. They are all soft-links to the subdirectories under 'unpackaged'. This directory is used to deploy all of these resources to production and/or sandbox, as opposed to the limited set under limitedRelease.

Our 'objects' directory is used to migrate object metadata changes between production and the sandbox. The files under this directory may be hard-linked or soft-linked.The basic commandline looks something like:

ant -Ddeploy.dir=limitedRelease #deploys resources that are currently being developed to Sandbox

ant -Duse_prod_env=true -Ddeploy.dir=apex #deploys code resources to Production

ant -Duse_prod_env=true -Ddeploy.dir=objects #deploys object metadata to Production

ant retrieveUnpackaged #gets all resources from Sandbox

ant -Duse_prod_env=true retrieveUnpackaged #gets all resources from Production

Instead of typing these out all of the time, we use shell scripts which expect to be passed the use_prod_env variable when we want to deploy something to Production, otherwise it's deployed to the Sandbox.For instance our deployApex.sh looks like this:

We keep the Force.com Migration Tool library in a lib directory above our src directory and reference that in our shell scripts.

You can download the files mentioned in this article here.

The Apple Script I use to invoke this from TextExpander is:

Avi Bryant gave a nice demo of 100 days of work on the VM.  It does simple things in the typical Gemstone distributed fashion.  Talking with some Gemstone folks afterward, I found out that in 100 days they have implemented about 20% or 30% of the Core library.  In the MagLev talk they mentioned that they are effectively (and impressively) running about 38 of the rubyspecs defined by the Rubinius team.

Great stuff.

If religion is your god, you are certainly in bondage. However, if God is your religion you are certainly free.

It's a bit out of context but the thought is simple enough to understand: the church today is so full of impersonating spirits that most of Christianity is not really an inspired life, but instead a copy of someone else's inspiration.

Instead of praying from the heart, people learn to copy others' prayers. Instead of fasting out of inspiration, it's a formula by which we expect to earn some favor from God.

We may quote Galatians 2:20, "I am crucified with Christ, therefore I no longer live..." but is it really so? To be crucified with Christ is to be fully identified with the message of His crucifixion, the message of the cross. To know why Christ died, and what it has accomplished in my life!!

Oh that I might truly be crucified with Christ...