软件开发是需要快速高质量的交付给客户，微服务也一样。如何将微服务快速高质量的交付到线上环境，也是微服务重点解决的问题。
实践证明持续集成（CI：Continuous Integration）， 持续交付（CD：Continuous Delivery）和 持续部署(Continuous Delivery, CD):是可以解决这种问题的最佳实践。
CI 持续集成：
当开发人员将代码提交到版本控制系统后（如git），后续的构建，单元测试后续各个环节都尽可能的自动化，而持续集成（CI）就可以帮助开发人员更加频繁地将代码更改合并到共享分支或“主干”中。一旦开发人员对应用所做的更改被合并，系统就会通过自动构建应用并运行不同级别的自动化测试（通常是单元测试和集成测试）来验证这些更改，确保这些更改没有对应用造成破坏。这意味着测试内容涵盖了从类和函数到构成整个应用的不同模块。如果自动化测试发现新代码和现有代码之间存在冲突，CI 可以更加轻松地快速修复这些错误。
持续集成有很多开源的软件，如常用的Jenkins，也有一些成熟的云服务，比如Travis CI，circleci。
CD 持续交付：
完成 CI 中构建及单元测试和集成测试的自动化流程后，持续交付可自动将已验证的代码依次发布到各个存储库（测试环境->预发布环境->生产环境）。为了实现高效的持续交付流程，务必要确保 CI 已内置于开发管道。持续交付的目标是拥有一个可随时部署到生产环境的代码库。
CD 持续部署:
将最终产品发布到生成环境、给用户使用。
CI/CD流水线
对于支持CI/CD相关工具集成起来，再配合企业的软件治理流程所组成的软件交付链路就称为CI/CD流水线。
CI/CD流水线可以提交企业开发软件的效率，知名的互联网公司Netflix有专门的团队去开发CI/CD，他们把CI/CD流水线称为铺好的路（Paved Road），寓意是为开发人员铺一条可以快速开发并高质量交付的路。
GitOps
近些年随着Kubernetes等云原生的发展，业界提出了GitOps这种云原生的持续交付模型。 GitOps 是一种快速、安全的方法，可供开发或运维人员维护和更新运行在 Kubernetes 或其他声明式编排框架中的复杂应用。
简单理解GitOps就是相当于Cloud Native + CI/CD。
GitOps流水线有CI和CD两个阶段，如下图所示。
GitOps的CI和传统的CI一样，当代码发布到Git仓库，然后触发CI构建流程，产生容器镜像并推送到镜像仓库。
GitOps的CD一般是开发或者运维人员将更新后的配置提交到Git仓库，这里有个发布状态同步器，会定期监听Git仓库预期变化（Desired state），也会监听K8s中实际的发布状态（Actual State），发布状态同步器会对比这两边，如果发现不一致它会进行协调，让两边达到最终一直，这样可以实现持续发布这样的功能。另外发布状态同步器的触发可以是手动也可以是自动触发。
k8s的好处：
- 简化应用部署
- 提高硬件资源利用率
- 健康检查和自修复
- 自动扩容缩容
- 服务发现和负载均衡