持续集成持续部署持续交付

Everything you need to know to get started with continuous integration: branching strategies, tests automation, tools and best practices.

开始进行持续集成所需的一切：分支策略，测试自动化，工具和最佳实践。

目标：快速安全地交付工作代码 (The goal: Deliver working code quickly and safely)

The goal of Continuous Integration is to deliver code to the main branch of your repository:

持续集成的目标是将代码交付到存储库的主分支：

• Quickly: from pushing new code to the repository to merging it to the main branch when it works should be done within minutes快速：从新代码推送到存储库到工作时将其合并到主分支，应在几分钟内完成
• Safely: how do we know the new code works? Continuous Integration is about setting up the right checks to merge code automatically in full confidence安全地：我们如何知道新代码有效？ 持续集成是指设置正确的检查以完全自信地自动合并代码

Continuous Integration is a bit about tools and a lot about mindset and culture in the team. You want your development process to facilitate fast integration of new code while keeping a working main branch at all times. This working main branch will enable Continuous Delivery or Continuous Deployment in the future. But these are for another post. Let’s focus on Continuous Integration first.

持续集成与工具有关，与团队中的观念和文化息息相关。 您希望您的开发过程能够促进新代码的快速集成，同时始终保持主分支正常工作。 这个工作的主要分支将在将来启用持续交付或持续部署。 但是这些是另一篇文章。 让我们首先关注持续集成。

There are 2 pillars to achieve Continuous Integration:

实现持续集成有两个Struts：

小块工作 (Work in small chunks)

Imagine a team of 5 working on a SaaS product. Each of them develops a separate new feature. The workload on each feature is about 1 or 2 weeks. There are 2 ways to go here.

想象一下一个由5人组成的团队在研究SaaS产品。 他们每个人都开发一个单独的新功能。 每个功能的工作量约为1或2周。 这里有2种方法。

• The team could go with feature branches. Each developer will work on their part on a “feature branch”. The branches will be merged to the main branch once everyone is happy with their work团队可以使用功能分支。 每个开发人员都将在“功能分支”中工作。 每个人对工作满意后，分支将合并到主分支
• The team could go with branches (still) but integrate their work to the main branch on every push. Even if things are still a work in progress! The work in progress would remain invisible to any end user or tester of the main branch该团队可以(仍然)使用分支机构，但每次推送时都将其工作集成到主分支机构中。 即使事情仍在进行中！ 正在进行的工作对于主分支的任何最终用户或测试人员将不可见

Which approach do you think will work best?

您认为哪种方法最有效？

The first approach will ultimately lead to the “unpredictable release syndrome”. Long lived feature branches create a false sense of safety and comfort for each developer individually. As the branches drift apart for a long period of time, there is no way to measure how hard it will be to merge it all. At best some minor code conflicts will arise, at worst fundamental design assumptions will be challenged and things will have to be reworked … the hard way.

第一种方法最终将导致“不可预测的释放综合症”。 长期存在的功能分支会给每个开发人员分别带来错误的安全感和舒适感。 由于分支分散很长一段时间，因此无法衡量将所有分支合并的难易程度。 最好的情况是会出现一些较小的代码冲突，最坏的情况是将挑战基本的设计假设，并且必须重做……这是艰难的方法。

Rework will be done under time pressure, leading to a drop in quality and accumulation of technical debt. This is a vicious circle.

返工将在时间压力下进行，从而导致质量下降和技术债务累积。 这是一个恶性循环。

See the post about Why you should not use feature branches for the dirty details.

有关肮脏的详细信息，请参阅有关为何不应该使用功能分支的文章。

The second approach is what we need to enable continuous integration. Each developer does work on their own branch. Difference is:

第二种方法是我们需要进行持续集成。 每个开发人员都在自己的分支上工作。 区别是：

Changes are merged to the main branch on every push, and each developer syncs their branch with latest main branch version a few times a day.

每次推送时，更改都会合并到主分支中，并且每个开发人员每天都会几次将其分支与最新的主分支版本同步。

This way the team can fix conflicts and align design assumptions faster and easier. 5 small problems discovered early on are way better that 1 big problem discovered just before release day. Check out the “Feature Toggles” section below to see how you should integrate “work in progress” to the main branch.

