servicenow - 在 Servicenow 中使用更新集时的标准开发实践

Question

我是 Servicenow 的新手，正在研究 ServiceNow 的功能。我试图了解我们如何在 ServiceNow 中实现标准开发最佳实践。

• 版本控制
• 持续集成/持续交付
• 源代码集成与代码审查

到目前为止，我从 SNOW 文档中找到了一些信息。

• Source control integration
• Team Development

到目前为止，当多个开发人员工作时，团队开发似乎是最佳选择。但由于它需要单独的独立实例，因此成本似乎更高。

我已经使用更新集进行了开发，我需要知道使用更新集时如何进行代码审查？

此外，根据我的经验，更新集似乎并不是孤立的开发方法。因此，更新集似乎不像 GIT 中的分支那样工作。

您能否告诉我哪些 SNOW 实践非常适合我的要求。

谢谢。

Answer 1

更新集类似于 Git 中的提交。您将更改的所有内容打包到一个更新集中，并且您的提交消息是更新集的描述。

对于审查过程，我们通常会将任何更新集从开发实例拉入测试实例，并在将其提交到测试实例之前检查更新集。然后，您可以将更新集提交到测试实例，以确认其按预期工作，然后再将其推送到生产环境。

这个过程本质上是

• 在更新集中进行开发更改
• 将更新集拉入测试以审查和测试更改
• 测试完成并正常运行后，从测试转向生产

您还可以通过将一个更新集设置为另一个更新集的父级来将更新集捆绑在一起。

这将允许您让多个更新集一起工作，并可能让多个开发人员处理一组更改。

对于源代码控制集成，它仅适用于 ServiceNow Studio，并且通常仅用于自定义应用程序。在这种情况下，每个单独的 XML 文件都存储在 git 存储库中，并通过提交跟踪文件的更改。