【发布时间】：2017-07-15 08:57:32
【问题描述】：
我想开发一个 vsts 扩展。
一个开发周期的描述过程是：
- 开发
- 包
- 发布
- 上传
- 测试
这对我来说听起来有点麻烦，因为测试开发需要很多时间。
有什么方法可以加快开发周期？
有什么方法可以模拟 TFS？
【问题讨论】：
标签： azure-devops azure-devops-extensions
【发布时间】：2017-07-15 08:57:32
【问题描述】：
为了加快开发速度，您可以将扩展清单中的 baseURI 属性设置为 localhost。
您只需要部署一次“localhost-extension”，因为它总是指在您的机器上本地运行的实例。
整个过程在以下博客文章中进行了描述： https://realalm.com/2016/03/11/debugging-your-vsts-extension/
【讨论】：
-
对于 UI 扩展，这是要走的路。
一言以蔽之，就是 webpack。
这是一篇写得很好的文章。它解释了
所需的所有步骤和工具- CI/CD
- 自动化测试
- 开发周期时间
- 依赖和依赖管理
该功能称为热重载和调试。
仍然对操作步骤一无所知： 关注this devblogs link 及其在this GitHub repo 中的示例代码。
【讨论】：
不，不能，扩展需要部署到VSTS，然后你可以测试它。
有VSTS Extension Tasks extension可以方便打包发布。
【讨论】：
-
感谢您的回答。这不是我期望读到的。但现在我知道该怎么做了。谢谢。
-
哪些事情你知道该怎么做？测试扩展的方法？
-
现在我知道如何开发扩展了。这是有据可查的。
嗯.. 有一种方法可以做到这一点，至少在您可以管理的自托管代理上测试扩展的情况下。
每个代理都将扩展数据存储在代理主目录内的_work/_tasks/<extension_name><Extension_GUID>/<version> 中 - 例如。 C:\VSTSagents\Agent01\_work\_tasks\OctopusCreateRelease_4e131b60-5532-4362-95b6-7c67d9841b4f\3.0.168.
没有什么能阻止你在那里玩扩展的内部结构，因此你可以轻松地替换任何内容甚至所有文件来测试你的最新更改。
但是，请考虑到这些更改仍会影响使用此代理的其他用户，因此如果您决定这样做，那么在生产代理之外使用特殊代理听起来是个好主意。
【讨论】：
-
这对于构建任务是正确的，但对于 UI 扩展却不是。我做这一切的配合，只要你的任务 UI 保持不变，你可以调整你想要的所有脚本。对于使用 VSTS 任务 SDK 的构建任务，您可以简单地在本地运行它们。