构建管理/持续集成最佳实践 [英] Build management/ Continuous Integration best practices

问题描述

您的团队如何处理构建？

我们使用Cruise Control，但（由于缺乏知识）我们面临一些问题 - SVN中的代码冻结 - 构建管理

具体来说，在不断检查代码时如何使特定版本可用？

How does your team handle Builds?
We use Cruise Control, but (due to lack of knowledge) we are facing some problems - Code freeze in SVN - Build management
Specifically, how do you make available a particular release when code is constantly being checked in?

通常，您能否讨论一下您在发布管理中使用的最佳实践？

Generally, can you discuss what best practices you use in release management?

推荐答案

<我非常惊讶这不是重复，但我找不到另一个。

I'm positively astonished that this isn't a duplicate, but I can't find another one.

好的，这是交易。它们是两个独立但相关的问题。

Okay, here's the deal. They are two separate, but related questions.

对于构建管理，关键点在于您应该拥有一个自动，可重复的构建，从头开始重建整个软件集合，并一直到您的可交付配置。换句话说，你应该每次都有效地建立一个候选版本。许多项目并没有真正做到这一点，但我已经看到它燃烧了人们（阅读被它烧掉了）太多次了。

For build management, the essential point is that you should have an automatic, repeatable build that rebuilds the entire collection of software from scratch, and goes all the way to your deliverable configuration. in other words, you should build effectively a release candidate every time. Many projects don't really do this, but I've seen it burn people (read "been burned by it") too many times.

持续集成说这个每当代码发生重大变化事件（如签入）时，应尽可能重复构建过程。我已经完成了几个项目，每晚都会变成一个构建版本，因为代码足够大，需要几个小时才能构建，但理想的是设置构建过程以便有一些自动机制 - 就像一个蚂蚁脚本或生成文件---只重建受更改影响的文件。

Continuous integration says that this build process should be repeated every time there is a significant change event to the code (like a check in) if at all possible. I've done several projects in which this turned into a build every night because the code was large enough that it took several hours to build, but the ideal is to set up your build process so that some automatic mechanism --- like an ant script or make file --- only rebuilds the pieces affected by a change.

您可以通过某种方式处理提供特定版本的问题，同时保留所有版本的确切配置每个构建的受影响的工件，因此您可以将可重复的构建过程应用于您具有的确切配置。 （这就是为什么它被称为配置管理。）通常的版本控制工具，如git或subversion，提供了识别和命名配置的方法，以便可以恢复它们;例如，在svn中，您可以为特定构建构建标记。您只需要保留一些元数据，以便了解您使用的配置。

You handle the issue of providing a specific release by in some fashion preserving the exact configuration of all affected artifacts for each build, so you can apply your repeatable build process to the exact configuration you had. (That's why it's called "configuration management.") The usual version control tools, like git or subversion, provide ways to identify and name configurations so they can be recovered; in svn, for example, you might construct a tag for a particular build. You simply need to keep a little bit of metadata around so you know which configuration you used.

您可能需要阅读其中一本实用版本控制书籍，以及当然，关于马丁福勒网站的CI和巡航控制的内容是必不可少的。

You might want to read one of the "Pragmatic Version Control" books, and of course the stuff on CI and Cruise Control on Martin Fowler's site is essential.

这篇关于构建管理/持续集成最佳实践的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！