我目前正在开展一个连续几年的项目。开发团队很小（少于5个程序员），源代码控制几乎不存在，部署过程就是基于手动将文件从一个服务器移动到另一个服务器。该项目采用经典的ASP，因此构建不是问题，因为部署和测试只是将文件放到需要的位置，并将浏览器指向正确的位置。目前，所有开发都在网络驱动器上完成，网络驱动器也是测试服务器。测试服务器仅在本地网络内部可用（可通过vpn访问），并且在浏览器中的地址“site.test”上可用（需要编辑所有客户端上的hosts文件，但是我们这么少的人根本没有被证明有任何问题。所有开发都在visual studio中完成。每当文件发生变化时，更改文件的开发人员都需要将他更改的文件写入word文档，并在变更内容和原因中包含一个小描述。然后，只要有一个版本碰撞（部署），我们的首席开发人员就会通过word-document进行复制，并将已经更改的每个文件（逐个文件）复制到生产服务器。现在，我认为我不需要告诉你这个方法非常容易出错（开发人员可能会忘记添加他改变了一些依赖关系，这可能会在部署时引起问题），并且涉及到很多工作部署。
这是主要问题。首席开发人员要求我花一些时间，看看我是否能够提出一个简单的解决方案，可以简化和自动化“版本控制”和部署。现在，重要的是它为开发人员使用和posible 一样简单。两个现有的开发人员已经使用计算机很长时间了，而且他们的日常工作非常困难，所以例如将它改成像git bash这样的东西根本不起作用。不要误会我的意思，我喜欢git，但是当他们中的第一次发生合并冲突时，他们根本不会知道该怎么做。此外，理想的情况是更改为更加分散的开发流程，开发人员无需登录到vpn（或根本不需要互联网）进行开发，并且他们离线时所做的更改可以同步进行。完成他们。现在，我看了微软的Teem Development Server，因为它与Visual Studio的强大集成。据我测试过，如果用户想要在用户关闭Visual Studio时签入更改，Visual Studio就可以提示用户。现在，使用TFS进行源代码控制可能会消除开发中的大多数问题，但是如何部署呢？版本控制更不用了？据我所知（我只是简要介绍了TFS），TFS每次办理登机手续都有一个运行编号，但有可能告诉TFS这个办理登机手续应该是系统版本2.0.1 （例如），然后将它部署到Web服务器？另一个问题是，整个解决方案由大约10个目录和数百个文件组成，虽然系统本身（没有图像等）只有5个目录，只有这5个应该部署到服务器，这是否可以实现自动化？
我知道这里有很多问题，但最重要的是我想要自动化开发过程（不是编码，而是代码的管理）和部署过程，我想要实现它尽可能简单使用。我不关心设置是否有点工作，因为我有足够的时间来设置适合我们需求的任何系统，但其他开发人员不应该做很多设置 。如果所有应该使用该系统的机器都需要设置一次，那就没问题了，因为我可以做到这一点，但是我们不需要做任何配置和设置。
现在，您是否有任何建议要使用哪些系统/如何使用它们，以简化上述过程？我曾经使用过几种类型的scm系统（GIT，HG和SubVersion），但我根本没有构建系统的经验（如果需要的话）。关于如何有效地设置这样的系统的文章和讨论将不胜感激。提前谢谢。
答案 0 :(得分：1)
这是相当主观的领域，但我认为你需要先获得一些轻松的胜利。 “陷入困境”的开发商是这里的主要障碍。他们将变革视为破坏性而不值得。你需要慢慢地，小心翼翼地去轻松获胜。
首先，TFS可能不是一个好的选择。它很昂贵，很重，TFS中的源代码控制非常糟糕。转向Subversion：它易于设置且易于使用，而且是免费的。先把它放到位，然后让开发者使用它。说起来容易做起来容易。
稍后（可能更晚），一旦开发者使用它并且无法想象没有VCS的生活，那么如果你需要一流的分支和所有其他不错的功能，你可以切换到Hg或Git。
一旦你有Subversion，你就可以使用像JetBrains TeamCity或Jenkins这样的东西，它们都是免费且易于使用的。但是，我只是假设你没有很多测试和构建CI服务器真正运行的脚本，所以你首先得到VCS更重要。在所有方面：尽可能简单。宝贝的步骤。获得一些胜利，建立信任，重复。
答案 1 :(得分：0)
我甚至无法开始思考从哪里开始！除了提到git和HG之外，没有任何针对你的冒犯，这篇文章可能是10年前写的。
1）源代码控制 - 如果没有某些形式的源代码控制，开发人员团队如何才能有效地工作？地狱，即使它的视觉源安全（*颤抖*）至少它会是什么。你必须坚持要求团队实施源代码控制。你知道什么是可用的，所以我不会谈论这个。 （但是，使用TortoiseSVN的Subversion对我来说效果很好。）
2）
“将他改变的文件写入 word-document包括一个小文件 关于改变的描述和 为什么“
你一定是在开玩笑......如果两个开发者改变同一个文件怎么办？然后，线索是否必须手动合并他/她从单词doc中提取的两个更改？请参阅＃1并向他们解释提交评论的工作原理。
由于您不需要“构建”（即编译等）任何东西，您应该能够使用一些简单的工具解决大部分问题。首先，您需要使用源控制解决方案。是的，开发人员必须学习如何使用其他工具（EEEK！）。您可以完成将代码放入存储库的初始工作。如果你有其他开发者机器的文件访问权限，你甚至可以将签出的工作副本复制到他们的机器上，这样他们就不必自己进行结账（实际上并不那么难）。然后，您可以在需要完成每个部署时使用版本控制的所有奶油优点来创建版本分支。您可以使用命令行SVN工具编写简单脚本来检出所述分支并自动将文件复制到目标服务器。使用像BeyondCompare这样的工具，复制过程可以仅限于不同的文件（如果这是一个问题，加上BC可以处理FTP目标）。通过在SVN repo上强制执行提交注释，您可以保证开发人员提供注释，对于版本之间的每组更改，您可以使用CSM日志检索功能轻松生成所有这些注释的列表。