Usually the way I do it is my nightly builds get promoted to Release builds. You usually don't want to create a separate release build. Most QA teams should test nightly builds (hopefully they aren't testing from your CI builds). Once they have deemed it good enough for release, you promote it to release status. You determine what that means. Move it to another location, rename it, tag it, label it, burn it, etc.
You don't want to have QA testing a nightly, then when they deem it good, build another one, that you say is the same. You never know, they can be different. An OS patch may have been applied to your build machine, a third party tool may have been updated, etc. You don't want to make your QA teams work twice to test the "same exact build". It might be from the same source, but there is no guarantee it is the same exact build.
第二个周期将是一个较慢的周期，仅拾取 CI 系统所做的构建。它不使用源代码作为输入，而是使用发布版本。这些可以根据您的需要（每个生成的构建）进行选择，或者在准备进行另一个周期时选择最新的可用的。这个较长的周期将包括将构建部署到测试服务器上，运行自动化功能测试以及执行其他“太慢”、“还不快”的操作或其他您想要的需要很长时间的操作。根据您的组织，您现在可以添加到可部署包（文档等），根据客户端可见的内容或类似内容重命名版本。通过这里的构建可以很好地上线。
最后，我想提一下，解决这个问题的方法也会因项目而异，尤其是在改造 CI 的情况下。您甚至可能希望有一个单独的持续构建，仅包含构建和单元测试，并有一个每天一次（或其他）构建来提供发布和测试。这当然意味着只有开发才使用快速 CI 构建，因为它们不完整且不适合部署。不过，从长远来看，这并不是您想要的。 您希望整个链条自动化。
The answer to your question depends highly on the project you're working on and the goals you want to set.
In general, (trivially true for small projects) a build should be very fast and it should include everything needed for deployment. This is for me always the goal even if I don't reach it - at least not at once. It just keeps me looking at what can be improved all the time.
I know from working on big legacy projects that there are so many accumulated problems slowing things down that it might not be feasible. At least not as an immediate target at least. In large legacy projects compiling and linking usually takes too long, tests (if existing) might also run too long and generating all the required information for deployment might also be slow and even manual. Also build hardware might be insufficient. There are many other things to add to this incomplete list.
When working on a project like this, I try to have separate cycles doing things.
First cycle, a solid CI server which builds, runs automated unit tests, packages and archives builds. This must be fast to give fast feedback to development on changes made. If this is slow, get better hardware for building, sort out dependencies and fix slow unit tests etc. You want this to be as fast as possible. The builds are all deployable builds.
The second cycle would be a slower cycle only picking up builds made by the CI system. It does not work with source code as input, but rather release builds. These are picked up as you want (every build produced) or latest available when ready to do another cycle. This longer cycle would consist of deploying the build onto a test server, run automated functional tests and do other things which are "too slow", "not yet fast" or something else you want which takes a long time. Depending on your organization, you can now add to the deployable package (docs etc.), rename the release according to something visible to clients or things like that. Builds passing here could be good-to-go-live.
If you also have performance tests to run, you might want a third cycle which works with the second cycle's builds as input.
This is briefly described, but the main point here is to separate things, so you can have everything in the chain while getting feedback quicker than having one cycle. I find this a good approach as it's possible to get the benefits of speed (feedback) as well as a natural place to do things.
Finally, I want to mention that the way to go about this would vary from project to project as well, especially if you retrofit CI. You may even want to have a separate continuous build with only build and unit tests, and have a one a day (or something) build which feeds the releases and testing. This would of course mean that only development uses the fast CI builds, because they're incomplete and not suitable for deployment. Still, long-term this is not where you want to be. You want to have the whole chain automated.
Over the years I've done this a number of ways. The first was that the release build would happen IF and ONLY IF the 'sanity test' passed for the debug build. It would also auto-deploy to our pre-production environment for user-driven validation.
I've also seen this done where release builds are treated almost as sacred, and that they are only made when it is deemed 'time to get ready to really deploy'. Along with that comes some 'paperwork' and approvals, and then the release build is made (manually) and then it is sanity checked and then deployed.
From my experience it doesn't really matter as long as you are consistent and that it works with the way the company/team understands it should work. Going against the grain is easy at first but then results in what happened at one client which is they actually abandoned a structured build/deployment approach all together (a $100M company did that, imagine, but they did).
发布评论
评论（3）
通常我这样做的方式是将我的夜间构建升级为发布构建。您通常不想创建单独的发布版本。大多数 QA 团队应该测试夜间构建（希望他们不是从您的 CI 构建进行测试）。一旦他们认为它足够好，可以发布，您就可以将其提升为发布状态。你决定这意味着什么。将其移动到另一个位置，重命名，标记，标记，刻录等。
您不想每晚进行 QA 测试，然后当他们认为好的时候，再构建另一个，您说是相同的。你永远不知道，它们可能会有所不同。操作系统补丁可能已应用于您的构建计算机，第三方工具可能已更新，等等。您不希望让您的 QA 团队工作两次来测试“相同的确切构建”。它可能来自同一来源，但不能保证它是完全相同的构建。
Usually the way I do it is my nightly builds get promoted to Release builds. You usually don't want to create a separate release build. Most QA teams should test nightly builds (hopefully they aren't testing from your CI builds). Once they have deemed it good enough for release, you promote it to release status. You determine what that means. Move it to another location, rename it, tag it, label it, burn it, etc.
You don't want to have QA testing a nightly, then when they deem it good, build another one, that you say is the same. You never know, they can be different. An OS patch may have been applied to your build machine, a third party tool may have been updated, etc. You don't want to make your QA teams work twice to test the "same exact build". It might be from the same source, but there is no guarantee it is the same exact build.
您的问题的答案很大程度上取决于您正在从事的项目以及您想要设定的目标。
一般来说，（对于小型项目来说确实如此）构建应该非常快，并且应该包括部署所需的一切。对我来说，这始终是目标，即使我没有达到——至少不是立刻。它只是让我一直关注可以改进的地方。
我从大型遗留项目的工作中了解到，有太多累积的问题拖慢了速度，以至于它可能不可行。至少不是作为直接目标。在大型遗留项目中，编译和链接通常需要太长时间，测试（如果存在）也可能运行太长时间，并且生成部署所需的所有信息也可能很慢，甚至是手动的。另外构建硬件可能还不够。还有许多其他内容需要添加到这个不完整的列表中。
当从事这样的项目时，我尝试使用单独的周期来做事情。
第一个周期，一个可靠的CI服务器，用于构建、运行自动化单元测试、打包和存档构建。 必须快速提供快速反馈以对所做的更改进行开发。如果这很慢，请获取更好的硬件来构建，整理依赖关系并修复缓慢的单元测试等。您希望这尽可能快。这些构建都是可部署的构建。
第二个周期将是一个较慢的周期，仅拾取 CI 系统所做的构建。它不使用源代码作为输入，而是使用发布版本。这些可以根据您的需要（每个生成的构建）进行选择，或者在准备进行另一个周期时选择最新的可用的。这个较长的周期将包括将构建部署到测试服务器上，运行自动化功能测试以及执行其他“太慢”、“还不快”的操作或其他您想要的需要很长时间的操作。根据您的组织，您现在可以添加到可部署包（文档等），根据客户端可见的内容或类似内容重命名版本。通过这里的构建可以很好地上线。
如果您还需要运行性能测试，您可能需要第三个周期，它与第二个周期的构建一起作为输入。
这是简要描述的，但这里的要点是分离事物，这样您就可以拥有链条中的所有内容，同时比一个周期更快地获得反馈。我发现这是一个很好的方法，因为它可以获得速度（反馈）的好处以及一个自然的做事的地方。
最后，我想提一下，解决这个问题的方法也会因项目而异，尤其是在改造 CI 的情况下。您甚至可能希望有一个单独的持续构建，仅包含构建和单元测试，并有一个每天一次（或其他）构建来提供发布和测试。这当然意味着只有开发才使用快速 CI 构建，因为它们不完整且不适合部署。不过，从长远来看，这并不是您想要的。 您希望整个链条自动化。
The answer to your question depends highly on the project you're working on and the goals you want to set.
In general, (trivially true for small projects) a build should be very fast and it should include everything needed for deployment. This is for me always the goal even if I don't reach it - at least not at once. It just keeps me looking at what can be improved all the time.
I know from working on big legacy projects that there are so many accumulated problems slowing things down that it might not be feasible. At least not as an immediate target at least. In large legacy projects compiling and linking usually takes too long, tests (if existing) might also run too long and generating all the required information for deployment might also be slow and even manual. Also build hardware might be insufficient. There are many other things to add to this incomplete list.
When working on a project like this, I try to have separate cycles doing things.
First cycle, a solid CI server which builds, runs automated unit tests, packages and archives builds. This must be fast to give fast feedback to development on changes made. If this is slow, get better hardware for building, sort out dependencies and fix slow unit tests etc. You want this to be as fast as possible. The builds are all deployable builds.
The second cycle would be a slower cycle only picking up builds made by the CI system. It does not work with source code as input, but rather release builds. These are picked up as you want (every build produced) or latest available when ready to do another cycle. This longer cycle would consist of deploying the build onto a test server, run automated functional tests and do other things which are "too slow", "not yet fast" or something else you want which takes a long time. Depending on your organization, you can now add to the deployable package (docs etc.), rename the release according to something visible to clients or things like that. Builds passing here could be good-to-go-live.
If you also have performance tests to run, you might want a third cycle which works with the second cycle's builds as input.
This is briefly described, but the main point here is to separate things, so you can have everything in the chain while getting feedback quicker than having one cycle. I find this a good approach as it's possible to get the benefits of speed (feedback) as well as a natural place to do things.
Finally, I want to mention that the way to go about this would vary from project to project as well, especially if you retrofit CI. You may even want to have a separate continuous build with only build and unit tests, and have a one a day (or something) build which feeds the releases and testing. This would of course mean that only development uses the fast CI builds, because they're incomplete and not suitable for deployment. Still, long-term this is not where you want to be. You want to have the whole chain automated.
多年来，我通过多种方式做到了这一点。第一个是，当且仅当调试版本的“健全性测试”通过时，发布版本才会发生。它还会自动部署到我们的预生产环境中，以进行用户驱动的验证。
我还看到过这种做法，发布版本几乎被视为神圣的，并且只有在被视为“准备真正部署的时间”时才会制作它们。随之而来的是一些“文书工作”和批准，然后（手动）发布版本，然后进行健全性检查，然后部署。
根据我的经验，只要你保持一致并且按照公司/团队理解的方式工作，这并不重要。一开始违背常规很容易，但随后会导致一个客户发生的事情，他们实际上完全放弃了结构化构建/部署方法（想象一下，一家价值 1 亿美元的公司这样做了，但他们确实这样做了）。
Over the years I've done this a number of ways. The first was that the release build would happen IF and ONLY IF the 'sanity test' passed for the debug build. It would also auto-deploy to our pre-production environment for user-driven validation.
I've also seen this done where release builds are treated almost as sacred, and that they are only made when it is deemed 'time to get ready to really deploy'. Along with that comes some 'paperwork' and approvals, and then the release build is made (manually) and then it is sanity checked and then deployed.
From my experience it doesn't really matter as long as you are consistent and that it works with the way the company/team understands it should work. Going against the grain is easy at first but then results in what happened at one client which is they actually abandoned a structured build/deployment approach all together (a $100M company did that, imagine, but they did).