2008-10-02 59 views
2

这是从以前的问题I have asked引用从SVN构建工件:外部构建在.NET项目

的延续问题,我现在已经在我的项目树的根/目录的外部。在这里我有一个参考另一个项目。我能够在主项目NAnt脚本中编写我所有外部的构建。这些结果建立如下:

/外部对象/外部PROJECT1 /建造/ buildartifacts/{的DLL | HTML | JS}

/外部对象/外部项目2 /建造/ buildartifacts/{的DLL | HTML | JS}

这是一切都很好,但现在我很好奇,我的主要项目应该如何参考这些构建工件。例如,假设外部项目构建了一些我的代码库所依赖的DLL。我应该只是在构建工件目录中引用DLL,还是应该实现另一个将这些副本复制到/ thirdparty/libs /文件夹的NAnt任务?

这意味着,我的版本是现在依赖于建立这个外部项目(既可以是内部或第三方)的能力。检查最新的构建工件集以确保主构建不会因为依赖构建中断而中断吗?

希望这是不够清楚。只是写下来,至少为我澄清了这个问题:-)。

- 编辑 -

谢谢你们。我想我会实施“结帐修订”,但由于构建过程非常快,我不会检查任何构建人工制品。也将不得不弄清楚如何处理外部项目的依赖关系(例如:prototype,swfobject等)。

回答

1

我会说他们建立一次,检查/ public/ext/some_dependency/ref中的构建工件(显然,该文件夹的命名取决于你:-))并从那里引用它们。

我的主要理由是,你几乎不需要每次你做你的产品的构建时间来建立外部依赖。一般而言,外部依赖应该很少发生变化。此外,当您选择外部依赖性更改时,您需要严格控制,以避免在编码阶段引入不稳定性。

作为扩展到这一点,我想补充一个单独的CI的任务,只能建立外部依赖,并在一些外部条件检查它们在上述文件夹 - 在依赖源文件夹或别的东西提交。

1

我有一个建议(我认为它来自Mike Mason的语用版本控制书),以引用您的外部特定版本,以便始终获得相同版本的外部依赖关系,直到您明确选择改变它。

此时,您可能已经交互式地构建过一次以确保它可以正常工作,因此依靠它每次构建并不是真正的问题,这样可以避免在构建任务中添加一些间接方法。

如果您选择让间接,以及由于某种原因,没有建立在外部失败,这有可能会被错过作为下一个恶性任务会拿起以前的二进制文件。