[SalesForce] Flows/Processes, Version Control and CI

I've started using Processes and Flows and am really excited about these features — but am still wrapping my mind about how to manage them in Version Control (which I use) and Continuous Integration (which I don't yet… but am trying to work in that direction).

The underlying challenge is that each time a process or flow is edited, the metadata file is renamed to reflect its update version, e.g. MyFlow-1.flow, MyFlow-2.flow, etc.

The Challenge for Version Control

If each version of the flow has its own file name, this makes it more complicated to track changes to flows. It seems like there could be two strategies here:

  1. Rename the files to remove the version number. I'd need a script to run through my src folder pre-commit, and remove the number so that my file name is always MyFlow.flow. This is an annoying extra step, but makes version control simpler. On the other hand, it probably makes deployment much harder.

  2. Track each file in version control with its original name. We'd need to be diligent about deleting MyFlow-1 in the commit where we add MyFlow-2 so that git would recognize this as a rename/move and show helpful diffs. Otherwise, the whole file appears to change with every change, which makes version control rather less useful.

The Challenge for Deployment/Continuous Integration

From my experiments so far, once a flow has been activated in a given environment, the metadata file can't be deployed again (either it is currently active, or has been active in the past and superseded).

That means that I need to prevent my previous flow versions from being included in a deployment package (either by not tracking them at all, or by using a script to delete earlier versions). I also need some way to determine whether the current version (in my repo) should be included in the deployment payload for a given environment or not.

I could imagine a script that (1) downloads flows from the target environment, and removes *.flow files from the payload if they already exist in the target environment, but that feels complicated. And it's even harder if I've removed the version numbers from my flow files.

Are you using flows in VS or CI? How are you managing these issues?

Note: I'm not sure whether VC and CI should be one question or two – depends on how integrated the strategy for dealing with these two challenges. If you think these should be separate questions, comment and I'll re-post.

Best Answer

The trick is to disable the deployment of the flows with build property. Let say you want to skip flows deployment normally and just deploy them if they don't exist. You have to do following steps:

  1. Add following snippet to you src/package.xml 

       <!--TO_REMOVED-->
       <types>
         <members>My_Flow-33</members> 
         <name>Flow </name>
       </types>
       <!--TO_DELETE-->
  1. Use following ant code 

    <target name="flowRequired">
        <condition property="includeFlow">
            <equals arg1="${deployFlow}" arg2="true"/>
        </condition>
    </target>

    <target name="deployFlow" unless="includeFlow"  depends="flowRequired">
        <replace file="src/package.xml">
            <replacefilter value="" token="TO_REMOVED--"/>
        </replace>        
        <replace file="src/package.xml">
            <replacefilter value="" token="!--TO_DELETE"/>
        </replace> 
    </target>

In this setting if you don't pass parameter deployFlow or set it to false to you ant script it will replace the values in a way that that section becomes a comment in your package.xml file.

Related Topic