正在开发中的Linux 5.10
|
#2：未将配置外部化的容器 在很多情况下，容器化都是一项了不起的技术。但是，它带有价值标签，可能会影响您的生产率。从安全角度以及通过必要的配置和环境管理等方面来看，容器会增加开销。如果您不同意团队的某些约定，那么容器也会损害您的生产力和开发人员的经验。 我看到的最常见的错误是：将配置文件或环境变量构建到容器中。容器化的核心思想是可移植性。通过硬编码配置，您将必须开始为每个单个环境编写文件和管道。您要更改URL吗?很好，请继续在20个不同的地方进行更改，然后重新构建所有内容。 在开始大规模使用和在生产环境中使用容器之前，请先坐下并同意对您重要的配置约定。确保在代码审查和回顾中始终如一地介绍这一点。重构这种体验是一种痛苦。 #3：错误地采用KUBERNETES 所有人都对这个名为Kubernetes的开源项目大肆宣传。但是，Kubernetes很难保持运行，也很难集成到您的开发人员流程中，同时又要保持较高的生产率和经验。很多事情都会出错： Kubernetes最坏的情况：XY同事真的很想弄脏他的手，并在线找到了入门指南。他们在裸机上建立了一个集群，它与该测试应用程序一起很好地工作。然后，他们开始迁移第一个应用程序，并要求其同事开始使用kubectl与集群进行交互。现在，团队的一半专注于学习这项新技术。现在，正在维护集群的可怜人将在第二个生产工作负荷达到第一的时候全职工作。CI/CD的设置完全没有做好应对这些的准备，并且由于整个团队都在尝试掌握Kubernetes，因此总体生产率正在下降。 可以做些什么来防止这种情况： Kubernetes是一项很棒的技术，如果做得正确，可以帮助获得类似于PaaS的开发人员体验。毕竟，它是Borg的后代。Borg是Google构建的平台，可让其软件工程师轻松构建可大规模扩展的应用程序。因此，它是对Google内部平台的一种开源解释。 最佳做法： 团队尽可能不要自己建立和运行准系统群集，而应使用托管的Kubernetes服务。阅读有关托管Kubernetes集群最适合您的需求的评论。在我撰写本文时，从纯粹的技术角度来看，谷歌Kubernetes引擎(GKE)到目前为止是最好的(尽管权限架构仍然很痛苦–权限问题，谷歌?)紧随其后的是Azure Kubernetes Service( AKS)。亚马逊的Elastic Kubernetes服务(Amazon EKS)并正在追赶。 使用自动化平台或持续交付API。它们使您可以在开发人员看不见的情况下在K8上运行工作负载。使所有人都暴露于整个设置的复杂性几乎为零。我知道“每个人都应该能够做所有事情”的论点，但是变革的步伐是如此之快，而且自动化管理的程度如此之高，以至于这确实没有道理。 如果团队真的希望开发人员自己管理Kubernetes集群，那么他们应该给他们足够的时间来真正了解架构，设计模式，kubectl等，并真正专注于此。 #4：忘记做持续交付 “等等，我已经有一个配置项工具”。常见的误解是，如果有持续集成设置，则工作做得很好。您仍然缺少连续交付!许多供应商创造了“ CI/CD工具”一词，这并没有给您带来困惑，如果您拥有Jenkins，CircleCI等，则给您留下了连续交付的印象-事实并非如此。 经过精心调整的“持续交付”设置(无论是自行编写的还是“即服务”的设置)，更是团队工具链中的“粘合剂”： 它使从源代码控制系统到CI-Pipeline，从数据库到群集以及从DNS设置到IaC的所有不同组件都可以集成到简化的便捷开发人员体验中。 这是一种结构，维护和管理数量不断增长的yml和配置脚本的方法。如果做得好，这将使您的开发人员可以利用CI-Pipeline构建的工件动态地启动环境，并通过预配置的数据库和已设置的一切进行全面配置。 它可以用作配置状态的版本控制系统，并具有可审核的记录，以记录部署在何处，以何种配置运行，并允许您来回滚动以及管理蓝/绿/金丝雀的部署。 通过精心设计的CD设置，可以改变开发人员的工作效率。它们使开发人员能够自助服务，减少了团队内部的依赖，同时提高了设置的可维护性。
使用这些做法的团队会更频繁，更快地发布，表现出总体上更高的绩效和满意度。 （编辑：常州站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
