Share via

使用具有解决方案文件的源代码控制

  • 项目

 

发布日期： 2017年1月

适用于： Dynamics 365 (online),Dynamics 365 (on-premises),Dynamics CRM 2016,Dynamics CRM Online

SolutionPackager 工具可以用于所有源控件系统。 在解决方案 .zip 文件被解压到文件夹后，请向源控件系统添加和提交文件。 可以在在另一台计算机上对这些文件进行同步，并将它们打包到一个新的相同的解决方案 .zip 文件中去。

在源控件中使用提取的组件文件时的一个重要方面是：将所有的文件添加到源控件中可能会产生多余的副本。 请参阅Solution component file reference (SolutionPackager)，查看每个组件类型产生了哪些文件，哪些文件适合用于源控件。

因为进一步的自定义和更改对解决方案来说是必要的，所以开发商应该通过现有的方法编辑或自定义组件，重新导出并创建 .zip 文件，并且将压缩的解决方案解压到同一个文件夹中。

重要

不支持手工编辑解压的组件文件和 .zip 文件。

当 SolutionPackager 工具解压组件文件时，如果文件内容是相同的，它不会覆盖同一个名字的现有组件文件。 另外，该工具支持组件文件的只读属性，会在控制台窗口中出现特殊文件不可编写的警告。 这使得用户可以在源控件中检查正在改变的最小文件集。/clobber 参数可以用于替代、改写或删除只读文件。/allowWrite 参数可以用于估计解压操作在不真正改写或删除任何文件的情况下会产生什么影响。/allowWrite 与详细日志记录一起使用是很有效的。

在完成解压操作并且检查完源控件中的最小文件集之后，开发商也许会像处理所有其他类型的源文件一样，将更改后的文件交回到源控件中去。

本主题内容

团队开发

创建解决方案

修改解决方案

团队开发

如果多位开发商操作同一个解决方案组件，可能会出现两位开发商同时更改一个文件的冲突情况。 将每个单独的可编辑组件或子组件分解到一个不同的文件中，可以最大程度地低降低这种情况发生的可能性。 考虑以下示例。

  1. 开发商 A 和 B 正在致力于同一个解决方案。

  2. 他们在各自的计算机上从源控件得到最新的解决方案来源，将一个非托管解决方案 .zip 文件打包并导入各自的 Microsoft Dynamics 365 组织。

  3. 开发商 A 自定义“可用联系人”系统视图和联系人实体的主要窗体。

  4. 开发商 B 自定义帐户实体的主要窗体并更改“联系人查询视图”。

  5. 两位开发商均导出一种非托管解决方案 .zip 文件并解压缩。

    1. 开发商 A 需要检查一个联系人主窗体文件和一个“可用联系人”视图文件。

    2. 开发商 B 需要检查一个帐户主窗体文件和一个“联系人查询视图”文件。

  6. 两位开发商可以按任何顺序提交，因为他们分别更改了单独的文件。

  7. 两个开发商都提交完成后可以重复步骤 #2，然后继续在独立的组织中做进一步的更改。 他们各自都有两套变动，不会覆盖自己的操作。

