function readOnly(count){ }
Starting November 20, the site will be set to read-only. On December 4, 2023,
forum discussions will move to the Trailblazer Community.
+ Start a Discussion
Tyler WagnerTyler Wagner 

Continuous Integration - how to manage package.xml?

Hi everyone,

We're attempting to get a path to production, utilizing CI as we don't have the time or budget to manually transition and merge changes from multiple developer groups up through the environments in our path to prod. We're looking at using git, ant, and jenkins (or similar). There are a lot of tutorials for how to implement that part, however I'm not really finding anything about how to manage package.xml when you have multiple developer groups pushing changes and need to merge the changes into a a chunk to have pushed to the next stage (while ensuring there is no loss of work). 

What's the best way to manage package.xml?

More in depth details below:

 

Our situation is that we're going to have multiple scrum teams performing config and code tasks (it's looking like each team will be around 70% config/30% code). They will each have a group sandbox. When they've finished a story, they will push the changes to git, which will in turn attempt to push the changes to a Dev Integration environment (to ensure each teams changes works with the others).

This will happen multiple times before all those changes will be need to be gathered and pushed to the QA environment (and then up to staging, and then to prod).

There are two goals that we need to accomplish that we are having trouble figuring out;

1) If team 1 changes an object, commits it, then team 2 does a commit without changing said object, it looks like it's possible team 2 could end up overwriting the work team 1 did (if they merge everything into the dev int branch). We need to ensure this doesn't happen.

2) Since there will be numerous commits from the various teams into DevInt before the collective changes get pushed to QA, we need a way to merge all of the changes since the last (good) push into one package.xml so that only what's been changed will be pushed out.

It looks like we may need to auto-generate the package.xml file on each commit/merge (in each branch) to include only what's actually been changed to handle these goals (unless there is a better way, or we're over-engineering here). 

Is this accurate? How would we go about auto-generating package.xml (I've found very few resources floating about the web)? Is this the best way to handle things in our scenario?

To make matters worse, we don't have a large budget for this (for example, I was looking at Flosum, but quickly got told we don't have the budget for it).

 

Thanks for any help anyone can give!

Andy BoettcherAndy Boettcher
Outside of designating someone to act as the gatekeeper on that final push to ensure a proper package.xml file - you may want to look at http://www.autorabit.com/ as a potential solution for your CI environment.  The guys at AutoRabit are solid and work with you to get your environment humming.

Reading that you don't have a large budget, AutoRabit isn't expensive for what it does.  However, if I'm reading between the lines - you are being asked to set up a large multi-team CI environment with about $25/month for a GitHub private repo that you may be funding from the office's swear jar.  =)  

You COULD have a scheduled ANT job that does a full metadata pull and then use that file as part of your CI solution, but that's a bit of a bubble gum/bailing wire solution.  
Bhargavi Vadlamani 12Bhargavi Vadlamani 12
I Agree .Autorabit is great tool to automate deployments in salesforce world 
PaqsPaqs
Hi Tyler,

If you use BitBucket/Jira you can also look at Bamboo which does a magnificient job as well. Check out this link: https://developer.atlassian.com/sfdc