Java持续交付

其他的指导和提示

｜

365

其他的指导和提示

关于如何推广持续交付的经验我们可以单独写一本书，但是也经常会面临一些挑战，例

如如何处理常见的不良实践和丑陋的架构。

不良实践和常见的反模式

在本章中，我们已经多次提到在组织内实施持续交付是一个复杂的过程，许多良好的实

践都跟使用场景有关，但是一些不良的实践却可能出现在任何地方。如果你能够了解这

些不良实践，就能够避免它们 ：

y

在持续交付的概念验证阶段，过于雄心勃勃地选择（或者扩张）某个功能。

y

尝试在一个全新、创新的功能上实现持续交付。虽然也可以用来进行

CD

实验，

但如果新功能没有良好的设计，或者在组织中没有资源的支持，就可能会导致长

时间的延期。

y

在技术栈中引入了太多新技术，例如，从在内部托管的应用服务器上部署一个

EAR

文件，到在公有云的

Kubernetes

容器中部署

Fat JAR

应用程序。

y

以破坏性的方式改变架构，同时又试图为应用程序建立一个构建管道，例如，将

应用程序从一个单体

WAR

文件的部署方式，拆分为

10

个微服务进行部署和编排。

y

过分依赖外部顾问或者供应商。虽然外部顾问和供应商可以为迁移带来很多价值

（提供急需的专业知识），但最后的迁移过程必须由内部团队来负责。

y

简单地将当前手动操作自动化。这可能是一个很好的起点，但是你必须确保每个

手动操作都是有效的和必要的。自动化意味着你可能会更快、更频繁地出错，造

成比以前更大的损失！

y

不承认遗留系统中存在的限制或者紧耦合。

y

不了解当前组织结构不适合于持续交付（例如，政治文化严重或者不尊重康威定 ...