Jitterbit 的源代码控制/差异工具

Ter*_*ryK 5 git version-control diff github jitterbit

我一直在寻找一种使用 git/github 为我们的 Jitterbit (JB) 项目进行源代码控制的方法。

我们当前的解决方案是让一名开发人员手动输入并解释他们在 JB 项目内的自述文件中所做的更改,注明哪些脚本、转换、操作等已更改,以及更改的行号。

然后,为了“批准”更改,另一个开发人员需要在 JB 设计工作室中打开该项目,通读 README 文件,查找已更改的对象,找到 README 文件中注明的行并查看更改。来回发送电子邮件或 Slack 讨论任何问题。对每个改变的物体进行冲洗和重复。

这是非常麻烦和耗时的。

虽然我当然可以在 JB 项目文件夹中创建一个存储库,但这不太理想,因为即使在 JB 脚本中进行一行更改,也会显示许多不相关的元数据更改(与 JB 环境等相关)。与开发人员所做的实际代码更改无关的差异。当您开始在 JB 中切换环境时,情况会变得更加复杂。

我研究过使用带有过滤器的 .gitattributes 文件,该过滤器用于sed从具有实际开发代码更改的文件(JB 将它们存储为 .xml 文件)中删除元数据行,但这充其量是一个非常笨拙且容易出错的解决方案。

有没有人想出一种方法来使用 JB 的源代码控制,或者至少是某种 diff 工具解决方案,开发人员可以轻松地查看、审查、评论和批准/拒绝开发人员所做的更改(基本上,git 所做的所有更改)提供...或至少提供差异部分)?

小智 0

我已经设置了 Jitterbit 和 Git,对我来说效果很好。这是很多手动步骤,但我已经将它们做到了可以可靠地获得相当干净的差异的程度:

\n

A. 设置

\n
    \n
  • 有两个独立的 Jitterbit 环境。其中之一将是您要进行更改的“工作副本”;另一个是用于部署和版本控制的“干净副本”
  • \n
  • 与这两者分开,创建一个 Git 存储库
  • \n
  • 通过复制“干净”Jitterbit 环境文件夹的内容并提交它们来初始化存储库
  • \n
\n

B. 开设分支机构:

\n
    \n
  1. 在 Design Studio 中,从“干净”环境的云中执行恢复项目。这可以确保您拥有其他开发人员部署的任何更改

    \n
  2. \n
  3. 在“干净”环境中,选择“迁移项目”,将整个项目迁移到“工作”环境中

    \n
  4. \n
  5. 这将导致一堆随机元数据更改。现在就提交这些,这样它们以后就不会污染您的差异:

    \n
      \n
    1. 确保您的 Git 存储库包含您的main签出您的或等效的分支
    2. \n
    3. 删除 Git 存储库* 中的所有内容,然后复制并粘贴“干净”Jitterbit 文件夹的内容(就像您最初设置它一样)
    4. \n
    5. 由于 Jitterbit 元数据更新,Git 将显示一系列更改。提交这些并推送到您的main分支
    6. \n
    \n
  6. \n
  7. 现在实际创建 Git 分支(git checkout -b在 Git 存储库中)

    \n
  8. \n
\n

C. 进行更改:

\n
    \n
  1. 在 Design Studio 中,确保您处于“工作”环境中。(由于步骤 B.1 和 B.2,这将与部署的代码同步)

    \n
  2. \n
  3. 正常处理项目,但每次更改某些内容时,仅迁移更改的元素迁移到“干净”环境(使用项目元素侧边栏列表中的右键单击菜单)

    \n
  4. \n
  5. 要提交您的更改:

    \n
  6. \n
  7. 从 Git 存储库中删除所有内容并再次将其替换为“干净”环境

    \n
  8. \n
  9. Git 更改将仅显示您迁移的文件。像平常一样添加并提交这些内容

    \n
  10. \n
\n

D. 审查和部署

\n
    \n
  1. 将您的分支与main使用进行比较git diff平常您仍然会看到一些不相关的元数据更改,但仅在迁移的文件\xe2\x80\xa0 中
  2. \n
  3. 当您准备好合并时,从 Design Studio 开始,并将整个“工作”环境迁移回“干净”副本。(我通常首先在“工作”环境中部署和测试项目作为额外检查)
  4. \n
  5. 将项目部署到“干净”的环境
  6. \n
  7. 在 Git 存储库中,将您的分支合并到main并签出main分支\xe2\x80\xa1
  8. \n
  9. 删除 Git 存储库中的所有内容并再次将其替换为“干净”的副本
  10. \n
  11. 更多元数据更改将显示在 Git 中。这些应该可以很好地提交,因为您已经完成了对分支的审查
  12. \n
\n
\n

*这种删除 Git 存储库并从 Jitterbit 复制的方法可确保提交的代码始终与 Jitterbit 代码的某些版本相匹配。

\n

\xe2\x80\xa0我还有一个.gitattributes文件来进一步过滤这些。就我而言,我使用的是 XSLT 模板,我觉得它比sed.

\n

\xe2\x80\xa1我不建议让这一步出现合并冲突,因为下一步将消除它们。我还没有找到任何方法可以在不弄乱 Jitterbit 元数据和破坏内容的情况下进行 Git 合并,因此我避免在其他人打开分支时在 Jitterbit 中工作。

\n