持续集成和部署的最佳实践 [英] Best-practice for continuous integration and deployment

问题描述

持续整合概念刚刚整合到我的小组中。

Continuous integration concept has just been integrated in my team.

假设我们有一个名为 Dev 的整合分支。

Assume we have an integration branch named Dev.

从它派生出3个分支，每个分支用于每个特定的当前项目：

From it derived 3 branches, one for each specific current project :

• A 项目 A
/ li>

• Project A
• Project B
• Project C

首先，Teamcity在专用服务器上配置，目标是：

First, Teamcity is configured on a dedicated server and it goals is :

从每个分支的版本来源编译并启动单元和集成测试，包括Dev

Compiles and launches unit and integration tests from versioned sources from each branch including Dev

然后，当然，每个项目分支和C）必须在克隆的生产环境中测试，以便可以执行UAT。

Then, of course, each project branch (A,B and C) must be tested in a cloned production environment so that UAT can be carried out.

但我不知道应该部署什么频率？每次源代码改变？

But I wonder what frequency should we deploy on? Everytime a source code changes ?

我们应该只部署包含3个项目的混合的Dev，在每个项目合并之后（对应于下一个生产版本中的现实）这3个项目是独立的吗？

Should we deploy only Dev that contains mix of the 3 projects after merging each one to it (corresponding to the reality in next production release) or the 3 projects independently?

如果部署了Dev，则不能考虑将来对Dev的更改。实际上，
可能有一个新项目开始于项目D ，并且不能是下一个版本的一部分。因此，由于部署者可能非自愿整合项目D的内容，所以采用开发者集成（UAT）是有风险的，因此环境不会揭示下一个版本的现实。

If Dev is deployed, potentially future changes on Dev must not be taken in account. Indeed, there might be a new project starting called Project D and that mustn't be part of the next release. So taking Dev for integration (UAT) is risked because deployer could unvoluntary integrate content of Project D and so environment will not reveal the reality of the next release.

其他解决方案：我们不是采取Dev但独立的3个项目，所以必须有3个克隆的生产环境并行？

Other solution: we're not taking Dev but independently the 3 projects, so must there be 3 cloned production environments in parallel?

如果是，UAT不可靠，因为集成环境的行为可能会变化很多...

If yes, UAT couldn't be reliable since behaviour of integration environment might change very often...

UAT的持续部署概念对我来说不清楚...

Concept of continuous deployment for UAT isn't clear for me...

推荐答案

你碰到现实的CD问题。真的很好的问题。

Oh boy. You're hitting real world CD problems. Really good questions.

答案取决于高度紧密耦合的开发工作是在各种项目。

The answer depends a bit on highly tightly coupled the development work is on the various projects.

在我的理想情况下，你会有一些努力特定的测试环境。在一种情况下，您可以考虑每个项目的测试环境。当项目A完成构建时，将其推入环境A，该环境具有用于B / C的最新批准/生产版本，您可以在那里执行基本集成测试。如果他们通过，你将构建提升到集成测试环境，其中最新的好A，沿着最新的B& C为同一版本。当集成测试环境通过测试时，您可以将其内容作为包含已知版本A，B和C的发布集来提升。 C.该发布集将部署到任何UAT，分级或生产环境。

In my ideal situation for you would be to have a number of "effort" specific test environments. In one case, you could consider a test environment for each project. When there is a completed build of Project A, you push it into Environment A which has the latest approved / production versions for B/C and you can perform basic integration tests there. If they pass, you promote the build to an integration test environment where the latest good A, is deployed along the latest B & C for the same release. When the integration test environment is passing tests, you can promote the contents of it as a release set containing known versions of A, B, & C. That release set would be deployed to any UAT, Staging, or Production environments.

基本思想是给每个项目一定程度的隔离，即使其他项目（暂时）严重中断，同时尽快进行完整的集成测试，测试也很好。我们还想确保，无论我们发现什么，通过集成测试将一起推广。挑选和选择尚未一起测试的项目版本对我的口味来说太冒险了。

The basic idea is to give each project a degree of isolation so that it can be tested well even if the other projects are (temporarily) badly broken, while getting to full integration tests as quickly as possible. We also want to make sure that whatever we find actually passes integration tests will be promoted together. Picking and choosing project versions to release that haven't been tested together is too risky for my taste.

这实际上是一个我可以讨论很多的话题。如果你不介意，我会列出几个关于这些主题的演示。

This is actually a topic I get to talk about quite a lot. If you don't mind, I'll list out a few presentations I've given around these topics.

1）用于并行开发的扩展CI （与Accurev的Chris Lucca共同提交）

1) Scaling CI for Parallel Development (co-presented with Chris Lucca of Accurev)

这是一个关于平衡隔离和集成的广泛策略的好方法。其中许多假设子项目被合并到一个通用的代码库，但是主体可以应用于独立构建和部署的模块，只有一点想象力。

This talks a good about broad strategies for balancing isolation and integration. Much of it assumes the sub-projects are being merged into a common code base, but the principals can be applied to independently built and deployed modules with only a little imagination.

2）使用uDeploy与Jenkins
（需要注册）

2) Using uDeploy with Jenkins (registration required)

这更侧重于产品，但几乎完全显示了为多个项目使用集成测试环境，创建一个发布集（我们称之为快照）和推广的想法。我们与TeamCity的整合非常相似，但我认为在那里举行的战略可能更重要

This is more product focused, but shows almost exactly the idea of using an integration test environment for multiple projects, creating a release set (we call it a "snapshot") and promoting that. Our integration with TeamCity is quite similar, but I think the strategy held in there may be more important

3）幻灯片显示多组件管道：

3) Slides visualizing a multi-component pipeline:

http://www.slideshare.net/城市代码/适应部署管道复杂应用程序

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