Kra*_*zek 6 .net continuous-integration nuget
在我的日常工作解决方案中,我们有大约80个项目.此解决方案包含4个不同的Web站点,业务逻辑和基础架构程序集(如扩展方法,各种实用程序,存储库基类等).
该解决方案非常有效,但如果我们将测试项目添加到解决方案中,我们可以轻松地通过100个项目,这使得使用此解决方案非常繁琐.
在我寻找解决方案时,我对Nuget非常感兴趣,我开始怀疑它是否可以帮助我们.
我们的想法是将巨大的解决方案分成更小的原子片,其输出将是一个Nuget包,可以上传到私有Nuget存储库.
Web站点将引用除绑定到该特定Web站点的类库之外的包.
从CI的角度来看:
每个包解决方案应该是原子的.
产品解决方案(比如网站)应该在以下情况下构建:
有什么建议吗?或者可能是实现这个巨大解决方案分裂的更好方法?
使用包管理(在Windows上:NuGet)肯定是一种可靠的方法.您可以"免费"获得依赖性解析,并且可以利用语义版本控制来仅通过包版本号将有意义的信息传递给包装消费者.
但是,NuGet实际上是一些更基本模式的具体实现:
从您的问题来看,听起来您正在构建超出必要的代码,并且您的代码模块化程度低于可能的代码.使用NuGet来模块化您的代码将有助于实现这三种模式(当然是1和2 - 您需要采取额外的步骤3).
应用这些模式也有助于@Fede(对于谁 - 使用C和C++代码 - NuGet不适用).通常,通过使您的软件更加模块化(但避免构建整体的,无所不知的"框架",通常称为*.Library.dll或*.Common.dll等),您将获得更好的构建体系结构.
最终,每个"块"代码(Visual Studio术语中的项目或解决方案)应该是单个开发人员可理解的; 如果它太笨重或太复杂,就把它拆开.项目,解决方案,.cs文件等都是人类的抽象,而不是机器,因此它们之间的大小和关系应该反映我们的人类能力和理解的需要.考虑到这一点太多将导致需要更改多个包以完成单个功能:在这种情况下,按定义分离是粒度的,您需要再次将一些代码重新组合在一起.
(披露:我是Windows软件包管理的合着者 - PackageManagementBook.com)
您可能可以将每个单独的网站移至不同的解决方案。如果您使用版本控制工具,这可能是一个合乎逻辑的步骤,因为每个单独的项目都将单独进行版本控制,这意味着开发人员不必立即与所有项目同步。此外,各个网站应该相互独立,因此这不应该是一个麻烦的举动。
您是否有与特定“业务项目”不紧密相关的通用或通用代码?该代码可以移动到另一个解决方案,例如公司框架或类似的东西。然后,每个业务项目都将使用该框架的发布版本,仅在符合业务逻辑的情况下以及如何进行升级。例如,如果网站 A 当前的发布计划很紧,那么引入包含重大更改的框架版本可能不是一个好主意。但是,如果网站 B 处于非关键阶段,您可能希望在框架中包含新功能,并在有一点空闲时间时处理重大更改。
我不知道 NuGet 是否可以满足您的要求,但Atlassian提供了一些工具(即 FishEye、Crucible 和 Bamboo)可以帮助您以有组织的方式实现类似的目标。注意:我不隶属于 Atlassian。
| 归档时间: |
|
| 查看次数: |
1632 次 |
| 最近记录: |