function readOnly(count){ }
Sign Up ›
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
Learn More

Browse by Topic
ShowAll Questionssorted byDate Posted
+ Start a Discussion
MayTheForceBeWithYouMayTheForceBeWithYou 

Salesforce Subversion-Dynamic Package Manifest File

I have been working on a script that automates pulling down my org's data/metadata into a subversion repository nightly.  I have completed the main objective utilizing Ant & the Force.com Migration Tool but have noticed in my tweaking that the package manifest file (package.xml) is not dynamic enough for my purposes.

 

I know from reading the Force.com Migration Tool Guide (http://www.salesforce.com/us/developer/docs/daas/salesforce_migration_guide.pdf)

that certain components cannot utilize the wildcard feature such as dashboards, documents, email templates, letterheads, and reports.  Likewise, I know that there are still several other components that you must first dot-qualify their object name as they are sub-components.

 

My question is as follows: is there a way to possibly create a dynamic package manifest file so that if a user were to create a new document or email template then such a change would be automatically detected during that night's backup and the corresponding change/file would be uploaded to my subversion repository?

 

Again, my initial glance at the Force.com Migration Tool Guide makes me think this is not possible and that a manual edit to the package.xml file would be necessary-but my optimism stems from drawing parallels between my desired task and the current functionality of the Force.com IDE tool.  Upon initially setting up a new Force.com project in the Eclipse IDE you are able to manually select which metadata components you would like included-as noted by JonP this is essentially a GUI for creating your package.xml file.  For existing projects, you have the option of later adding additional components that were either not originally included in your project or were created over the web interface after you set up your Eclipse project (exactly the scenario that affects my desired task) by utilizing the Add/Remove metadata components tool and then clicking the "Refresh from Server" button (depicted by circular arrows).  This refresh from server button proves there is a way to somehow poll your org and discover new metadata components not currently included in your package.xml file and if I could find a way to automate this process via the command line (and then have the differences updated in my existing package.xml) then I could create a dynamic package manifest file as I desire. 

 

This problem also exists in the inverted scenario where a user deletes certain components via the web interface that should then be replicated in the subversion repository (I must admit though that this issue does not concern me as much as allowing for new components to be brought in does).

pklockepklocke

I am needing to do something very similar. Here is our scenario:

  1. Developed MetaData (ApexClasses, Triggers, components, etc):  Our developers do their work, and direclty check their changed code in SVN (this allows developers to work on FUTURE code in our DEV/Config sandboxes). They completely control what gets built/deployed, as SVN is the "one true source"
  2. Non-Developed code (as you have noted above) that we want to know, basically, "what changed?".  For these (and it is still WIP), I would do an ANT retrieve of all metadata that does not fit the Developed MetaData definition, above).
  3. Given, per step 2, I now have a full set of "non-developed" metadata, I can then execute a "compare" activity between what is already in my SVN repository (yes, our non-developed code also sits in the SVN repository using standard folder structure, ie ..\src\email, ..\src\documents, etc)
  4. At this point, I will take any action I wish with this last fileset, and if all is well, I check in "ONLY THE CHANGED" files to SVN (generating a report of same).  Again, the "compare" tells me what is different for each file, if anything, since SVN received its latest revision of that file.

 

Given all of above, for my deployment, I can then execute a svn checkout (to some special location) of only files changed since my last build (ie Prior SVN Revision+ files).  If I do this, then I can use a plain old "generic" package.xml, such as you might get with an IDE full retrieve.  Given I stage "ONLY" the changed folders, I can set parameters (I think) in my build.xml file to ignore issues that arise if no files are found for a specific set/folder/dot notated file(s).

 

Anyway, that's the way I am approaching it.  There are so many ways, but that is my plan. (and I am brand new to this so I may be overly optimistic, or naive....I do have up to the compare process mostly working at this point).