有没有办法让未混淆的 JavaScript 过期？
目前，我们的开发人员对 JavaScript 代码进行了取消混淆处理，以便他们可以在发布到生产环境之前更好地对我们的代码进行质量检查。
然而，有时，他们忘记在发布到生产环境之前混淆代码。
我想知道是否有一种方法可以使未混淆的 javascript 过期，这样，即使 QA 开发人员忘记混淆 js，它也会在一定时间范围（例如 12 小时）后自动混淆 js？
Currently, our developers unobfuscate the javascript code so they can better QA our code in staging before we release to production.
However, sometimes, they forget to obfuscate the code before releasing to production.
I was wondering if there is a way to expire unobfuscated javascript so that, even if the QA developers forget to obfuscate the js it will auto obfuscate the js after a certain time frame (say 12 hours)?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
不，你所要求的没有意义。
问题在于您的流程：为什么在 QA 开发人员获得产品之前会发生混淆？为什么不在他们和最终客户版本之间（即使有必要）？
尝试重新设计代码在核心开发人员和客户手中之间的路径，而不是寻找业务问题的技术解决方案。
No, what you are asking for does not make sense.
The problem is with your process: why is the obfuscation happening before your QA developers get the product? Why is it not between them and the final customer release (even if it is necessary)?
Try redesigning the path the code takes between your core developers and the customers' hands instead of looking for a technical solution for a business problem.
Javascript 不会混淆自己，所以这个问题没有多大意义。
混淆是由构建/发布过程中的单独工具完成的。您需要的是改进/自动化部分发布过程，以消除该过程中出现人为错误的可能性。这可以通过更严格的手动流程或更多的自动化来完成。
一般来说，质量检查团队应该测试与最终站点上部署的完全相同的代码，因此如果代码被混淆，那么这就是质量检查应该测试的内容。因此，首先，我会回顾一下 QA 正在做什么以及为什么这样做。他们应该测试混淆的代码。
如果 QA 出于任何原因需要审查未混淆的代码（我自己想不出任何可能的原因），那么他们应该在自己的系统上制作自己的未混淆的代码副本，并且不应将未混淆的代码放在任何地方在发布过程中。
最后，听起来您会受益于构建一个自动发布流程，该流程进行混淆并部署到 QA 测试环境，并将相同的流程部署到您的生产服务器。这保证了混淆到位，并且 QA 正在测试发布时将投入生产的完全相同的位。
Javascript does not obfuscate itself so this question doesn't make a whole lot of sense.
Obfuscation is done by a separate tool in the build/release process. What you need is to improve/automate part of the release process to remove the chances of human error in that process. This can either be done with a more rigorous manual process or with more automatation.
In general, the QA team should be testing the EXACT same code that gets deployed on the final site so if that's obfuscated, that's what QA should test. So, first of all, I'd review what QA is doing and why. They should be testing the obfuscated code.
If QA needs to review the unobfuscated code for any reasons (I can't think of any likely reasons myself), then they should make their own copy of the code on their own systems that is unobfuscated and should not be putting the unobfuscated code anywhere in the release process.
Lastly, it sounds like you would benefit from building an automated release process that does the obfuscation and deploys to both the QA test environment and the same process deploys to your production servers. That guarantees that obfuscation is in place and that QA is testing the exact same bits that would go to production when it's released.
你的流程是错误的。如果开发人员需要未混淆的 javascript 进行调试，请使服务器本身具有调试标志以返回未混淆的代码。默认为混淆代码。要求两人都在场。在发布过程中将混淆处理到发布脚本中。
您不希望对正在部署的构建之外的其他内容进行 QA 测试，因此事后进行混淆是不理想的（想象一下您在混淆器中遇到了错误......尽管看起来很可能，您是否愿意在 QA 中捕获它，或者直到它达到产品版本为止？
通过默认混淆代码，但允许通过会话状态或 cookie 的纯代码，您可以获得正确测试的版本和易于调试的版本。
Your process is wrong. If the devs need unobfuscated javascript for debugging, make it such that the server itself has a debug flag to return unobfuscated code. Default to obfuscated code. Require both be present. Work the obfuscation into a release script in the release process.
You don't want QA testing something other than the build you're deploying, so obfuscating after the fact is unideal (imagine you hit a bug in the obfuscator... as likely as it seems, would you rather catch it in QA, or not until it hits prod?
By defaulting to obfuscated code, but allowing plain code via say session state or cookie, you get both correctly tested releases, and easily debuggable ones.