Source Code Control / Diff Tool for Jitterbit

Question

I've been looking for a way to use git/github for source code control for our Jitterbit (JB) projects.

Our current solution is for one dev to manually type out and explain the changes they've made in a README file within the JB project noting what scripts, transformations, operations, etc. have been changed and what line numbers the changes were made on.

Then to 'approve' the changes, another dev needs to open that project in the JB design studio, read through the README file, hunt down the object that was changed, find the line(s) noted in the README file and review the changes. Email or Slack back and forth to discuss any issues. Rinse and repeat for each object changed.

It's very cumbersome and time consuming.

While I can certainly create a repo in the JB projects folder, that's less than desirable because even with a one line change in a JB script, there are a lot of unrelated metadata changes (related to the JB environment, etc.) that show in the diff that have nothing to do with the actual code changes a dev makes. This gets even more complicated when you start switching environments in JB.

I've looked at using a .gitattributes file with a filter that uses sed to remove metadata lines from files (JB stores them as .xml files) that have actual dev code changes, but that's a very clunky and error prone solution, at best.

Has anyone figured out a way to use source control with JB, or, at least, some sort of diff tool solution where one dev can easily see, review, comment on, and approve/deny changes a dev makes (basically, everything that git provides...or at least the diff part)?

Answer 1

I've got a set up with Jitterbit and Git that works OK for me. It's a lot of manual steps, but I've got them to a point where I can get reasonably clean diffs reliably:

A. Setup

• Have two separate Jitterbit environments. One of these will be your "working copy" to make changes in; the other is a "clean copy" for deploys and version control
• Separate from both of these, create a Git repository
• Initialise the repository by copying in the contents of the "clean" Jitterbit environment folder, and committing them

B. To start a branch:

1. In Design Studio, do a Restore Project from Cloud of the "clean" environment. This makes sure you have any changes deployed by other devs

2. In the "clean" environment, select "Migrate Project" and migrate the entire project to the "working" environment

3. This will cause a bunch of random metadata changes. Commit those now so they don't pollute your diffs later:

   1. Make sure your Git repository has your main or equivalent branch checked out
   2. Delete everything from the Git repo*, and copy and paste in the contents of the "clean" Jitterbit folder instead (like you did to set it up initially)
   3. Git will show a bunch of changes due to Jitterbit metadata updates. Commit these and push to your main branch

4. Now actually create the Git branch (git checkout -b in the Git repo)

C. To make changes:

1. In Design Studio, make sure you're on the "working" environment. (This will be in sync with the deployed code due to steps B.1 & B.2)

2. Work on the project as normal, but each time you change something, migrate just the changed element to the "clean" environment (using the right-click menu in the sidebar list of project elements)

3. To commit your changes:

4. Delete everything from the Git repo and replace it with the "clean" environment again

5. Git changes will show only the files you migrated. Add and commit these as you usually do

D. To review and deploy

1. Compare your branch with main using git diff like you usually do. You'll still see some irrelevant metadata changes, but only in the migrated files†
2. When you're ready to merge, start in Design Studio, and migrate the entire "working" environment back to the "clean" copy. (I usually deploy and test the project in the "working" environment first as an extra check)
3. Deploy the project to the "clean" environment
4. In the Git repository, merge your branch into main and check out the main branch‡
5. Delete everything in the Git repo and replace it with the "clean" copy again
6. A bunch more metadata changes will show up in Git. These should be fine to commit as you've already done your review of the branch

---

* This delete-Git-repo-and-copy-from-Jitterbit approach makes sure that the committed code always matches some version of Jitterbit code.

† I also have a .gitattributes file to further filter these. In my case I'm using an XSLT template, which I feel is a bit better adapted to filtering XML than sed.

‡ I don't recommend letting this step have merge conflicts as the next step will obliterate them. I haven't found any way to do a Git merge without messing up the Jitterbit metadata and breaking things, so I avoid working in Jitterbit while anyone else has a branch open.