王子向公主求婚，2013nian，无弹窗
在谈DevOps的时候我更多谈的是CI/CD持续集成和持续布置，本日重点谈下持续交付和灰度发布方面的数据。在谈这个之前，照样准备先将前面几点的区别进行阐述。
CI/CD和持续交付
首先照样先谈下持续集成，持续布置和持续交付几个概念的区别。
对于CI持续集成一般来说是指完备的软件产物从源代码获取起头的编译，构建，打包，布置完备过程。而对于布置来说则是一个独立的动作，即将一键构建打包好的布置包或二进制的镜像文件，找到一个具体的中间件或容器资源，并将其布置下去。
也便是说。
持续集成一般涉及到重新的编译构建过程，而持续布置则不涉及到重新编译构建，而是拿已有的构建完成的布置包后镜像文件进行，即持续布置是基于二进制文件进行交付的。
你在测试阶段编译构建的包最终便是布置到生产情况的包，独一转变的便是配置文件和情况变量，确保你测试通过的数据不会因为重新编译，打包的原因引入新的Bug。
在CI/CD里面持续布置概念相当紧张，便是要阐明后期SIT，UAT各个测试情况间的迁移，测试情况朝生产情况的交付都是基于二进制布置文件或容器镜像进行的。
再简洁来说如果一个软件开发涉及到SIT，UAT和生产三个情况。那么仅仅在SIT情况阶段涉及到重新编译，构建，打包等操纵。而在后续两个情况仅仅是情况迁移，持续布置，不会再涉及到具体的编译构建。
持续布置和持续交付
对于持续交付这个概念，交付的重点一个是面向生产情况，另一个重点是面向最终的用户。那么是否生产情况的持续布置便是持续交付？
在早期，现实上生产情况持续布置便是持续交付，因为布置和交付两个过程并没有分离或解耦。也便是说生产情况布置完成后最终的用户马上就能够使用的。
然则到了当前阶段，稀奇是在云原生和DevOps下，生产情况布置完纷歧定就马上交付给用户使用，好比生产情况有A一套情况，然则在生产情况布置的时候我并没有将A覆盖而是重新布置了一套B情况。
这个时候布置动作已经完成，然则交付动作还没有完。只有当我们将用户最终访问的流量切换到B情况的时候，B情况才算完成了对用户的最终交付动作。
云原生弗成变根蒂设施
在谈云原生的时候谈到，云原生包含了一系列的管理实践和手艺实践，而里面的手艺实践包含了容器、ServerMesh服务网格，Serverless无服务器，微服务、弗成变根蒂设施和声明式API。这些手艺可以构建容错性好、易于管理和便于察看的松耦合体系。
里面谈到一点弗成变的根蒂设施。
我在前面的文章对这个手艺要素谈得对照少。弗成变根蒂设施里的“弗成变”非常类似于法式设计中的“弗成变”概念。法式设计中弗成变变量（Immutable Variable）便是在完成赋值后就不克产生变动，只能建立新的来团体替代旧的。由于具有这样的特征这种变量能够在并发情况下平安的使用。对于根蒂设施的弗成变性，最根基的便是指运行服务的服务器在完成布置后，就不再进行变动。
本文地址：http://www.wbwb.net/bianchengyuyan/212761.html 转载请注明出处！
