构建快照与本地编译代码的争论？
我们有大量的项目。它是使用 ant 目标构建的，该目标调用一堆单独的 Maven 项目。
问题是，每当其他开发人员将代码提交到与我正在开发的项目不同的项目时，我都必须更新代码并在本地重新构建，以确保我根据最新版本进行编译。这需要每次等待 30-60 分钟才能测试代码更改。
我们希望在“快照”jar 上运行所有项目，因此每次发生代码更改时，我们的本地构建都应该简单地下载最新的快照。
有人担心，由于持续集成服务器需要一个多小时来构建项目，因此我们的快照可能比最新代码晚一个小时，并且基于它们构建并不能保证我们的代码根据最新代码进行编译。
这是一个常见的问题吗？如果是，如何缓解？对于切换到使用快照所获得的价值，我可以向我的团队提出什么好的论据吗？
We have a large group of projects. It's build using ant targets which invoke a bunch of separate maven projects.
Problem is, any time a fellow developer commits code to a separate project from the one I'm working on, I have to update the code and re-built locally in order to ensure I'm compiling against the latest. This involves waiting between 30-60 mins every time just to test code changes.
We'd like to run all the projects off 'snapshot' jars, so each time a code change occurs, our local builds should simply download the latest snapshots.
The concern was raised that, since the continuous integration server takes over an hour to build the projects, our snapshots may be an hour behind the latest code, and building off them wouldn't be a guarentee that our code compiles against the latest.
Is this a common concern, and if so, how can it be mitigated? Are there any good arguments that I can make to my team for the value-gained in switching to using snapshots?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
如何让更改组件接口的任何人也负责确保依赖于该组件的所有组件仍然可以工作，即单个提交包含 API 更改、实现更改以及针对新版本构建所有其他组件所需的更改。
这会鼓励人们对不兼容的 API 更改进行长时间的思考，并且在提交不再编译的组件时还会导致版本控制中的显式冲突。
根据您的内部策略，您还可以允许引入新的 API，同时将旧版本标记为已弃用，同时仍保持功能不变；但是我发现这对其他开发人员有点不礼貌。
How about making anyone who changes a component's interface also responsible for making sure that all components depending on it also still work, i.e. a single commit contains the API change, the implementation change and the changes required to make all other components build against the new version.
This encourages thinking long and hard about incompatible API changes, and also leads to explicit conflicts in the version control when committing a component that would no longer compile.
Depending on your internal policy, you can also make it acceptable to introduce new APIs and at the same time mark the old version as deprecated while still leaving the functionality intact; however I find that to be somewhat impolite towards your fellow developers.
在确保代码是最新的时，一小时前的代码真的会成为交易破坏者吗？除非有重大更改或重写，否则我看不出一项更改会如何破坏其他所有内容。
我还看到您目前的情况是编译每个构建的所有依赖项，大约需要 30-60 分钟。根据最近可用的构建来编译您的项目不是很好吗？我假设这需要大约 5-10 分钟，然后继续编程？
我也不明白一个重大的改变怎么会不会造成破坏。当您针对一个小时前的依赖项构建签入代码，然后该依赖项更改为破坏您的代码的位置时，您的代码仍然被破坏。当修复发生时，你现在只需移动一下即可。
Is hour old code really going to be a deal breaker when making sure that code is up to date? Unless there are major changes or rewrites then I couldn't see how one change would break everything else.
I also see that your current situation is to compile all the dependencies on each build which takes about 30-60 minutes. Wouldn't it be nice to compile your project against the most recently available build, which would take I assume something like 5-10 minutes, then move on with programming?
I also don't see how a major change isn't going to be break stuff anyway. When you checkin code against an hour old build of a dependency and then that dependency changes to where it breaks your code, your code is still broken. Your now just shifting around when the fix happens.