上传一些特定功能，但不是所有开发功能从开发到实时服务器
这或多或少与项目管理有关，也与每个开发人员有关。当您在开发站点上开发了许多功能并且所有功能都经过客户测试并准备好上线时，你们如何处理这种情况。
这些功能在公共文件中有一些代码，即。一个 PHP 文件包含一项功能和另一项功能的代码。
但是客户端会要求您只上传 10 或 15 个功能中的 2 个。文件是常见的，如果直接上传该文件会导致错误问题，因为它们有其他功能的代码。如果您上传所有更新的文件，那么所有功能都将生效。
一种可能的方法是返回并从公共文件中注释掉目前不需要的功能。但也有可能忘记在其他地方发表评论。
这也不是一个好方法，最后客户会说发生了什么，一切都在开发服务器上进行了测试，以及为什么这些错误和错误会在实时服务器上引入。 这将降低对开发商的信心。
我多次遇到这个问题，但找不到任何好的方法来避免这些问题。所以我认为你们也面临或面临过这个问题。
我认为版本控制系统可以在这里提供帮助。
你们如何处理这件事？
你能分享一下想法吗？
This is more or less related to project management and also with every developer. How you guys handle this situation when you have developed many features on development site and all are tested by client and ready to go live.
These features have some code in common files ie. One PHP file have the code for one feature as well as one other feature.
But client will ask you to upload only 2 feature out of 10 or 15. Files are common if you upload that file directly will leads to error problems because they have code for other features. If you upload all updated files then all feature will be live.
A possible way is go back and comment out that feature which is not needed live for now from common files. But there is possiblities to forgot to comment anywhere else.
This is also not a good way and at last client will say what happen everything was tested on development server and why these bugs and errors are introduced on live server.
This will reduce the faith on developers.
I faced this problem many times and could not found any good way to avoid these issues. So I am thinking that you guys also facing or faced this problem.
I am thinking versioning system can help here.
How you guys are handling this?
Could you share ideas?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
您所描述的情况是不可能理智管理的。我不相信这种情况能够发生，但真正的问题是你为什么要这么做？
您描述的场景存在很多问题，但核心问题确实是这样。您正在测试一件事，并部署另一件事。您在问题中承认变化的相互关联性。事实上，这比你描述的还要困难。当您尝试部署已测试解决方案的一部分时，您根本无法知道系统将如何运行。为什么要测试它？
我能看到的唯一明智的解决方案是拥有一个演示新功能的沙箱环境。但是，请保留您的测试环境仅用于测试将要上线的内容。因此，在您的示例中，一两个功能正在测试中，准备好进行产品签名，其他功能则被锁定在沙箱中。
这导致了下一个问题，即管理源代码。我没有看到任何明智的策略来管理代码库中任意包含的功能。即使在我所知道的最灵活的系统 Perforce 下，当您尝试将内容移入和移出时，任何分支策略都需要对合并进行糟糕的解决。
我已经看到这种情况发生，相信我，它会变得非常丑陋。
我建议你想出一个更好的解决方案。与您的客户交谈并改变做事的方式。这对你来说更好，从长远来看对他们也更好。
The situation you are describing is impossible to manage sanely. I don't believe it would be possible to make this situation work, but the real question is why would you want to?
There are a number of issues with the scenario you describe, but the core issue is really this. You are testing one thing, and deploying another. You acknowledge in your question the interconnected nature of changes. In reality it is even more difficult than you describe. You simply cannot know how a system will behave when you try and deploy parts of a tested solution. Why test it at all?
The only sensible solution I can see is to have a sandbox environment where new features are demonstrated. However keep your test enviornment only for testing stuff that will go live. So in your example the one or two features are in test, ready to be signed off for prod, and the other featues are locked in the sandbox.
This leads to the next problem, which is managing your source code. I don't see any sane strategy for managing the arbirtrary inclusion of features from a code base. Even under the mostflexible system I know, Perforce, any branching straegy would require awful resolves on merges as you try to move stuff in and out.
I have seen this happen, and believe me it gets very ugly.
I suggest you come up with a better solution. Talk to your client and change the way things are done. It will be better for you, and in the long run better for them.
解决方案可能是使用 VCS 提供的廉价版本分支，例如 Git 或 Mercurial。该项目将包含许多功能分支，用于开发所述功能并构建分支，其中功能分支将被合并并进行临时修复。当构建分支准备好进行测试时，将对其进行测试，并根据需要进行修复，然后将构建分支发送到生产平台。
当功能经过验证后，构建分支可以合并到剩余的功能分支中，以便正在开发的分支可以集成“官方”更改。
总而言之，该应用程序是根据需要从现有功能分支定制构建的。
A solution could be to use cheap version branching as provided by VCS such as Git or Mercurial. The project would consist in many feature branches used to develop said features and build branches where feature branches would be merged and adhoc fixing would take place. When a build branch is ready for test, it is tested, fixed if needed and then the build branch is shipped to production platform.
When features have been validated, the build branch can be merged into remaining feature branches so the branches under development can integrate the "official" changes.
To sum up, the application is custom built from existing feature branches as needed.
在代码级别上管理此问题的一种合理的方法是将每个功能隔离到插件中。然后，您只需启用或禁用相应的插件即可按需添加/删除功能。
但此解决方案有一定的成本：
为您的应用程序开发和测试插件引擎的时间
您需要测试每个插件配置（启用的插件集和他们的版本）将要部署。否则，存在此特定集不兼容的风险，最终用户将首先看到由此产生的崩溃、数据丢失或其他一些恐怖
需要额外的时间来编写插件，以使它们最小程度地相互依赖。
通常只有当您有许多具有不同需求的客户时才值得。就您而言，我建议向您的客户解释单独启用功能的成本，看看他们是否真的如此需要它。最有可能的是，他们不
One reasonably sane way to manage this on the code level is to isolate each feature into a plugin. Then you can add/remove features on-demand by simply enabling or disabling corresponding plugins.
But this solution has certain costs:
Time to develop and test plugin engine for your app
You need to test every plugin configuration (set of enabled plugins and their versions) that is going to be deployed. Otherwise there's a risk that this specific set is not compatible and end users would be first to see resulting crash, or data loss, or some other horror
Additional time to wirte plugins the way that they're minimally dependent on each other.
It's usually worth it only if you have many clients with different needs. In your case, I'd recommend explaining cost of separately enabling features to your client to see if they really need it this hard. Most likely, they don't