这样，团队可以更快，更轻松地解决冲突并调整设计假设。 早期发现的5个小问题比发布前一天发现的1个大问题要好得多。 请查看下面的“功能切换”部分，以了解如何将“进行中的工作”集成到主分支中。

安全来自于自动检查 (Safety comes with automated checks)

Ancient software development process was based on a build cycle followed by a test cycle. And this would probably still fit the “feature branches” approach described above. If we integrate and merge code tens of times a day, manual testing does not make sense. It would take too long. We need automated checks to verify that the code works properly. We need a CI tool that will take each developers’ push and run build and tests automatically.

古代软件开发过程是基于构建周期和测试周期的。 而且这可能仍然适合上述“功能分支”方法。 如果我们一天要整合和合并代码数十次，那么手动测试就没有意义。 会花太长时间。 我们需要自动检查以验证代码是否正常运行。 我们需要一个CI工具，该工具将接受每个开发人员的推送并自动运行构建和测试。

The test’s type and content should be:

测试的类型和内容应为：

• fast enough to provide feedback to the developer within minutes足够快地在几分钟内向开发人员提供反馈
• thorough enough to merge the code to the main branch in full confidence足够彻底地将代码完全合并到主分支中

Unfortunately there is no one size fit all test type and content. The right balance is specific to your project. Do not run large and time consuming test suites during your CI phase. Such tests provide better safety but they come at the cost of a delayed feedback to the developers. This leads to context switching which is a pure waste of time.

不幸的是，没有一种适合所有测试类型和内容的尺寸。 适当的平衡是针对您的项目的。 在CI阶段，请勿运行大型且耗时的测试套件。 这样的测试提供了更好的安全性，但是却以延迟反馈给开发人员为代价。 这导致上下文切换，这纯粹是浪费时间。

优化开发人员的时间并减少上下文切换 (Optimize developers’ time and reduce context switching)

Long CI checks, and by long I mean over 3 minutes, introduce a compound waste of time for each developer in your team. Let’s compare a “good” and a “bad” worklow.

冗长的CI检查(很长时间(平均超过3分钟))会给您团队中的每个开发人员造成时间上的浪费。 让我们比较一下“好”和“坏”的工作流程。

The “good” workflow:

“良好”的工作流程：

• You commit and push your code您提交并推送您的代码
• The CI build and tests run for 1 to 3 minutesCI构建和测试运行1-3分钟
• During the 1 to 3 minutes you review the task at hand, bump the status in some management tool, or review your code once again在1至3分钟内，您将审阅手头的任务，更改某些管理工具的状态或再次审阅代码
• Within 3 minutes you get a successful status: you can move on to the next part of your task. If you get a failed build: you can fix the issue right away在3分钟内，您将获得成功的状态：您可以继续执行任务的下一部分。 如果构建失败：您可以立即解决问题

The “bad” workflow:

“不良”工作流程：

• You commit and push your code您提交并推送您的代码
• The CI build and tests run for 15 minutesCI构建和测试运行15分钟
• What do you do during these 15 minutes?您在这15分钟内会做什么？
• You could grab a cup of coffee with the team. Fair enough, but how many of these can you have per day?您可以和团队一起喝杯咖啡。 足够公平，但是您每天可以有多少个？
• You would probably get your head on the next task in your pipeline您可能会着手处理管道中的下一个任务
• 15 minutes later you get a failed build notification. You need to switch back to the previous task, try to fix the issue … and go for another 15 minutes loop …15分钟后，您会收到失败的构建通知。 您需要切换回上一个任务，尝试解决该问题……然后再循环15分钟……
• At that point you are wondering: should I get back to this next task again or just wait the 15 minutes and achieve peace of mind that I am actually really done with my current task …那时，您想知道：我应该再回到下一个任务还是等待15分钟，让我放心，我实际上已经完成了当前任务……

The bad workflow is not only a waste of time. It is also frustrating for developers. And productive developers are happy developers.

糟糕的工作流程不仅浪费时间。 这也让开发人员感到沮丧。 生产性开发人员是快乐的开发人员。

You need to align your tools and workflows to keep your developers happy.

您需要调整工具和工作流程，以使开发人员满意。

工具类 (Tools)

