asp.net 5 中客户端任务运行器的替代方案
Alternative to client side task runners in asp.net 5
我一直在使用 Visual Studio 团队服务（Visual Studio 在线）进行版本控制。作为备份，我将我的项目文件保存在 OneDrive 上，并将根工作空间映射到那里。在 RC 1 发布并支持 Azure 后不久，我们就开始将所有项目迁移到 ASP.NET5，一切都非常顺利，我真的很喜欢用于客户端开发的 GruntJS 任务运行器，但是问题是节点模块创建了一个高度嵌套的文件夹结构，导致 OneDrive 同步失败。
客户端开发在 TypeScript 中进行，grunt 仅用于编译的 JavaScript 文件的捆绑和缩小目的。由于 Web 优化不是 ASP.NET 5 中推荐的方法，而且我找不到 .NET Core 的任何端口
在寻找解决方案时，我在某个地方偶然发现了一个 link，它说 OneDrive for Business 没有此限制，我们有组织的 Office 365 订阅并尝试在那里同步项目，但同样失败OneDrive for business 有此限制。
虽然有一个 UserVoice suggestion for this，Microsoft 代表说他们正在考虑这个问题，但是在这个实现之前，我想为 ASP.NET 寻求 GruntJS 的替代方案 5 .
由于我们构建的大多数应用程序都是单页企业应用程序，用户在工作日开始时打开应用程序并在一天结束时关闭选项卡，很少刷新应用程序，因此我们暂时可以不用优化，但出于对面向消费者的应用程序的好奇，GruntJS 是否有任何替代品 ASP.NET 5.
编辑
注意事项
- TFS 签入仅在需要提交代码时发生，但 OneDrive 同步会在硬件崩溃或设备丢失（或世界上任何阻止我们访问的任何原因）的情况下自动在后台自动连续发生代码），TFS 将无法提供未提交的正在开发中的代码。 OneDrive 将我们从那些场景中拯救出来
- 签到主要发生在积压工作中分配任务的很大一部分完成时。在 50% 的情况下，它是 2-6 个工作小时，但在其余一半情况下，它可能会在 2-3 个工作日左右发生，最坏的情况是 5 天，以防假期发生在两者之间。
- 一个驱动器允许我们停止将实时可用的选定文件夹同步到本地，但我们无法停止将本地文件夹同步到实时
- 假定硬件故障的可能性为每年一次，导致损失 5 个工作日，并且放弃进度是不可接受的风险。 （在我的开发机器上安装 visual studio 具有所有功能的企业大约需要 5-8 小时，配备第 4 代 Intel i5 2.9GHz 16GB 内存，我们计划用 SSD 和 64 GB 内存升级我们的开发机器，但是这超出了问题的范围）
- 如果我们权衡花费在优化任务上的额外时间与丢失文件的风险，优化只会在我们将更新推送到生产服务器时发生，每月发生 1-3 次，每一轮优化任务不会花费更多时间超过 10-15 分钟，因此我们可以忍受在生产前手动优化文件或根本不优化。
- 像 .gitignore and.csproj 这样的文件允许将哪些文件同步到 TFS 而不是 OneDrive，我的问题根本不在 TFS 上，我们对 Check Ins 的完成和管理方式非常满意，一旦代码提交了，所有的烦恼都自动解决了，我的烦恼只是针对未提交的代码。
总结
我同意这个问题具有高度的特殊性，但它可能对未来寻找类似解决方案或只是为了获得更多知识的读者有所帮助。
两件事：
Team Foundation Services / Visual Studio 在线是您的源代码管理解决方案，为什么您需要/想要在其他地方备份它？
无论如何，我可能会将您的节点模块从同步中排除。您的项目配置文件将包含您需要的节点模块列表，如果您想将应用程序移动到新机器或文件夹，您只需再次 运行 npm install 来下载包。
编辑：
TFS Check in happens only when a code needs to be committed, but
OneDrive sync happens continuously in the background automatically, in
the event of a hardware crash or device getting lost (or any reason in
the world stopping us from accessing the code), TFS won't be able to
provide the code under development which was not committed. OneDrive
saves us from those scenarios
这表明您的签到可能太大或不够频繁。
你多久检查一次？您的硬件发生故障以致丢失所有文件的频率是多少？这是可接受的风险吗？
One drive allows us to stop syncing of selected folders available on live to local but there is no way we can stop sync of local folders
to live
这就是为什么您应该使用 TFS/VSO 作为控制源代码控制存储库中存储的文件的机制。 .gitignore 或 .csproj 文件之类的系统正是出于这个原因而存在。
编辑 2：
我尽量不要太苛刻，我同意这是一个可能可以通过 OneDrive 以某种特定方式解决的问题，但我正在尝试执行与 5 Whys 等价的 SO .
你说过：
TFS won't be able to provide the code under development which was not committed. OneDrive saves us from those scenarios
和
Check in happens mostly when a significant portion of assigned task in backlog is completed. In 50% of the cases it's 2-6 working hrs but in the rest half it can happen around 2-3 business days, worst case scenario is 5 days in case holidays happen in between
好的，让我们谈谈这个。您希望在硬件出现故障时防止代码丢失，当然我们都这样做。查看您的数字 2-6 个工作小时似乎是合理的，因此您正在考虑减少 0.25 到 1 天（大概）。我认为更大的问题是人们是否有 5 天没有登记入住。您已经提到 5 天可能是最坏的情况，而且只有在节假日发生的情况下，所以这不是 5 个工作日，而是 2-3 个工作日，最坏的情况。
然后你说：
Possibility of hardware failure is assumed to be once a year resulting in a loss of 5 working days
所以，上面您说的是 2-6 小时的签到时间（有例外），但您是基于 5 个工作日的假设来决定为此问题提出解决方案的。上面你说只有在假期发生时才 5 天（不工作）。所以你的风险数字确实被夸大了。
让我们更现实一点，假设您每年发生一次硬件故障，而您损失了 4 个小时的工作时间。
从 OneDrive 恢复这项工作需要多长时间？让我们猜测说几分钟来连接和下载它，也许半小时到一个小时来解决冲突（#optimism）。所以假设净节省 3 小时......每年一次......你认为这足以将所有代码备份到异地云提供商吗？
您谈到重新安装 VS 所花费的时间，但这与将文件备份到 OneDrive 无关，无论如何您都需要这样做。
老实说，我认为您对丢失未提交代码的恐惧被夸大了，我认为您的反应也是如此。 TFS 和 VSO 提供了类似搁置集的功能，可以用于这种情况。
作为一名企业开发人员，我确实理解这种担忧，但通常你会通过在带有 RAID 阵列或类似设备的机器上工作来解决这个问题。
我认为您应该重新评估您的签入政策以及您对丢失代码的可能性的评估。
我一直在使用 Visual Studio 团队服务（Visual Studio 在线）进行版本控制。作为备份，我将我的项目文件保存在 OneDrive 上，并将根工作空间映射到那里。在 RC 1 发布并支持 Azure 后不久，我们就开始将所有项目迁移到 ASP.NET5，一切都非常顺利，我真的很喜欢用于客户端开发的 GruntJS 任务运行器，但是问题是节点模块创建了一个高度嵌套的文件夹结构，导致 OneDrive 同步失败。
客户端开发在 TypeScript 中进行，grunt 仅用于编译的 JavaScript 文件的捆绑和缩小目的。由于 Web 优化不是 ASP.NET 5 中推荐的方法，而且我找不到 .NET Core 的任何端口
在寻找解决方案时，我在某个地方偶然发现了一个 link，它说 OneDrive for Business 没有此限制，我们有组织的 Office 365 订阅并尝试在那里同步项目，但同样失败OneDrive for business 有此限制。
虽然有一个 UserVoice suggestion for this，Microsoft 代表说他们正在考虑这个问题，但是在这个实现之前，我想为 ASP.NET 寻求 GruntJS 的替代方案 5 .
由于我们构建的大多数应用程序都是单页企业应用程序，用户在工作日开始时打开应用程序并在一天结束时关闭选项卡，很少刷新应用程序，因此我们暂时可以不用优化，但出于对面向消费者的应用程序的好奇，GruntJS 是否有任何替代品 ASP.NET 5.
编辑
注意事项
- TFS 签入仅在需要提交代码时发生，但 OneDrive 同步会在硬件崩溃或设备丢失（或世界上任何阻止我们访问的任何原因）的情况下自动在后台自动连续发生代码），TFS 将无法提供未提交的正在开发中的代码。 OneDrive 将我们从那些场景中拯救出来
- 签到主要发生在积压工作中分配任务的很大一部分完成时。在 50% 的情况下，它是 2-6 个工作小时，但在其余一半情况下，它可能会在 2-3 个工作日左右发生，最坏的情况是 5 天，以防假期发生在两者之间。
- 一个驱动器允许我们停止将实时可用的选定文件夹同步到本地，但我们无法停止将本地文件夹同步到实时
- 假定硬件故障的可能性为每年一次，导致损失 5 个工作日，并且放弃进度是不可接受的风险。 （在我的开发机器上安装 visual studio 具有所有功能的企业大约需要 5-8 小时，配备第 4 代 Intel i5 2.9GHz 16GB 内存，我们计划用 SSD 和 64 GB 内存升级我们的开发机器，但是这超出了问题的范围）
- 如果我们权衡花费在优化任务上的额外时间与丢失文件的风险，优化只会在我们将更新推送到生产服务器时发生，每月发生 1-3 次，每一轮优化任务不会花费更多时间超过 10-15 分钟，因此我们可以忍受在生产前手动优化文件或根本不优化。
- 像 .gitignore and.csproj 这样的文件允许将哪些文件同步到 TFS 而不是 OneDrive，我的问题根本不在 TFS 上，我们对 Check Ins 的完成和管理方式非常满意，一旦代码提交了，所有的烦恼都自动解决了，我的烦恼只是针对未提交的代码。
总结
我同意这个问题具有高度的特殊性，但它可能对未来寻找类似解决方案或只是为了获得更多知识的读者有所帮助。
两件事：
Team Foundation Services / Visual Studio 在线是您的源代码管理解决方案，为什么您需要/想要在其他地方备份它？
无论如何，我可能会将您的节点模块从同步中排除。您的项目配置文件将包含您需要的节点模块列表，如果您想将应用程序移动到新机器或文件夹，您只需再次 运行
npm install来下载包。
编辑：
TFS Check in happens only when a code needs to be committed, but OneDrive sync happens continuously in the background automatically, in the event of a hardware crash or device getting lost (or any reason in the world stopping us from accessing the code), TFS won't be able to provide the code under development which was not committed. OneDrive saves us from those scenarios
这表明您的签到可能太大或不够频繁。 你多久检查一次？您的硬件发生故障以致丢失所有文件的频率是多少？这是可接受的风险吗？
One drive allows us to stop syncing of selected folders available on live to local but there is no way we can stop sync of local folders to live
这就是为什么您应该使用 TFS/VSO 作为控制源代码控制存储库中存储的文件的机制。 .gitignore 或 .csproj 文件之类的系统正是出于这个原因而存在。
编辑 2：
我尽量不要太苛刻，我同意这是一个可能可以通过 OneDrive 以某种特定方式解决的问题，但我正在尝试执行与 5 Whys 等价的 SO .
你说过：
TFS won't be able to provide the code under development which was not committed. OneDrive saves us from those scenarios
和
Check in happens mostly when a significant portion of assigned task in backlog is completed. In 50% of the cases it's 2-6 working hrs but in the rest half it can happen around 2-3 business days, worst case scenario is 5 days in case holidays happen in between
好的，让我们谈谈这个。您希望在硬件出现故障时防止代码丢失，当然我们都这样做。查看您的数字 2-6 个工作小时似乎是合理的，因此您正在考虑减少 0.25 到 1 天（大概）。我认为更大的问题是人们是否有 5 天没有登记入住。您已经提到 5 天可能是最坏的情况，而且只有在节假日发生的情况下，所以这不是 5 个工作日，而是 2-3 个工作日，最坏的情况。
然后你说：
Possibility of hardware failure is assumed to be once a year resulting in a loss of 5 working days
所以，上面您说的是 2-6 小时的签到时间（有例外），但您是基于 5 个工作日的假设来决定为此问题提出解决方案的。上面你说只有在假期发生时才 5 天（不工作）。所以你的风险数字确实被夸大了。
让我们更现实一点，假设您每年发生一次硬件故障，而您损失了 4 个小时的工作时间。 从 OneDrive 恢复这项工作需要多长时间？让我们猜测说几分钟来连接和下载它，也许半小时到一个小时来解决冲突（#optimism）。所以假设净节省 3 小时......每年一次......你认为这足以将所有代码备份到异地云提供商吗？
您谈到重新安装 VS 所花费的时间，但这与将文件备份到 OneDrive 无关，无论如何您都需要这样做。
老实说，我认为您对丢失未提交代码的恐惧被夸大了，我认为您的反应也是如此。 TFS 和 VSO 提供了类似搁置集的功能，可以用于这种情况。
作为一名企业开发人员，我确实理解这种担忧，但通常你会通过在带有 RAID 阵列或类似设备的机器上工作来解决这个问题。
我认为您应该重新评估您的签入政策以及您对丢失代码的可能性的评估。