构建自动化期间 TFS 中的持续集成 (CI) 出现问题？
我正在使用 TFS 2008 和 Visual Studio，我的老板指示我为 Web 项目实现开发和发布构建的构建自动化。
我是构建自动化领域的新手。
有多个开发人员使用 Visual Studio 2008 团队系统在不同的计算机上处理该项目。源已在 TFS 2008 上维护。使用的 SQL Server 是 SQL Server 2000，托管 IIS 是 Windows Server 2008 x64 上的 IIS 7.5。
我在网上搜索发现持续集成和夜间构建是两种重要的构建自动化技术。
我只是想知道与这两种方法（CI 和 Nightly Builds）相关的任何缺点。
如果有人可以指导我一个解释这两种技术的工作教程，那将会非常有帮助。
还请说明 IIS、SQL Server 和任何其他可能是实现构建自动化的先决条件的要求。
我还想知道是否还有其他技术比 CI 更好？
非常感谢回复和讨论。
谢谢
I am using TFS 2008 and Visual Studio and my boss has instructed me to implement Build Automation for Development and Release builds for a web Project.
I am a total newbie in Build Automation.
There are multiple developers working on the project on different machines using Visual Studio 2008 team System. Source is already being maintained on TFS 2008. SQL Server in Use is SQL Server 2000 and hosted IIS is IIS 7.5 on Windows Server 2008 x64.
I have searched over the net and found Continuous Integration and Nightly Builds as two important Build Automation techniques.
I was just wondering of any disadvantages associated with both the methodologies (CI and Nightly Builds).
If someone could guide me to a working tutorial that explains both techniques the it would be quite helpful.
Please also tell the requirements of IIS, SQL Server and any other that might be pre-requisite to implement build automation.
Also i would like to know whether there are other techniques that are better then CI?
Replies and discussion much appreciated.
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
没有什么真正的缺点，只是使用 CI 你的服务器会更忙。
这些构建的原因是：
注意：每天早上您都会有一个可以测试的完整构建的版本安装程序。您知道所有代码的构建，并且每天您都会有一个“准备好”的版本，如果您愿意，您可以发送出去。这比每次准备发布新版本时让程序员花一天时间逐步运行“如何构建版本”文档来创建安装程序要好得多！而且您的测试人员能够测试完整的发布包，因此您可以确信发布和安装过程的每个部分都可以正常工作，就像日常锻炼一样。
CI：这只是一个快速构建，每次有人签入时都会运行。它会告诉您是否签入了非编译代码，以便作者可以立即修复问题并最大限度地减少对其他团队的干扰成员。当 4 或 5 个程序员获得最新代码，然后发现他们在 2 小时内无法完成任何工作，直到 Fred 修复他的错误签入之前，您可能会浪费很多时间。了解断网可以让程序员避免执行 Get 操作，除非代码已被验证为有效。
要实现 NB 和 CI，您首先需要获得将在您的服务器上运行的构建。
如果您有正在运行的 TFS，那么要创建构建服务器，您只需安装开发工具（VS2008 以及构建代码所需的任何其他工具，例如第 3 方库/构建工具等）就好像它是开发人员 PC，并且可以用作构建服务器。只需右键单击“构建”文件夹并“创建新构建”，您就应该能够弄清楚其中的大部分内容。您必须给它一个名称，设置工作区映射以告诉它在哪里构建代码，并设置一个输出文件夹以将结果“放入”其中，然后您就可以开始了。
您可能需要调整项目的设置才能使其正常工作，例如开发人员不擅长在其解决方案中引用“C:\Projects...”，当项目移动到 D: 时，这些解决方案通常会中断。另外，令人烦恼的是，构建服务器会将代码构建到与您的开发 PC 不同的位置，因此您可能会发现构建过程的某些部分会中断，并且您必须重新配置诸如参考的固定位置等内容这样它们就可以在构建和开发机器上工作。
自动添加尽可能多的流程（清理、获取代码、构建它、运行单元测试、混淆二进制文件、签署二进制文件、构建安装程序、签署安装程序、复制到部署文件夹），以便 NB 可以构建< em>一切，只需按一下按钮即可获得完全可释放的产品。计算机擅长这些东西，所以不要让人类整天忙着制作安装程序，这样容易出错且成本高昂！
将 NB 设置为完全重建（默认情况下应该是这种情况），并使用触发器设置让它在每个工作日晚上（例如）凌晨 1 点运行。 NB 应该构建所有内容（良好、彻底的构建）。
复制 NB 构建设置以进行 CI 构建。在 MSBuild 项目文件中，设置以下属性：IncrementalGet=true、IncrementalBuild=true、ForceGet=false。这会将其转换为快速增量构建。在工作空间映射中，隐藏或删除尽可能多的文件夹，以最大程度地减少从源代码控制获取的代码量，以帮助保持快速。将构建设置为仅构建一个变体（例如发布），因此它将是一个快速构建。在触发器中（右键单击构建并对其进行编辑），将其设置为在签入时进行构建。
在所有开发机器上运行构建监视器。这会在您的图标托盘中放置一个图标，并在构建开始、完成和失败时向您提供可选的通知。如果您的 CI 构建失败，您将立即知道。
现在，您应该准备好每晚的构建，以便每天早上进行测试，每当有人检查任何更改时，新的增量构建就会启动，您将在几分钟内知道您是否破坏了源代码管理中的代码库。
（我们有第三个构建，它是增量测试构建。这与 CI 构建相同，但它也运行我们所有的单元测试。这是每晚执行的，开发人员可以在希望验证代码库时触发它在服务器上（我们在升级到测试分支之前使用它作为门控机制）它比 CI 测试慢很多，这就是为什么它不用于 CI 构建 - 你希望 CI 构建尽快完成。可能）
注意：为了使 CI 工作，您有时需要进行完全重建。在“队列构建”对话框中，输入以下命令行选项来强制执行此操作：
没有任何技术比 CI “更好”。除了您实施的所有其他流程之外，您还可以（并且应该）使用 CI。
There are no real disadvantages, except that with CI your server will be busier.
The reasons for these builds are:
NB: Every morning you have a fully built release installer that you can test. You know all your code builds, and every day you have a release "ready" that you could send out if you wanted to. This is much better than having a programmer spend a day running through a "how to build a release" document step by step to create an installer every time you're ready to release a new version! And your testers are able to test a complete release package, so you have confidence that every part of your release and installation process works as it's getting a daily workout.
CI: This is just a fast build that runs every time someone checks in. It tells you if you check in non-compiling code, so that the author can fix the problem immediately and minimise disruption to other team members. You can waste a lot of time when 4 or 5 programmers get the latest code and then find they can't do any work for 2 hours until Fred fixes his bad checkin. Knowing about a broken net allows your programmers to avoid doing a Get unless the code has been verified as working.
To implement NBs and CI you first need to get a build that will run on your server.
If you have a running TFS, then to create a build server you just need to install your dev tools (VS2008 and anything else needed to build the code, such as 3rd party libraries/build tools etc) as if it is a developer PC, and it's ready to use as a build server. Just right click on the Builds folder and "Create new build" and you should be able to figure out most of it as you go. You have to give it a name, set up the workspace mappings to tell it where to build the code, and set up an output folder for the results to be "dropped" into, and you'll be good to go.
You may need to tweak the setup of your projects to make this work well e.g. developers are terrible at putting references to "C:\Projects..." in their solutions, which often break when the project moves onto the D: drive of a buid server, etc. Also, rather annoyingly the build server will build code into different locations than your dev PCs, so you may find parts of the build process will break and you will have to reconfigure things like fixed locations for references etc so that they work on both Build and Dev machines.
Add as much of the process as you can (clean, get code, build it, run unit tests, obfuscate binaries, sign binaries, build installers, sign installers, copy to deployment folder) automated so that the NB can build everything and you get a fully releasable product at the press of a single button. Computers are good at this stuff, so don't leave an error-prone and expensive to run human slaving away all day to make an installer!
Set the NB up to do a full rebuild (this should be the case by default) and use the Triggers settings to have it run every weeknight at (e.g.) 1am. The NB should build everything (a good, thorough build).
Copy the NB build settings to make a CI build. In the MSBuild project file, set these properties: IncrementalGet=true, IncrementalBuild=true, ForceGet=false. This will convert it to a fast incremental build. In the Workspace Mapping, Cloak or remove as many folders as possible to minimise the amount of code it Gets from source control, to help keep it fast. Set the build to only build one variant (e.g. Release) so it'll be a quick build. In the Triggers (right click on the build and edit it), set it to build whenever there is a checkin.
Run the build monitor on all dev machines. This places an icon in your icon tray and give you optional notifications whenever builds start, complete, and fail. If your CI build fails you will then know about it immediately.
Now, you should have a nightly build ready for testing every morning, and whenever anyone checks in any changes, a new incremental build will kick off, and you'll know within a few minutes if you have broken the codebase in source control.
(We have a third build, which is an incremental Test build. This is the same as the CI build, but it runs all our unit tests as well. This is executed nightly, and developers can trigger it whenever they wish to verify the codebase on the server (we use this as a gating mechanism before promoting to a the test branch). It's a lot slower than the CI test, which is why it's not used for the CI build - you want the CI build to finish as fast as possible)
Note: To make the CI work, you will sometimes need to do a full rebuild. In the "Queue Build" dialog, enter these command line options to force this:
There aren't any techniques that are "better" than CI. You can (and should) use CI in addition to all other processes you implement.