k8s部署-26-k8s与cicd持续集成、交付、部署的总流程（一）

cicd是什么？ cicd是做什么的，如何使用cicd，是不是身边的人经常说这些东西的，但是到底是什么，你真的理解了嘛？ 我们往下看哈。

什么是cicd

CICD，简单来说就是持续集成，持续交付的一整套流程。

随着 DevOps 的兴起，出现了持续集成、持续交付 (CI/CD) 和持续部署的新方法。传统的软件开发和交付方法正在迅速过时。从历史上看，在敏捷时代，大多数公司会以每月、每季度、每两年甚至每年发布一次的方式部署/发布软件。然而现在，在 DevOps 时代，每周一次、每天一次，甚至一天多次是常态。当 SaaS 正在接管世界时尤其如此，您可以轻松地即时更新应用程序，而无需强迫客户下载新组件。很多时候，他们甚至不会意识到事情正在发生变化。 

持续集成

持续集成（CI）可以帮助开发者更加方便地将代码更改合并到主分支。

CI 的目标是将集成改进为一个简单、易于重复的日常开发任务，这将有助于降低总体构建成本并在周期的早期发现缺陷。CI 的成功将取决于开发团队文化的变化，以便有动力准备好、频繁和迭代构建，以及在更早发现错误时急于处理错误。

持续交付实际上是 CI 的扩展，其中软件交付过程进一步自动化，以便随时轻松、自信地部署到生产中。成熟的持续交付流程展示了始终可在现场部署的代码库。有了 CD，软件发布就变成了例行公事，没有情绪或紧迫感。团队继续进行日常开发任务，相信他们可以构建生产级版本——任何他们喜欢的时间——无需精心编排或特殊的后期游戏测试。

持续部署

持续部署扩展了持续交付，因此如果软件构建通过所有测试，它将自动部署。在这样的过程中，不需要一个人来决定何时以及什么产品投入生产。CI/CD 系统的最后一步将自动部署成功退出交付管道的任何构建组件/包。这种自动部署可以配置为向客户快速分发组件、功能和修复程序，并准确说明目前生产中的内容。

采用持续部署的组织可能会从用户对新部署的快速反馈中受益。功能快速交付给用户，任何明显的缺陷都可以及时处理。用户对无用或误解功能的快速响应将有助于团队重新聚焦并避免将更多精力投入到不太可能产生良好投资回报的功能领域。

无cicd的情况

在没有提出cicd概念和实际配套的环境之前，我们是怎么从开发-测试-部署的呢？

1、开发人员写完代码之后上传到gtilab上；

2、然后本地使用IDE（maven）打包程序；

3、发布到指定的服务器上；

4、停服务，替换服务，启动服务。

每一步都需要人工去操作这是次要的，其次还面临着一些风险，如下：

1、服务间断；

2、环境不可控，因为不可能每台服务器部署一个服务；

3、多次构建，因为你要到达生产环境，可能需要经过开发、测试、预发布、准生产环境之后，才能到达生产环境；

但是我们如果使用cicd的话，整体流程就可以自动化的来进行，当然了cicd的模式，以及插件有很多，这里只介绍一种，也是k8s中最常见的一种。

有cicd的情况

剩余内容请转至VX公众号 “运维家” ，回复 “133” 查看。