DevOps利用集装箱化微服务实现连续部署管道的自动化的资料说明

　　我开始了我的开发生涯。在那些早期的日子里，我只知道（并且认为我应该知道）写代码。我相信，一个伟大的软件设计师是一个精通代码编写的人，而掌握这门手艺的途径是了解关于一种选择的编程语言的一切。后来，情况发生了变化，我开始对不同的编程语言感兴趣。我从Pascal切换到Basic，然后是ASP。当Java和后来的.Net出现时，我学到了面向对象编程的好处。Python、Perl、Bash、HTML、JavaScript、Scala。每种编程语言都带来了一些新的东西，教会了我如何以不同的方式思考，如何为手头的任务选择合适的工具。每学一门新语言，我都觉得自己更接近成为一名专家。我只想成为一名高级程序员。这种渴望随着时间而改变。我知道，如果我要做好我的工作，我必须成为一个软件工匠。我要学的不仅仅是输入代码。一段时间以来，测试成了我的困扰，现在我认为它是开发的一个组成部分。除了在非常特殊的情况下，我编写的每一行代码都是用测试驱动开发（TDD）完成的，它成为我工具带中不可或缺的一部分。我还了解到，我必须接近客户，并与他并肩工作，同时确定应该做什么。所有这些和许多其他的事情都让我想到了软件架构。了解全局并尝试将不同的部分整合到一个大系统中是我学会喜欢的挑战。在我从事软件行业的所有岁月里，没有任何一种工具、框架或实践比持续集成（CI）以及后来的持续交付（CD）更让我钦佩，这种说法的真正含义隐藏在CI/CD所涵盖的范围之内。一开始，我认为CI/CD意味着我认识詹金斯，能够写剧本。随着时间的推移，我变得越来越投入，并且了解到CI/CD几乎涉及软件开发的每个方面。这种知识是要付出代价的。

　　我未能（不止一次）创建一个成功的CI管道，该管道包含我当时使用的应用程序。尽管其他人认为结果是成功的，但现在我知道这是失败的，因为我采取的方法是错误的。没有体系结构决策就无法完成CI/CD。对于测试、配置、环境、故障转移等，也可以说是类似的。为了创建一个成功的CI/CD实现，我们需要做很多改变，乍一看，这些改变似乎并不直接相关。我们需要从一开始就应用一些模式和实践。我们必须考虑体系结构、测试、耦合、打包、容错和许多其他事情。CI/CD要求我们影响软件开发的几乎每个方面。这种多样性使我爱上了它。通过实践CI/CD，我们正在影响和改进软件开发生命周期的几乎每个方面。要真正精通CI/CD，我们需要的不仅仅是操作方面的专家。DevOps运动是一项重大改进，将传统业务与开发可能带来的优势结合起来。我认为这还不够。如果我们想获得CI/CD所能带来的所有好处，我们需要了解并影响体系结构、测试、开发、运营甚至客户谈判。即使是作为CI/CD背后的驱动力的DevOps这个名字也不合适，因为它不仅涉及到开发和操作，而且涉及到与软件开发相关的一切。它还应该包括架构师、测试人员，甚至管理人员。与传统操作相比，DevOps将它们与开发结合起来，是一个巨大的改进。该运动明白，考虑到当前的业务需求，手动运行操作不是一个选项，没有开发就没有自动化。我认为是时候通过扩展DevOps的范围来重新定义它了。由于DevOpsArchTestManageAndEverythingElse这个名字太难记住，而且几乎不可能发音，所以我选择了DevOps 2.0。下一代应该放弃繁重的“一劳永逸”产品，转而使用更小的工具来完成非常具体的任务。这个交换机应该从头开始，不仅要确保操作自动化，而且整个系统的设计可以自动化、快速、可扩展、容错、零停机、易于监控等。我们不能简单地通过自动化手动过程和使用单一的“一劳永逸”工具来实现这一点。我们需要更深入的研究，开始在技术和过程层面重构整个系统。