分枝 (Branching)

Continuous Integration is about integrating code from different developers’ branches to a common branch in your configuration management system. Chances are you are using git. In git the default main branch in a repository is called “master”. Some teams create a branch called “develop” as the main branch for continuous integration. They use “master” to track deliveries and deployments (develop being merged to master).

持续集成是将代码从不同开发人员的分支集成到配置管理系统中的公共分支。 您可能正在使用git。 在git中，存储库中的默认主分支称为“ master”。 一些团队创建一个名为“ develop”的分支作为持续集成的主要分支。 他们使用“母版”来跟踪交付和部署(将开发内容合并到母版中)。

You probably already have a main branch your team pushes or merges code to. Stick with it.

您可能已经有一个主要分支，您的团队将代码推送或合并到该分支。 坚持下去。

Each developer should work on their own branch. One can use multiple branches if working on many different topics at once. Although this would be a sign of “unfocused” work at best. As soon as a consistent part of your code is ready, push your repository. The CI checks will kick in and merge your code to the main branch if they are successful. If the checks fail, you are still on your own branch and can fix whatever needs to be fixed and push again.

每个开发人员都应该在自己的分支上工作。 如果一次处理多个不同的主题，则可以使用多个分支。 尽管这充其量是最好的“无重点”工作的标志。 一旦代码的一致部分准备就绪，请推送您的存储库。 如果成功，CI检查将启动并将您的代码合并到主分支。 如果检查失败，则您仍在自己的分支上，可以修复需要修复的任何内容并再次推送。

The important word in the process above is consistent part of your code. How do you know it is consistent? Simple.

上面过程中的重要单词是代码的一致部分 。 您怎么知道它是一致的？ 简单。

If you can easily come up with a good commit message, it’s consistent.

如果您可以轻松提出一个好的提交消息，那么它是一致的。

On the other hand if your commit message needs 3 bullets and many adjectives and adverbs, it’s probably not good. Split your work in multiple, consistent commits. And then push the code. Consistent commits help code reviews and make the repository history easier to follow.

另一方面，如果您的提交消息需要3个项目符号以及许多形容词和副词，则可能不是很好。 将您的工作分成多个一致的提交。 然后推送代码。 一致的提交有助于代码审查，并使存储库历史记录更易于遵循。

Don’t just push whatever because it’s the end of the day!

不要仅仅因为它已经结束而推动任何事情！

拉取要求 (Pull requests)

What is a pull request? A pull request is a concept in which you ask the team to merge your branch to the main branch. The acceptance of your request should go through a status provided by your CI tool and potentially a code review. Ultimately the manual acceptance of a human being in charge of merging the pull requests.

什么是拉取请求？ 拉取请求是一个概念，在该概念中，您要求团队将您的分支合并到主分支。 接受请求应经过CI工具提供的状态，并可能需要进行代码审查。 最终，人工负责合并合并请求请求的人员。

Pull requests were born in open source projects. Maintainers needed a structured way to evaluate contributions before merging them in. Pull requests are not part of Git. They are supported by any Git provider, though (GitHub, BitBucket, GitLab, …).

拉取请求诞生于开源项目中。 维护人员需要一种结构化的方法来评估捐款，然后再将其合并。拉取请求不属于Git。 但是，任何Git提供程序都支持它们(GitHub，BitBucket，GitLab等)。

Note that pull requests are not mandatory for Continuous Integration. Their main benefit is to support a code review process, which cannot be automated by design.

请注意，对于持续集成，拉取请求不是必需的。 它们的主要好处是支持无法通过设计自动执行的代码审查过程。

If you are using pull requests, the same principles of “work in small chunks” and “optimize developers time” apply:

如果您使用拉取请求，则“小块工作”和“优化开发人员时间”的相同原则适用：

• keep each pull request small and with one clear purpose (it will make code review way easier)将每个拉取请求保持较小且有一个明确的目的(这将使代码查看方式更容易)
• keep your CI checks fast保持您的CI快速检查

自动检查 (Automated checks)

The heart of your Continuous Process are automated checks. They ensure that the main branch code is working properly after your code is merged. If they fail, your code does not get merged. As a minimum the code should compile or transpile or whatever your tech stack is doing to make it ready for runtime.

