有关开发人员如何通过构建日常工作来降低生产力的文章很多。一个常见的例子是全天安排了太多不必要的会议，以至于没有人可以进入深度专注模式。今天，我想研究一下最大的开发人员生产力杀手：配置和设置DevOps工作流的方式。在几乎所有情况下，我都会遇到一些可以帮助您避免大多数问题的捷径。#1：在没有适当工具的情况下全面使用微服务当一个项目在单体设置中运行时，所有的工作都可以完成。工具链已准备好很好地处理这个整体，但是，要更改一小部分，需要部署整个整体。需要运行端到端测试以验证一切仍在运行。整体越大，效率越低。因此，该团队继续采用微服务。他们的第一次体验很好，同事们可以独立完成个人服务，部署频率提高，大家都很开心。当团队不使用微服务并且过于重视“微”时，问题就开始了。从工具的角度来看，您现在将不得不处理更多的yml文件、docker文件以及这些服务的变量之间的依赖关系、路由问题等。它们需要更新和维护。您的CI/CD设置、组织结构和员工人数可能需要重新调整。如果您出于任何原因进入微服务，请确保您计划足够的时间来重组您的工具设置和工作流程。只需计算每个位置需要维护的脚本数量即可。考虑这需要多长时间，谁负责，以及哪些工具可以帮助您管理它。如果您选择一种工具，请确保他们拥有一个用户社区。#2：不外部化配置的容器容器化在许多情况下是一项了不起的技术。但是，它带有一个可能会影响您的工作效率的价值标签。容器增加了开销，无论是从安全角度还是通过必要的配置和环境管理。如果您不同意团队的某些约定，容器也会损害您的生产力和开发人员体验。我看到的最常见的错误是：将配置文件或环境变量构建到容器中。容器化的核心思想是可移植性。使用硬编码配置，您将不得不开始为每个单独的环境编写文件和管道。您要更改URL吗？好吧，继续吧，在20个不同的地方进行更改并重建所有内容。在开始大规模和生产中使用容器之前，请坐下来同意对您很重要的配置约定。确保在代码审查和回顾中始终如一地涵盖这一点。重构这种体验是一种痛苦。#3：误用KUBERNETES所有关于这个名为Kubernetes的开源项目的炒作。然而，Kubernetes很难在保持高生产力和体验的同时保持运行并集成到您的开发人员流程中。很多事情都可能出错：Kubernetes最坏的情况：同事XY真的很想亲自动手，并在网上找到了入门指南。他们在裸机上设置了一个集群，它在这个测试应用程序中运行良好。然后他们开始迁移第一个应用程序，并要求他们的同事开始使用kubectl与集群进行交互。现在，一半的团队专注于学习新技术。现在，维护集群的可怜人将在第一个出现时全职处理第二个生产工作负载。CI/CD设置对此完全没有准备，并且随着整个团队试图掌握Kubernetes，整体生产力正在下降。可以采取什么措施来防止这种情况发生：Kubernetes是一项伟大的技术，如果使用得当，它可以帮助实现类似PaaS的开发人员体验。毕竟是博格人的后裔。Borg是Google构建的平台，旨在让其软件工程师轻松构建可大规模扩展的应用程序。因此，它是对Google内部平台的开源解释。最佳实践：只要有可能，团队应该避免自己设置和运行准系统集群，而是使用托管的Kubernetes服务。阅读有关哪种托管Kubernetes集群最适合您的需求的评论。在我撰写本文时，从纯粹的技术角度来看，谷歌Kubernetes引擎(GKE)是迄今为止最好的（尽管权限架构仍然是一个痛苦——权限问题，谷歌？）紧随其后的是AzureKubernetes服务(AKS)。Amazon的ElasticKubernetesService(AmazonEKS)正在迎头赶上。使用自动化平台或持续交付API。它们允许您在开发人员不可见的K8s上运行工作负载。让每个人都接触到整个设置的复杂性几乎为零。我知道“每个人都应该能够做所有事情”的论点，但变化的速度如此之快，而且自动化水平得到控制，这真的没有意义。如果团队真的想让开发者自己管理Kubernetes集群，就应该给他们足够的时间去真正理解架构、设计模式、kubectl等，并真正专注于此。#4：忘记做持续交付“等一下，我已经有了一个配置项工具”。一个常见的误解是，如果你有一个持续集成设置，你就做得很好。您仍然缺少持续交付！许多供应商创造了术语“CI/CD工具”，这不会让您感到困惑，如果您有Jenkins、CircleCI等，您就会对持续交付产生印象——但事实并非如此。一个调整良好的“持续交付”设置（无论是自写的还是“即服务”）是团队工具链中的“粘合剂”：它支持从源代码控制系统到CI-Pipeline的一切，从所有从数据库到集群，从DNS设置到IaC的不同组件都可以集成到简化和方便的开发人员体验中。这是一种构建、维护和管理越来越多的yml和配置脚本的方法。做得好，这将允许您的开发人员利用CI-Pipeline构建的工件来动态启动环境，完全配备预配置的数据库和已经设置的一切。它可以用作配置状态的版本控制系统，具有部署位置、运行配置的可审计记录，并允许您来回回滚以及管理蓝/绿/金丝雀部署。通过精心设计的CD设置，可以改变开发人员的生产力。它们使开发人员能够自助服务，减少团队内部的依赖性，同时提高设置的可维护性。使用这些实践的团队发布得更频繁、更快，总体上表现出更高的绩效和满意度。#5：不可持续的测试自动化没有自动化就不可能进行有效的测试。持续交付带来了不破坏任何东西的持续责任。您需要不断确保自己不会落入倒置测试金字塔的陷阱。为此，您需要能够在开发生命周期的正确时间点运行正确的测试。适当的CI工具将帮助您将单元和集成测试放在正确的位置，而具有配置管理和环境管理的CD工具将帮助您以可靠的方式运行自动化的端到端测试。良好的设置允许开发人员或测试人员动态地启动预配置的环境。严格外部化您的配置，并确保您拥有在部署时注入这些变量的配置管理。这导致了许多积极的改进：在正确的时间运行正确的测试，同时向开发团队提供有效的反馈开发人员获得自主权，你减少了对关键人员的依赖，QA现在可以通过功能环境测试子集，QA可以并行测试，这在测试数据子集时节省时间。#6：自己管理数据库刚刚离开的一位队友负责为客户项目设置MongoDB，当然还使用开源项目自己运行它。当然，切换是“完美的”，当然数据库没有得到适当的保护，一天晚上它显示了数据应该在哪里：当然：你检查你的备份。出现语法错误。现在，您必须对所有数据进行逆向工程。这是一个经常发生的真实例子。自我管理的数据库存在操作和安全风险。它们令人分心、无聊且不必要。使用CloudSQL之类的东西，睡个好觉。我们通常会看到Aiven.io等公司提供的托管服务。这些公司提供大多数数据库，他们为您在所有大型云提供商上运行它们，并且它们具有更多功能、更成熟和更复杂。此外，它们通常更便宜并确保零锁定，同时为开发人员提供更多便利，如果它是并驾齐驱，我一直想要。#7：无缘无故地采用多云是仅使用多云与尝试将系统设计为不可知和可移植的区别。后者具有许多不同的优势，例如动态环境，并且比使用多云更有意义。当然，这有一个遗留问题：一些团队一直在使用GCP，而其他团队则从AWS开始，现在就在这里。其他包括专业化。有人可能会争辩说，GPU在GCP上比在AWS上运行效率更高，或者出于成本原因。但要真正浮出水面，你需要一个合适的尺寸。简单的多云设置需要高度自动化，并屏蔽开发人员的配置和设置任务。否则，您将陷入脚本地狱。作为一般规则：如果不是绝对必要，请不要使用多云。结论我希望这些要点可以帮助您避免在该领域犯下最大的错误。请记住NicoleForsgren、JezHumble和GeneKim在他们的《加速》一书中写道：“前1%的团队出货频率提高10倍。”这是因为他们正在充分利用当今可用的一切。我每个月花1小时查看我的个人工作流程、待办事项列表以及我如何组织我的应用程序。为什么？因为如果你的流程效率低下，它可能会在数周内累加起来。这些微小的事情，比如搜索你的照片应用程序会分散你的大脑。每个月停下来花一个下午来确保您的工作效率得到提高。这将帮助您专注于创新而不是配置，从而使团队更快乐。
