如何使用所有依赖于单个类库的多个产品设置源代码控制

发布于 2024-08-04 20:32:35 字数 934 浏览 7 评论 0原文

我是我公司的首席技术官和唯一的开发人员。我正准备雇用我们的第一位开发人员,并可能在未来 6-12 个月内雇用第二位开发人员。我很尴尬地说,我从未将源代码控制用作我的工作流程的一部分。我想作为一个只有 1 名成员的开发团队让我变得有点懒惰。不是我不想,只是我对如何开始有一点心理障碍。

我构建和维护了 5 个 Web 应用程序。我们使用 ASP.NET,每个 Web 应用程序都引用一个 .NET 类库 (DLL),该类库已复制到每个应用程序的“bin”文件夹中。我一直在使用单个 Visual Studio“解决方案”进行开发,其中包括类库和所有 Web 应用程序。我确信有点臃肿,但这种方法使我能够同时对所有应用程序(和类库)进行全局查找和替换操作,从而轻松地减少错误。

我意识到实施源代码控制本身对我的工作流程来说就是一个巨大的改变,但在我的流程中引入另一个开发人员让我有点不知所措。我正在寻求一些有关如何开发工作流程的帮助,使我的小团队能够快速行动,而无需繁琐的流程。我想避免讨论选择哪个 SCC 系统(我们将使用 Mercurial)。我更感兴趣的是讨论其结构和工作流程方面。

以下是我需要帮助解决的问题:

  1. 我应该将每个应用程序拆分为一个单独的“项目”还是将它们全部放在一起,以便我们可以在必要时继续从全局查找和替换操作中受益。由于类库的情况,我担心将它们分开(参见#2)。

  2. 如果将应用程序拆分为单独的项目,我不确定如何继续处理每个项目都需要副本的类库。例如,假设对其中一个应用程序(称为“项目 1”)的更改需要对类库进行更改...如果类库位于单独的项目(称为“项目 2”)中,则它对我来说,项目 1 需要依赖项目 2 的最新更改才能正常工作,这似乎“混乱”。或者,您是否只是对项目 2(类库)进行更改,签入它们,然后将新编译的 dll 复制到项目 1 中(但复制到项目 1 中的 dll 的新副本不应该记录在SCC 以某种方式)。即使在我写这篇文章时我也感到困惑...

提前感谢您的帮助。

I am the CTO and sole developer for my company. I'm getting ready to hire our first developer and possibly a second within the next 6-12 months. I'm embarrassed to say that I've never used source code control as part of my workflow. I guess being a 1-member development team has allowed me to be a bit lazy. It's not that I haven't wanted to, I just have a bit of a mental block about how to get started with it.

We have 5 web applications that I build and maintain. We use ASP.NET, and each web app references a single .NET Class Library (DLL) that has been copied into the "bin" folder for each app. I've been developing with a single Visual Studio "solution" that includes the class library and all of the web apps. A bit bloated, I'm sure, but this method has made it easy for me to minimize mistakes by enabling me to do global find and replace operations on all of my apps (and the class library) at the same time.

I realize that implementing source code control is a big change to my workflow by itself, but also introducing another developer into my process has me a bit overwhelmed. I'm looking for some assistance on how to develop a workflow that will enable my small team to move quickly without cumbersome processes. I'd like to avoid discussions about which SCC system to choose (we're going to use Mercurial). I'm more interested in discussing the structure and workflow aspects of this.

Here are the questions I need help with:

  1. Should I split up each app into a separate "project" or keep them all together so we can continue to benefit from global find-and-replace operations when necessary. I'm worried about splitting them up because of the class library situation (see #2).

  2. If splitting up the apps into separate projects, I'm not sure how to proceed with the class library that each project needs a copy of. For example, let's say that the changes to one of the apps (call it "project 1") requires a change to the class library... if the class library is in a separate project (call it "project 2"), it seems "messy" to me that project 1 would be dependent on the latest changes in project 2 in order to work properly. Or, do you simply make your changes to project 2 (the class library), check them in, and then copy the newly compiled dll into project 1 (but shouldn't the new copy of the dll being copied into project 1 be recorded in the SCC somehow). I'm getting confused even as I write this...

Thanks in advance for your help.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

木落 2024-08-11 20:32:36

首先,祝贺您决定最终使用源代码控制。我知道改变你的习惯可能会令人沮丧,但从长远来看,我相信你会看到好处。

  1. 包含多个项目的解决方案没有任何问题。我通常将数量保持在 10 左右,但这只是为了缩短加载时间。如果将它们放在一起对您来说效果更好,就这样吧。使用源代码控制不会对此产生任何影响。
  2. 就类库而言,我认为您需要做的是改变对库项目进行更改的方式,而不是如何使用引用它的项目。对库项目实施单元测试以强制向后兼容性,这样您就知道删除最新版本的库不会破坏您的应用程序。您可能会发现这种情况有几次并不成立,但随着您开发更多的单元测试来处理边缘情况,这种情况会越来越少。

First, congratulations on deciding to finally use source control. I know changing your habits can be frustrating but in the long run I'm sure you'll see the benefits.

  1. There's nothing wrong with a solution that has multiple projects in it. I generally keep mine to about 10 but that's simply to improve load times. If keeping them together works better for you, leave it that way. Usage of source control won't have any affect on this.
  2. As far as the class library, I think what you need to do is change the way you go about making changes to the library project rather than how you use the projects that reference it. Implement unit testing on the library project to enforce backward compatibility so you know that dropping the latest version of the library won't break your app. You'll likely find this won't be true a few times but as you develop more unit tests to handle edge cases this will happen less and less.
爱格式化 2024-08-11 20:32:36

您可以在单个 Visual Studio 解决方案中拥有多个项目。我过去所做的是将 ASP.NET 项目和类库项目放在同一个解决方案中。您可以让 ASP.NET 项目引用类库项目(添加引用,然后转到“项目”选项卡以显示同一解决方案中的其他项目)。这样,每当您更改类库时,ASP.NET 应用程序都将使用最新版本的类库构建。您可以设置多个解决方案 - 每个 ASP.NET 应用程序一个,每个解决方案包括类库项目。

您还可以使用所有 ASP.NET 项目以及类库设置一个大型解决方案,但这可能会有点难以使用,特别是当多个开发人员在不同的 ASP.NET 页面上工作时。

You can have multiple projects in a single Visual Studio solution. What I've done in the past is to have both the ASP.NET project and the class library project in the same solution. You can have your ASP.NET project reference the class library project (Add Reference and then go to the Projects tab to show other projects in the same solution). That way, whenever you change the class library, the ASP.NET application will be build using the latest version of the class library. You can setup multiple solutions - one for each ASP.NET application with each solution including the class libary project.

You could also setup one large solution with all of your ASP.NET projects as well as your class library but that may get a bit hard to work with, especially with multiple developers working on the different ASP.NET pages.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文