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