为一个小型团队使用SVN进行每日构建

Question

我有一个关于最佳做法的一般性问题。我有一个小团队在一个中等规模的软件项目上工作，这涉及到集成来自不同环境的代码，等等。这个项目是一个独立的桌面软件。

基于从类似的项目中吸取的经验教训，我正在尝试实现一些更好的软件工程实践。

我想从自动化的日常构建开始。我们使用SVN进行源代码管理，所有开发人员都在主干中工作，包括我。我的问题很简单：

我们在哪里做每日的建设？我是否应该在本地机器上创建另一个文件夹，即“每日构建”文件夹？我应该设置一个虚拟机吗？我应该吸收它并在我的开发文件夹中这样做吗？

我很好地理解了修订控制范例。我主要是在寻找人们如何在实践中实现它。

Answer 1

即使对于小型项目/团队来说，构建机器也是可行的。

1. 随便找一台备用机器.一个旧的开发箱)。
2. 在上面安装一些持续的集成软件，如詹金斯或teamcity。
3. 完成

我已经有一段时间没有安装或维护一台构建机器了，但除非从一年或两年前开始变得更糟，否则您可以在每次签入上进行连续的构建，并在一小时内将其转储到网络共享设置中，使用这些产品中的任何一个。

Answer 2

假设您的应用程序可以从命令行构建，给出一个干净的签出和预先安装的前提条件，那么您可以机械地做一些简单的事情，比如cron作业或预定的任务。但是您真正想要的是一个连续集成服务器。

这些服务器处理几件事：

• 他们可以很容易地通过提供日程安排来安排“每天午夜去建造这个”或者“每当有人入住时就去构建这个”。
• 他们通过提供反馈机制来扩展基本的构建--比如在Bob破坏构建时给整个团队发电子邮件。
• 随着时间的推移，他们可以提供关于构建性能和成功的长期报告。
• 可以在适当的情况下提供自动打包和发布应用程序的管道。

或者，它们实际上是现代开发和部署过程的大脑。

在这个领域有两个很好的开始-- Jenkins，它是免费和开放源代码的，TeamCity是免费的，但不是开源的。这两种方法都能让你找到你需要去的地方，选择哪一种确实是一个战术上的决定，它取决于你在构建什么东西，以及你在配置这个东西时需要付出多少努力--而不是说，如果你曾经站起来配置了一个web应用程序，那么任何一个产品的基本设置都是可怕的。它们在解剖学上是相似的，因此这个答案的其余部分将适用于两者。

这些产品都有一个中央服务器，这是您与之交互的内容，以及构建代理或构建发生的工作人员的概念。这似乎有点奇怪，直到您意识到您可能正在构建一个跨平台的产品，需要一个本机windows、osx和linux构建。

就安装位置而言，这确实是一个战术上的决定--它们都是非常灵活的java产品，几乎可以在任何情况下运行。这可以归结为硬件/软件/许可和安全的可维护性--有些人真的想把所有东西都保存在局域网上。至于构建代理，这也是一个战术上的决定。代理没有理由不能在与您的CI服务器相同的框上，但是如果需要的话，您肯定可以将它放到不同的位置。在同一个LAN上使用它会有帮助，除非您想要做一些网络配置，因为它们确实需要通信，这通常需要一些防火墙穿孔。

我可能不会把这个安装在一台有人正在积极使用的机器上，以防止有人关闭机器。或者冲洗机器并破坏你的CI过程。但是机械地说，旧的桌面就行了--我们刚刚退休了一个2005年的惠普桌面，它是我们每一个经常构建的QA站点的主要构建服务器。它的主要问题是，我们只能把2gb的RAM放在盒子里，这样我们就不能在ram中缓存很多东西，而且它会跳出到一个由运行在预期寿命之外的最低厂商制作的缓慢磁盘上。

获得詹金斯或TeamCity，安装在一个备用的桌面上，征服世界。