项目文件夹结构建议 [英] Projects folder structure recommendation

问题描述

我已经准备好实施源代码控制系统（Subversion），但是我在如何构造文件夹方面面临一些疑问。

I'm getting ready to implement a source control system (subversion) but I'm facing some doubts on how to structure my folders.

我使用Delphi进行我所有的开发工作，都可以在IDE中编译项目。

I use Delphi for all my development and compile the projects from within the IDE.

我当前的项目文件夹结构如下：

My current projects folder structure is as follows:

-E:\Work\1. Shared
--Forms (shared forms across all projects)
--Units (shared units/classes across all projects including 3rd party like JCL)

-E:\Work\2. Company Name
--Admin (stuff related with admin work like a license keys generator, Windows CGI to handle order processing automatically, all developed in Delphi)
--Projects
----ProjectA
-----5.x (version 5.x)
------BIN (where all the binaries for this project go)
------Build Manager (where the FinalBuilder project lives)
-------Install (NSIS file that create the setup.exe)
-------Protection (Project files to protect the compiled exe)
-------Update (inf files related with the auto-update)
------Docs (where the readme.txt, license.txt and history.txt that are included in the setup file are)
-------Defects (docs for any testing done by me or others)
-------HTMLHelp (html help for the project)
------R&D (where screenshots, design ideas and other R&D stuff goes to)
------Releases (when building a release with FinalBuilder the setup file created by nsis is placed here)
------Resources (Images and other resources used by this project)
------Source (if a sub-project exists it will compile to BIN since they are all related)
-------SubprojectA
-------SubprojectB
-------SubprojectC
--Sites
--- companywebsite.com (the only one at the moment but if we decide to have individual web sites for products they would all be placed on the Sites folder)

符号-表示目录。

有人想评论当前结构或有任何建议要改进吗？

Anyone cares to comment about the current structure or has any suggestions to improve it?

谢谢！

推荐答案

这些年来，我们已经完成了数百个项目的设置，并且专门从事软件配置管理和发布工程，我建议您首先关注如何实现

Having setup literally hundreds of projects over the years, and having specialized in software configuration management and release engineering, I would recommend that you first focus on how you want to build/release your project(s).

如果仅使用IDE来构建（编译和打包）您的项目，那么您最好遵循该IDE的典型约定以及任何最佳实践。

If you only use an IDE to build (compile and package) your project(s), then you might as well just follow the conventions typical for that IDE, plus any "best practices" you may find.

但是，我强烈建议您不要仅使用IDE进行构建，甚至完全不使用。而是使用许多可用的出色开源工具中的一个或多个来创建自动化的构建/发布脚本。由于您似乎以Windows为目标，所以我建议先看一下Ant，Ivy和适当的xUnit（用于Java的jUnit，用于.NET的nUnit等）进行测试。

However, I would strongly recommend that you do not build only with an IDE, or even at all. Instead, create an automated build/release script using one or more of the many wonderful open-source tools available. Since you appear to be targeting Windows, I recommend starting with a look at Ant, Ivy, and the appropriate xUnit (jUnit for Java, nUnit for .NET, etc.) for testing.

从这条道路上开始，您会发现许多有关项目结构，设计构建脚本，测试等方面的建议。与其立即为您提供详细的建议，不如让您不知所措，我只是将您的建议留给您-您会很容易在这里找到您问题的答案，以及发现更多值得研究的问题。

Once you start down that path, you will find lots of advice regarding project structure, designing your build scripts, testing, etc. Rather than overwhelm you with detailed advice now, I will simply leave you with that suggestion--you will readily find answers to your question there, as well as find a whole lot more questions worth investigating.

享受！

基于注释，似乎需要一些细节。

Based on comments, it seems that some detail is needed.

我要提出的一个特别建议是将代码库分为多个单独的子项目，每个子项目都产生一个单项交付。主应用程序（.EXE）应该是一个，任何支持的二进制文件都将是单独的项目，安装程序将是一个单独的项目，等等。

A particular recommendation that I would make is that you separate your codebase into individual subprojects that each produce a single deliverable. The main application (.EXE) should be one, any supporting binaries would each be separate projects, the installer would be a separate project, etc.

每个项目都产生一个主要可交付成果：.EXE，.DLL，.HLP等。该可交付成果被发布到单个共享的本地输出目录中。

Each project produces a single primary deliverable: an .EXE, a .DLL, a .HLP, etc. That deliverable is "published" to a single, shared, local, output directory.

制作子项目是同级项目的目录树（没有深度或层次结构，因为它无济于事），并且不允许项目互相进入对方的子树-每个项目应完全独立，并且仅依赖于主要项目其他子项目，在共享输出目录中引用。

Make a directory tree where the subprojects are peers (no depth or hierarchy, because it does not help), and do NOT let projects "reach" into each other's subtree--each project should be completely independent, with dependencies ONLY on the primary deliverables of the other subprojects, referenced in the shared output directory.

不要创建相互调用的构建脚本层次结构，我这样做了，发现它不会增加价值，但是确实成倍增加了维护工作量。相反，制作一个连续的集成脚本来调用您的独立构建脚本，但是首先将其干净签出到临时目录中。

Do NOT create a hierarchy of build scripts that invoke each other, I did and found that it does not add value but does exponentially increase the maintenance effort. Instead, make a continuous integration script that invokes your stand-alone build script, but first does a clean checkout into a temporary directory.

请勿将任何可交付结果或依赖项提交到源代码控制-不是您的构建输出，也不是您使用的库等。对与Maven类似的二进制存储库使用Ivy，该二进制存储库与源代码管理分开部署，并发布自己的可交付成果以供组织内部共享。

Do NOT commit any deliverables or dependencies into source control--not your build output, not the libraries that you use, etc. Use Ivy against a Maven-like binary repository that you deploy separate from source control, and publish your own deliverables to it for sharing within your organization.

哦，不要使用Maven，它太复杂了，混淆了构建过程，因此定制成本不高。

Oh, and don't use Maven--it is too complicated, obfuscates the build process, and therefore is not cost-effective to customize.

我正在根据目标平台转向SCons，BuildBot，Ant，Ivy，nAnt等。

I am moving towards SCons, BuildBot, Ant, Ivy, nAnt, etc. based on my target platform.

我一直在撰写一个

编辑：请参阅我对您如何您组织版本控制存储库吗？

这篇关于项目文件夹结构建议的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！