连续流程的核心是自动检查。 他们确保在合并代码后，主分支代码可以正常工作。 如果它们失败，则不会合并您的代码。 至少，该代码应可以编译或转译，或者您的技术堆栈正在做什么，以使其可以运行时就绪。

On top of compilation you should run automated tests to ensure the software works properly. The better the test coverage, the better confidence you can have in the new code being merged to the main branch. Careful though! Better coverage means more tests and longer execution time. You need to find the right tradeoff.

在编译之上，您应该运行自动化测试以确保软件正常运行。 测试范围越好，您对合并到主分支的新代码的信心就越大。 小心点！ 更好的覆盖范围意味着更多的测试和更长的执行时间。 您需要找到正确的权衡。

Where do you start when you have no tests at all or need to cut down on some long running tests? Focus on what is critical for your project or product.

当您根本没有测试或需要减少一些长期运行的测试时，您从哪里开始呢？ 将重点放在对您的项目或产品至关重要的方面。

If you are building a SaaS application, you should check that users can sign up or login, and perform the most basic operations your SaaS provides. Unless you are developing a Salesforce competitor, you should be able to run your tests within minutes if not seconds. If you are building a heavy data processing backend: use limited data sets to exercise the different building blocks. Keep long running runs on large data sets out of Continuous Integration. Long running tests can be triggered after code is merged.

如果要构建SaaS应用程序，则应检查用户是否可以注册或登录，并执行SaaS提供的最基本的操作。 除非您正在开发Salesforce竞争对手，否则您应该能够在几分钟甚至几分钟内运行测试。 如果您要构建大量的数据处理后端，请使用有限的数据集来练习不同的构建基块。 在大型数据集上保持长期运行，而不会进行持续集成。 合并代码后，可以触发长时间运行的测试。

专业提示 (Pro Tips)

功能切换 (Feature toggles)

The key concept of Continuous Integration is to put your code in the main branch as soon as possible. Even work in progress. Even features that do not fully work or that you don’t want exposed to testers or end users. The way to achieve that is to use feature toggles. Have your new feature under an enabled/disabled toggle. The toggle can be a compile time boolean flag, an environment variable or a runtime thing. The right approach depends on what you want to achieve.

持续集成的关键概念是尽快将代码放入主分支。 甚至正在进行中。 甚至某些功能无法完全使用，或者您也不想暴露给测试人员或最终用户。 实现此目的的方法是使用功能切换。 在启用/禁用切换下启用新功能。 切换可以是编译时布尔标志，环境变量或运行时事物。 正确的方法取决于您要实现的目标。

The first major benefits of feature toggles is that you can take them up to production and enable/disable the new feature upon need. You could restart a server with a changed environment variable, or toggle on/off a new UI dashboard layout. This way you have full flexibility to roll out the feature. Or disable it if causes unexpected issues in production. Or allow end users to opt in or out of the feature (in case of the UI toggles).

功能切换的第一个主要好处是您可以将其投入生产并根据需要启用/禁用新功能。 您可以使用更改后的环境变量重新启动服务器，也可以打开/关闭新的UI仪表板布局。 这样，您就可以完全灵活地推出该功能。 如果在生产中导致意外问题，请禁用它。 或允许最终用户选择启用或退出功能(在UI切换的情况下)。

The second major benefit of feature toggles is that they force you to think of the boundary between what you are doing and the existing code. This is a good exercise and this is what you should start with anyway every time you make an addition to an existing system. The feature toggle step makes this step of the process more visible.

功能切换的第二个主要优点是，它们迫使您考虑正在执行的操作与现有代码之间的界限。 这是一个很好的练习，这是每次添加到现有系统后都应该从头开始的事情。 功能切换步骤使该过程的步骤更加明显。

The only drawback on feature toggles is that you need to clean them up periodically from the environment and from the code. Once a feature is battle tested and adopted by users, it should be the default. The code for the toggle and the old version of things (if any) should be cleaned up. Don’t fall into the trap of a “configuration as toggles” system. The pitfall is that you will never be able to maintain and test all combination of the toggles and will have a fragile architecture in the end.

