1

I am dealing with a team of unmotivated sf dev/configurators. They are either refusing to learn git or are just slow. So, asking them to start the dev process using git and IDE is bringing in more unstability then agility. Our organization wants to adopt more agile way of doing things rather. So we want to implement some in-house pilot continuous integration and deployment process.

Since the usage of git is becoming a bigger challenge, i am kind of thinking to allow them to deploy their changes to to the sharedDEV using the old fashion changesets (which they are familiar with).

And i am setting up a Jenkins job to pull/retrieve the metadata from this sharedDEV org and version control it. The delta changes will be pulled in as we repeat this process again an again. And once they are in the source control, i will build the src components and package.xml based on the diff to validating and deployment to higher environments/orgs.

Question: Have anyone done this approach? And does any of the SF experts here foresee any issues with it?

NOTE: i am not looking for commercial product recommendations (like autorabbit, gearset ....etc )

3

Change sets have one very important feature missing: the ability to merge changes in code and detect potential overwrites to files. Basically, you're neutering one of the most important features of Git to provide developers some perceived comfort. You may as well just use ant and Jenkins to back up your code daily, because that's the only benefit you're getting from Git when you use it this way. We recently migrated to Git, and while it did take a little bit of effort to get everyone into the groove, we're more efficient than before, thanks to never losing changes and the ability to roll back a single file to any point in time.

  • Agreed with the features that are going to be missing by dropping git from the developers. But at this point - i am trying to get things going as our dev team is in sea with git. And i do have a job set, to perform daily backup of the prod metadata. But changesets overwrite files is a news.!!! So, you do mean if someone creates a new customfield. The new profile will overwrite the ones that are there in the server, rather then appending the new content? @sfdcfox – OK999 Aug 22 '17 at 16:47
  • @OK999 The longer you put off migrating to Git, the worse it gets. Also, if they want to use the really cool features, like Salesforce DX and CI, they need to learn Git. Salesforce DX automatically tracks changes in metadata in a scratch org, thus eliminating the need for manually building change sets, and with CI, they also wouldn't have to deal with the delay of "uploading" change sets and "deploying" change sets. Ultimately, they will save a lot of time using Git. – sfdcfox Aug 22 '17 at 16:55
  • @OK999 As far as custom fields, etc, deploying permissions with change sets is a nightmare, to the point where most orgs only change permissions manually after deployment. DX/Git resolves this situation by allowing you to merge permissions without much effort. The fields themselves can't be deleted this way (each field is a separate "file"), but then they have to remember to add the profiles to the change sets, and user permissions (like Modify Users) are always overwritten in a profile when using change sets. – sfdcfox Aug 22 '17 at 16:57
  • absolutely, can't escape the git. but like i said i want to get things rolling and then continue to push and train the herd. Finally, the force ecllipse ide sucks. it hangs big time, going to try mavens mate (hopefully it wont hang while doing save to server or sync with server). Any suggestion for a good ide (one that doesn't hang and free to start), we dont have a huge metadata – OK999 Aug 22 '17 at 16:59
  • @OK999 Depends on your preferences. I personally like Cloud9, but it costs money for more than one private repo. The Force.com IDE 2 is for DX, and it is absolutely amazing; no hangs because it uses the sfdx process in the background for retrieves/deploys. MavensMate is usually a favorite, but I haven't had much luck with it (my fault, not its fault). – sfdcfox Aug 22 '17 at 17:04
3

I think this process will give you a basic level of visibility, but a few things you should consider:

  1. You won't have any committer info such as author or commit message so your source control repository won't have the desired level of traceability
  2. Building those deployment packages is likely to be challenging, especially if there are a lot of changes in between your deployments from source control to the higher environments
  3. Depending on what you're retrieving from sharedDEV, you may have to do some tricks with the Force.com Migration Tool to get aorund the 10,000 file limit. You can run into that thing surprisingly quickly!

In short, I think this approach will give you some insight into the changes and allow you to monitor what is happening across the environments but you're likely to still have some very tricky deployments from sharedDEV to UAT and production.

  • yes, agreed with #1. what tricky things do you foresee? I thought this is the way SF migration guide is suggesting right? i.e. retrieve metadata from a dev org and push to another target org. The only difference here is, i am trying to retrieve and version it first. And instead of creating the package manually i am looking at using the open sourced - force-dev-tool npmjs.com/package/force-dev-tool – OK999 Aug 22 '17 at 16:41
  • Migrations using the Metadata API are anything but simple unfortunately, with things like dependencies proving to be a right pain. Getting a reliable deployment process with just the Force.com Migration Tool is possible to a degree but requires a very disciplined team and can require a lot of manual work – Kevin Boyle Aug 23 '17 at 9:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.