只有对单独的文件分别作出修改时，先前的示例才会起作用。 独立自定义必然会要求在一个单一的文件内做出改动。 基于以上显示的例子，请考虑当开发商 B 已经自定义了“可用联系人”视图时，开发商 A 也在对其进行自定义的情况。 在这个新例子中，事件顺序变得重要。 解除这种困境的正确的详细过程如下：

  1. 开发商 A 和 B 正在致力于同一个解决方案。

  2. 他们在各自的计算机上从源控件得到最新的解决方案来源，将一个非托管解决方案 .zip 文件打包并导入各自的组织。

  3. 开发商 A 自定义“可用联系人”系统视图和联系人实体的主要窗体。

  4. 开发商 B 自定义帐户实体的主要窗体并更改“可用联系人”。

  5. 两名开发人员均导出非托管解决方案。zip 文件和提取。

    1. 开发商 A 需要检查一个联系人主窗体文件和一个“可用联系人”视图文件。

    2. 开发商 B 需要检查一个帐户主窗体文件和一个“可用联系人”视图文件。

  6. 开发商 A 先准备好。

    1. 在提交源控件之前，他必须得到最新的来源，以保证他所做的变动不会和先前的签入发生冲突。

    2. 没有发生冲突，因此他可以提交。

  7. 在开发商 A 之后，开发商 B 已经准备好了。

    1. 在提交之前他必须得到最新的来源，以保证他所做的变动不会和先前的签入发生冲突。

    2. 有冲突，因为他最后检索了最新的来源，修改了“可用联系人”文件。

    3. 开发商 B 必须解除这种冲突。 所使用的源控件系统的功能有可能可以辅助这个过程；否则可以进行以下选择：

      1. 如果开发商 B 可以查看源控件历史，他就可以看到开发商 A 之前所做的变动。 他们可以通过直接联系讨论每个变动。 然后开发商 B 只需要按照商定好的方案更新组织。 然后他导出、解压并覆盖出现冲突的文件并且提交该文件。

      2. 允许源控件覆盖本地文件。 开发商 B 打包该解决方案并将它导入自己的组织中，然后估计这个视图的状态，并根据需要对其进行自定义。 接着，他可能导出、解压和覆盖出现冲突的文件。

      3. 如果开发商 B 认为先前的变动是不必要的，他可以允许自己的文件覆盖源控件的版本并且提交。

无论是在共享的组织中运作还是在独立的组织中运作，对 Microsoft Dynamics 365 解决方案进行团队开发都要求经常运作解决方案的人清楚其他人所做的工作。SolutionPackager 工具不会完全取消这种要求，但它确实使得在源控件水平上合并非冲突变化变得容易，并且会主动突显发生冲突的地方。

以下部分是在进行团队开发时在源控件中有效地使用 SolutionPackager 工具的通用过程。 这些同样适用于独立组织和共有的开发组织，尽管对于共有组织来说这种导出和解压操作将会自然地包括当前解决方案中的所有变动，而不仅仅是那些进行导出操作的开发商所做的修改。 同样，当导入解决方案 .zip 文件时，会自动发生覆盖所有组件的行为。

创建解决方案

第一次创建解决方案时，可以通过以下流程标识典型的步骤：

  1. 在一个干净组织中的 Microsoft Dynamics 365 服务器上创建一个解决方案，然后根据需要添加或创建组件。

  2. 当您准备签入时，请执行以下操作：

    1. 导出非托管解决方案。

    2. 使用 SolutionPackager 工具，将解决方案解压到组件文件中去。

    3. 从那些解压的组件文件中，将必要的文件添加到源控件。

    4. 提交对源控件所做的这些更改。

修改解决方案

当修改现有的解决方案时，可以通过以下流程标识典型的步骤：

  1. 同步或获取最新的解决方案组件文件来源。

  2. 使用 SolutionPackager 工具，将组件文件打包到非托管解决方案 .zip 文件中。

  3. 将非托管解决方案导入到一个组织中。

  4. 如有必要，请自定义和编辑解决方案。

  5. 当您准备检查对源控件所做的修改时，请执行以下操作：

    1. 导出非托管解决方案。

    2. 使用 SolutionPackager 工具，将解决方案导出到组件文件中去。

    3. 从源控件中同步或获取最新的来源。

    4. 如果存在任何冲突，请解除冲突。

    5. 提交对源控件所作的更改。

在发展组织中进一步自定义之前，必须先完成第 2 步和第 3 步。 在第 5 步中，必须在步执行 c 步骤之前完成步骤 b。

另请参阅

团队开发解决方案的工具
Solution component file reference (SolutionPackager)
使用 SolutionPackager 工具压缩并提取解决方案文件

Microsoft Dynamics 365

© 2017 Microsoft。 保留所有权利。 版权