功能切换的唯一缺点是您需要定期从环境和代码中清除它们。 一旦功能经过实战测试并被用户采用，则应将其作为默认功能。 切换代码和旧版本的东西(如果有的话)应该清除。 不要陷入“切换配置”系统的陷阱。 陷阱是您将永远无法维护和测试所有切换组合，并且最终将拥有脆弱的架构。

将CI建立时间保持在3分钟以下 (Keep CI build time under 3 minutes)

Remember the “good” and the “bad” workflow in the first part of the article. We want to avoid context switching for developers. Pick your phone and set a 3 minutes timer on. See how long it is when you are just waiting for something! 3 minutes should be an absolute maximum for you to focus and move safely and efficiently from one task to the other.

记住本文第一部分中的“好”和“坏”工作流程。 我们希望避免为开发人员切换上下文。 拿起手机，并设置3分钟计时器。 看看等待什么时间！ 3分钟绝对是您最多的绝对时间，您可以集中精力并安全有效地将其从一项任务转移到另一项任务。

A build under 3 minutes might seem crazy to some teams, but it is definitely achievable. It has more to do with how you organize your work than the tools you use. Ways to optimize your build are:

3分钟以内的构建对于某些团队来说似乎是疯狂的，但这绝对是可以实现的。 与您使用的工具相比，它与您组织工作的方式更多有关。 优化构建的方法是：

• Use more build capacity: if you don’t have enough concurrent builds on your CI tool and builds get queued, developers lose time使用更多的构建能力：如果您的CI工具没有足够的并行构建，并且构建排队，开发人员将浪费时间
• Leverage caching: most tech stacks require you to install and configure dependencies when running a fresh build. Your CI tool should be able to cache these steps when dependencies do not change to optimize build time利用缓存：大多数技术堆栈都要求您在运行全新构建时安装和配置依赖项。 当依存关系不改变时，您的CI工具应该能够缓存这些步骤，以优化构建时间
• Review your tests: check that your tests are optimized for time. Remove timeouts and “safely long” waiting steps. If you have heavy tests suites to run, consider moving them on a separate build that is run after the merge to the main branch. They would not be part of the Continuous Integration safeguard anymore, but heavy tests should not be anyway查看测试：检查测试是否针对时间进行了优化。 删除超时和“安全长”的等待步骤。 如果您要运行繁重的测试套件，请考虑将它们移动到合并到主分支后运行的单独构建中。 它们不再是持续集成防护的一部分，但是无论如何都不应进行严格的测试
• Split your code base: do you have to have everything in one repository? Do you have to build and run tests on everything even when some small part changes? There might be wins here.拆分代码库：是否必须将所有内容都存储在一个存储库中？ 即使某些小部分发生更改，您是否也必须对所有内容进行构建和运行测试？ 这里可能会有胜利。
• Run tests conditionally: run your tests only if some directories have changed. If your codebase is well organized, this can be a huge win有条件地运行测试：仅在某些目录已更改的情况下运行测试。 如果您的代码库井井有条，这将是一个巨大的胜利

The great thing about forcing a short time limit on your CI checks is that it requires you to fundamentally improve your whole development process.

强制在较短的时间上进行CI检查的好处在于，它要求您从根本上改善整个开发过程。

As Jim Rohn said:

正如吉姆·罗恩(Jim Rohn)所说：

“Become a millionaire not for the million dollars, but for what it will make of you to achieve it”.

“成为百万富翁不是因为获得了百万美元，而是成为了您实现目标所能带来的好处”。

虚拟合并：您的代码本身并不重要 (The virtual merge: your code alone does not really matter)

Most Continuous Integration tools run the CI build on your branch to say if it can be merged or not. But that is not what is of interest here. If you know what you’re doing there is a pretty good chance that the code you have just pushed is working already! What your CI tool is supposed to verify is that your branch merged with the main branch works properly.

大多数持续集成工具会在您的分支机构上运行CI构建，以说明是否可以合并。 但这不是这里令人感兴趣的。 如果您知道自己在做什么，那么您刚刚推送的代码很有可能已经在工作！ 您的CI工具应该验证的是您的分支与主分支合并正常。

Your CI tool should perform a local merge of your branch to the main branch and run the build and tests against that. Your branch can then be automatically merged if the main branch does not change in the meantime. If it does change, the CI checks should be run again until your code can be safely merged. If your CI tools does not support this kind of workflow, change your tool.

