我经历了一些可用于持续集成（以及持续交付和部署）的资源，例如：
我的问题是
答案 0 :(得分：1)
让我们尝试使用一个真正简化且不一定正确的真实示例：
我正在为一家开发Android应用程序的公司工作。目前，我们必须开发一个应用程序，这只是一个很小的项目，所以只有我和另一位同事在该应用程序上工作。
由于我们是一流的开发人员，所以我们当然会编写测试，并且只希望在应用程序实际编译且我们的所有测试均为绿色时，我们的代码才能到达develop分支。
要使此重复执行的任务自动化，我们使用自动化/连续服务器，例如Jenkins（或诸如Bamboo之类的东西），并创建一个工作流，该工作流可构建项目代码并在每次尝试提交时运行测试develop分支的任何代码。
只有成功构建并且所有测试均为绿色，我们的代码才会被集成到develop分支中。
->我们正在使用持续集成，
现在，几个月后，我们决定可以将我们的应用发布给Play商店的用户。
我们从develop分支中获取应用程序当前（并希望经过全面测试）版本的代码，并将其复制到名为release的新分支中。
release分支在第二个Jenkins工作流中使用，目前与我们的第一个工作流相同：它从该分支构建代码并对其进行测试。
然后，我们需要在新的Jenkins工作流程中添加另一个步骤。当我们的应用代码成功构建并且所有测试都变为绿色时，我们希望将应用自动部署 /上载到Play商店，以便用户可以将其下载并安装在手机上。
->我们正在使用持续部署，
答案 1 :(得分：0)
正如您通过相关链接所提到的那样，因此我假设您知道什么是持续集成和部署。
仅当您需要在部署代码之前集成测试（或其他功能）并希望自动化此任务时，您可以使用Jenkins / circleCI AKA连续集成工具之类的连续服务器。
现在，如果您希望自动触发部署到服务器（生产）而无需手动升级到生产，则应该进行连续部署。