使用 Visual Studio 自动化构建和开发模式

Question

我目前正在从事一个已经连续进行了几年的项目。开发团队很小（少于 5 名程序员），几乎不存在源代码控制，部署过程只是基于手动将文件从一台服务器移动到另一台服务器。该项目采用经典的 ASP，因此构建不是问题，因为部署和测试只是将文件放到需要的位置并将浏览器定向到正确的位置。目前所有的开发都是在一个网络驱动器上完成的，它也是测试服务器。测试服务器仅在本地网络内可用（可以通过 vpn 访问），并且在浏览器中的地址“site.test”上可用（需要在所有客户端上编辑主机文件，但由于我们当中很少有人证明没有任何问题）。所有的开发都是在visual studio中完成的。每当更改文件时，更改文件的开发人员都需要将他更改的文件写入 word 文档，并包含关于更改内容和原因的简短描述。然后，只要有版本更新（部署），我们的首席开发人员就会通过 word-document 并复制每个已转换到生产服务器的文件（逐个文件）。现在，我认为我不需要告诉您此方法非常容易出错（例如，开发人员可能忘记添加他更改了一些依赖项，这可能会在部署时导致问题），并且涉及很多工作与部署。

主要问题来了。首席开发人员要求我花​​一些时间，看看我是否能想出一个简单的解决方案来简化和自动化“版本控制”和部署。现在，重要的是它尽可能简单供开发人员使用。现有的两个开发人员已经使用计算机很长时间了，并且非常坚持他们的例程，因此例如将其更改为 git bash 之类的东西根本行不通。不要误会我的意思，我喜欢 git，但是当他们第一次遇到合并冲突时，他们根本不知道该怎么做。此外，更改为更分布式的开发流程是理想的，开发人员不需要登录到 vpn（或根本不需要互联网）来开发，并且他们离线所做的更改可以在他们被同步时同步。和他们一起完成。现在，我查看了 Microsoft 的 Teem Development Server，因为它与 Visual Studio 紧密集成。据我测试，如果用户想要在用户关闭 Visual Studio 时签入更改，似乎可以让 Visual Studio 提示用户。现在，使用 TFS 进行源代码控制可能会消除开发中的大部分问题，但是部署呢？更不用说版本控制了？据我了解（我只是简单地看了一下 TFS），TFS 每次签到都有一个运行号，但是有没有可能告诉 TFS 这个签到应该是系统的 2.0.1 版本（例如），然后让它部署到网络服务器？还有一个问题，整个解决方案由大约 10 个目录组成，其中包含数百个文件，虽然系统本身（没有图像等）只有 5 个目录，并且只有这 5 个应该部署到服务器，这可以自动化吗？

我知道这里有很多问题，但最重要的是我想自动化开发过程（不是编码，而是代码的管理）和部署过程，我想做尽可能简单易用。我不在乎设置是否有点工作，因为我手头有足够的时间来设置任何适合我们需要的系统，但是其他开发人员不应该做很多设置 .如果应该使用系统的所有机器都需要设置一次，那完全没有问题，因为我可以这样做，但是我们应该不需要做任何配置和设置。

现在，你们中的任何人对使用哪些系统/如何使用它们有什么建议吗，以简化上述过程？我之前使用过几种类型的 scm 系统（GIT、HG 和 SubVersion），但我根本没有任何构建系统的经验（如果需要的话）。关于如何有效地设置这样的系统的文章和讨论将不胜感激。提前，谢谢。

Answer 1

我什至想不出从哪里开始！无意冒犯你，除了提到 git 和 HG，这篇文章可能是 10 年前写的。

1) 源代码控制 - 如果没有某种 形式的源代码控制，开发团队如何可能有效地工作？见鬼，即使它是 Visual Source Safe (* shudder *)，至少它会是一些东西。你必须坚持让团队实施源代码控制。你知道什么是可用的，所以我不会对此进行宣讲。 （但是，使用 TortoiseSVN 的 Subversion 对我来说效果很好。）

2)

"把他改成的文件写成 word-document 并包含一个小的 对更改内容的描述和 为什么”

你一定是在开玩笑......如果两个开发人员更改同一个文件会发生什么？那么领导是否必须手动合并他/她从单词 doc 中提取的两个更改？请参阅 #1 并向他们解释提交 cmets 的工作原理。

---

由于您实际上并不需要“构建”（即编译等）任何东西，因此您应该能够使用一些简单的工具来解决大部分问题。首先，您需要使用源代码控制解决方案。是的，开发人员必须学习如何使用另一种工具（EEEK！）。您可以完成将代码放入存储库的初步工作。如果您对其他开发人员机器具有文件访问权限，您甚至可以将签出的工作副本复制到他们的机器上，这样他们就不必自己进行签出（不是那么难）。然后，当需要完成每个部署时，您可以使用版本控制的所有优点来创建版本分支。您可以使用命令行 SVN 工具编写简单的脚本来检查所述分支并自动将文件复制到目标服务器。使用 BeyondCompare 之类的工具，复制过程可以仅限于不同的文件（如果有问题，BC 可以处理 FTP 目标）。通过在 SVN 存储库上强制执行提交 cmets，您将保证开发人员提供 cmets，并且对于版本之间的每组更改，您可以使用 CSM 日志检索功能非常轻松地生成所有这些 cmets 的列表。

Answer 2

这是一个相当主观的领域，但我认为你需要先获得一些轻松的胜利。 “陷入困境”的开发人员是这里的主要障碍。他们会认为变革具有破坏性，不值得。您需要缓慢而谨慎地争取轻松获胜。

首先，TFS 可能不是一个好的选择。它既昂贵又沉重，而且 TFS 中的源代码控制非常糟糕。选择 Subversion：它易于设置且易于使用，而且是免费的。首先将其落实到位，然后让开发人员使用它。说起来容易做起来难。

稍后（可能更晚），一旦开发人员使用它并且无法想象没有 VCS 的生活，那么如果您需要一流的分支和所有其他不错的功能，您可以切换到 Hg 或 Git。

安装好 Subversion 后，您可以使用 JetBrains TeamCity 或 Jenkins 之类的工具，它们都是免费且易于使用的。但是，我只是假设您没有太多测试和构建 CI 服务器真正要运行的脚本，因此首先获得 VCS 更为重要。在所有方面：尽可能简单。婴儿步。取得一些胜利，建立信任，重复。