1

I'm using the Force.com Migration Tool and I'm trying to figure out what directory name(s) I should be using in my build.xml file. Note, I'm not trying to deploy to the AppExchange. This in internal changes only, and I'm migrating from dev to another org.

The documentation isn't clear and the matter and the sample that ships with the Salesforce Ant Task doesn't help.

It lists:

  • codepkg - containing classes and triggers
  • mypkg - containing objects
  • removecodepkg
  • unpackaged

So is it required or convention that classes and triggers shall go in the codepkg directory and objects go into the mypkg directory? I assume not in both cases, but if there is an commonly accepted convention, I'd like to follow it.

Thanks.

2 Answers 2

1

The folder names are simply a matter of convenience. They're samples. Actual directory names are irrelevant. You can use any folder name you like.

Each entire deployment must exist in a single deploy root directory, however. You can place code, objects, profiles, etc, all in a single deploy root. If you do so, all elements must be referenced in the package.xml file.

For my setup, I use one directory per sandbox. This lets me migrate between sandboxes easily, as well as perform diffs, etc. You might also use multiple directories for a multi phase deployment (e.g. you have incompatible elements that have to be deployed in order).

The structure within each directory is significant, however. Classes go in the classes directory, etc. The deploy root names aren't significant, and can be any value that is meaningful to you.

2

The Force.com Migration Tool doesn't really care about your directory structure. Your build.xml will tell it the directory to deploy in the targets you create.

The convention we use with our repository is all package code under src and all unpackaged code under unpackaged/pre and unpackaged/post with unpackaged/pre being deployed before src and unpackaged/post being deployed after src.

However, I'd try to just use a single subdirectory such as src to hold all the metadata you want to deploy. I've found deploying everything at once is the easiest as the platform handles most of the dependencies between metadata in the deployment for you.

I think the Force.com Migration Tool documentation is simply providing you example targets each with their own set of metadata to show you different ways of using it.

1
  • Thanks Jason. I am confused about your convention... the way it is worded makes me a bit dizzy... ;) Commented Feb 12, 2015 at 18:37

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .