在一个典型组织中，一个定义明确的 SDLC 实践通常具有与用户和角色一起运行的项目。 这些用户根据业务需求/要求设计，开发，测试和部署作业。但是你有没有想过：

1. 那之后的代码会发生什么？
2. 如果多个开发者想从事相同的工作怎么办？
3. 您将如何存储这些代码，以及如何确保其他开发人员始终选择正确的版本？

那么欢迎来到“持续集成”的世界。

在本博客中，我将强调持续集成（CI）的过程，连续性的重要性以及如何使用 Talend CI 构建工具结合 Jenkins 和 Maven 插件去实现目的。

首先让我们熟悉一些基本术语

1. 持续集成：CI 是一种开发实践，要求团队成员频繁的集成他们的工作，每一次集成都由自动化构建来验证，以便尽可能快的发现错误
2. 持续测试：CT 意味着每次集成完成后，都会运行预定义的测试用例，以确保新的代码不会破坏现有系统
3. 持续部署：CD 意味着你交付软件是基于连续递增的方式，并经常部署，在这里，可以部署到测试环境或者是预生产环境。

所以，作为一个组织变得持续性应该是由 CI,CT,CD 驱动的，并且他必须融合在软件开发周期中，下面的图显示了从 SDLC 生命周期到 CI,CT,CD 阶段的融合。

因此，持续性的好处是什么？如果正确实现了并且定期进行实践，持续性有助于减少集成的问题，这些会使你交付作业／代码／软件更加迅速。

另外，通过定期集成，你能快速检测错误，并且很容易的定位它们。通过使用正确的工具，在集成代码的时可以减少冲突和更容易解决冲突。最重要的一点是，你没有机会打破已经存在的东西，即使他坏了，也更容易解决／恢复。

持续工作流概述

为了进行持续集成，需要有一个仓库，可以保存、检索和维护代码。这个仓库必须足够的好，可以提供开发人员一个强大的版本控制系统。

虽然有许多 CI 工具可以用，但是我建议尝试 Git，Git 是一种版本控制软件，用于跟踪代码变化和协调许多人之间的代码工作。

它主要用于软件开发中的源代码管理，但是它能用来追踪任何一组文件的改变，它提供了少量的常见工作流模型

集中式工作流

此流程使用中央仓库作为项目所有更改的单点入口。默认的开发分支为主干，所有的更改都要提交到这个分支。除了主干以外，这个工作流不需要任何其他分支。典型的集中式工作流生命周期如下：

1. 开发人员首先将中心仓库克隆到自己本地的项目副本中，他们编辑作业并在本地提交更改，一旦更改被测试通过，开发人员将本地主干分支推到中央仓库。
2. 管理冲突：中央仓库代表官方的项目，因此如果本地工作与上游提交发生冲突，Git 将暂停处理并提供手动解决冲突的机会。这使得开发人员更容易管理合并。

你可能注意到了这个集中式工作流更像是具有很少 Git 特性的 SVN。这对 SVN 转型团队来说非常好，不过他并没有使用 Git 的分布式特性。

特性分支工作流

特性分支工作流的核心思想是，所有的功能开发都应该在专用分支中进行而不是主干，Git 不会在主干分支和特性分支之间进行技术上的区别。因此，开发人员可以像在集中式工作流中一样编辑，分段和提交。这里，一个典型的工作流如下所示：

1. 每当开始新功能开发工作时，开发人员就创建一个新的分支。
2. 特性分支应具有描述性名称，如问题#1061，Jira-190。这是为了给每个分支提供一个清晰的、高度集中的目标。

Gitflow工作流

定义了围绕项目发布设计的严格分支模型。这为管理大型项目提供了一个健壮的框架，和特性分支工作流类似，只是他分配了非常具体的角色给不同的分支，并定义了他们应该如何以及何时进行交互。

它还使用了各个独立的分支来准备，维护和记录发布。像前面的工作流一样，开发人员在本地工作并推送分支到中央仓库，唯一的区别是项目的分支结构，你定义了历史分支，特性分支，发布分支和维护分支

作者：Rekha Sree
原文：https://dzone.com/articles/an-introduction-to-continuous-integration-and-work
译者：one day