本地构建和自动化构建_构建自动化面板

本地构建和自动化构建

上周二，我作为持续讨论（＃c9d9）的一部分，参加了一个关于Build Automation主题的在线讨论会，这是一系列有关敏捷，持续交付和DevOps的社区讨论会。自动化构建流程面临许多挑战，包括第三方依赖关系，构建版本管理，尤其是文化，小组成员讨论了解决这些挑战的现实经验。

持续讨论是Electric Cloud的一项社区计划，该计划通过自动化其构建，测试和部署流程来推动SpaceX，Cisco，GE和E * TRADE等企业的持续交付。

以下是我对面板所做的贡献。

构建瓶颈对您的管道意味着什么？

以我的经验，瓶颈通常与软件架构有关，而与工具和团队无关。我认为大多数人还没有准备好以可以快速，轻松地构建，测试和部署软件的方式来设计软件。

我们需要开始将事情分解成非常小的部分。这是消除瓶颈的最简单方法。大是坏，小是好。如果我们想要快速交付而没有停机时间，并且能够在出现问题时回滚，并且如果我们想经常这样做，那么我们就需要以一种可以立即交付更改内容而不是整个系统的方式来设计软件。 Docker的微服务和容器打开了新的大门，直到最近我们才对我们大多数人关闭。

长期以来，我们试图围绕整体架构构建管道，现在是时候以支持持续交付的方式开始构建架构。

有哪些常见问题？

问题是有团队，但没有个人责任。 Docker和微服务改变了世界，这使我有可能对我所做的一切负全部责任，而不是将其传递给运营商，测试人员和其他团队。当将其传递给其他团队时，DevOps的工作只是确保构建了存储库并且该构建已投入生产。 DevOps不会决定要构建什么或如何构建。他们只是将一切推向生产。这很困难，因为出了问题，人们就不再承担责任。为了解决此问题，我们需要将软件分解为小单元。

许多组织正在转向微服务。当一切都变小时，可以每天进行部署。只要您的架构不会阻止它，并且只要您的团队有能力完成这项工作即可。如果您需要依靠他人来完成工作，那么就会遇到瓶颈。

我们需要力量掌握在开发人员手中。该组织的所有其他成员应支持发展。一旦我们改变了这种文化，事情就会变得更加顺利，运行得更快。

您如何看待流程的一致性和标准化？

如果标准化不是最大的创新杀手，那将是很棒的。标准化后，您将陷入困境多年。

对于尝试新方法的人们来说，我认为没有任何问题，特别是如果您将应用程序分解成小块的话。您只需很少的代码就可以在系统的一小部分进行尝试。学习起来并不难。在我曾任职的任何组织中，标准化程度越高，变更和创新的引入就越少。以我的经验，标准化与创新成反比。

一些标准化很重要，尤其是关于如何从外部接收通信时。但是在团队中，假设团队规模合理，没有人比团队本身更适合决定团队的工作方式。

无论我们在做什么，我们都必须在有关组件之间通信的合同上非常严格。但是我开发的组件内部发生的一切都是我的问题，只要没有外界的干扰太多，我就可以以最好的方式解决它。”

翻译自: https://www.javacodegeeks.com/2015/05/build-automation-panel.html

本地构建和自动化构建