您的CI工具应执行分支到主分支的本地合并，然后运行构建并对此进行测试。 如果主分支在此期间未更改，则分支可以自动合并。 如果确实发生更改，则应再次运行CI检查，直到可以安全地合并代码为止。 如果您的CI工具不支持这种工作流程，请更改您的工具。

邪恶的任务管理器 (The evil task manager)

There is a misbelief that it is cool to be able to trace the code related to a task in your Agile board or bug tracker like JIRA or similar. While it is a nice concept on paper, the impact on the development process is for sure not worth the effort. The task manager provides a “features and bugs” view of the world. The code is structured and layered in a very different way. Trying to reconciling an item in the task manager and a set of commits is pointless. If you want to know why a piece of code has been written, you should be able to get the information from the code context and comments.

令人怀疑的是，能够在敏捷板或Bug跟踪程序(例如JIRA或类似程序)中跟踪与任务相关的代码很酷。 尽管这是一个很好的概念，但对开发过程的影响肯定不值得付出努力。 任务管理器提供了世界的“功能和错误”视图。 代码以非常不同的方式进行结构化和分层。 试图协调任务管理器中的项目和一组提交是没有意义的。 如果您想知道为什么要编写一段代码，则应该能够从代码上下文和注释中获取信息。

最后的想法 (Final Thoughts)

Tools are only tools. Setting up the tools is probably a 1 hour thing. If you use them wrong though, you won’t get the expected results.

工具只是工具。 设置工具可能需要1个小时的时间。 如果您错误地使用它们，将无法获得预期的结果。

Keep in mind the goals we set for ourselves for Continuous Integration:

请记住我们为持续集成设定的目标：

• Deliver working code quickly and safely快速安全地交付工作代码
• Optimize developers’ time and reduce context switching优化开发人员的时间并减少上下文切换

The real deal is about shifting your mindset to “continuously deliver value” to your project or product.

真正的交易是改变思维方式，“为项目或产品“持续交付价值”。

Think of your software development process as a hardware production facility. Developers’ code represents the moving parts. The main branch is the assembled product.

将您的软件开发过程视为硬件生产设施。 开发人员的代码代表活动的部分。 主要分支是组装产品。

The faster you integrate the different pieces together and check that things are working, the closer you are to have a working product at the end.

您将各个部分集成在一起并检查工作是否正常的速度越快，最后获得有效产品的可能性就越大。

A few practical examples:

一些实际的例子：

• You are working on a new feature and have to change a low level component others will most likely use. Make a dedicated commit for that common component part and have it merge already. Then continue working on the rest of your feature. Other developers will be able to base their work on your change right away.您正在开发一项新功能，并且必须更改其他人最有可能使用的低级组件。 为此公用组件部分进行专用提交，并使其已经合并。 然后继续处理其余功能。 其他开发人员将能够立即根据您的更改进行工作。
• You are working on a large feature that will require a lot of time and code? Use a feature toggle. Don’t work in isolation. Ever!您正在开发一项需要大量时间和代码的大型功能吗？ 使用功能切换。 不要孤立地工作。 曾经！
• You are waiting for a code review but no one is available to do it. If your code is passing the CI checks then just merge it and make the code review happen afterwards. If it sounds like breaking the process, remember that “done is better than perfect”. If it is working, it provides more value in the main branch than parked on the side for days.您正在等待代码审查，但没有人可以这样做。 如果您的代码通过了CI检查，则只需合并它，然后再进行代码检查。 如果听起来像要打破流程，请记住“做总比做得好”。 如果它可以正常工作，那么它在主分支机构中提供的价值要比在边上停泊好几天。

Thanks for reading! If you find the article useful please hit the clap button below. It would mean a lot to me and it helps other people see the story!

谢谢阅读！ 如果您发现该文章有用，请点击下面的拍手按钮。 这对我来说意义重大，而且可以帮助其他人看到这个故事！

Article originally published at fire.ci on April 9, 2019.

该文章最初于2019年4月9日在fire.ci上发表。

翻译自: https://www.freecodecamp.org/news/how-to-get-started-with-continuous-integration-7b2f8d87c914/

持续集成持续部署持续交付