devops工具_DevOps示例：DevOps文化的工具，优缺点

devops工具

There’s a number of steps between applications and websites being conceived and being finally released — design, programming, QA, and deployment. Let’s close the gap between the development and operations cycle, and review some of the practices of the DevOps movement.

构想并最终发布应用程序和网站之间有许多步骤-设计，编程，质量保证和部署。 让我们缩小开发和运营周期之间的差距，并回顾一下DevOps运动的一些实践。

常规软件开发：开发与运营 (Conventional Software Development: Dev vs Ops)

Traditionally, there are distinct teams and processes for the different states of a project, from the initial states of analysis and design (when a product or idea is conceived), to the actual development and testing (e.g. when code is being written or a product is being developed), to finally deployment and maintenance (e.g. when a website, application, or product goes live).

传统上，针对项目不同状态，从分析和设计的初始状态(构思产品或想法时)到实际开发和测试 (例如，编写代码或产品时)，都有不同的团队和流程。开发中)，以最终进行部署和维护 (例如，网站，应用程序或产品上线时)。

There’s good reason for this differentiation: they all demand a different set of skills. However, a strict (and at times even bureaucratic) separation of duties can add a lot of unnecessary delays, and experience proves that blurring some of these lines can be advantageous for all of the parties involved, and for the process as a whole.

进行这种区分的理由很充分：他们都需要一套不同的技能。 但是，严格的(有时甚至是官僚主义的)职责分离可能会增加许多不必要的延迟，而经验证明，模糊这些界限中的某些界限可能对所有相关方以及整个流程都有利。

This is true not only for software development, but for many industries. Think of Toyota, for example, the Japanese car manufacturer that’s had, for many years, a strong culture of reducing what they call “waste” from the production chain so that they could fasten the flow of changes from development into operations. Furthermore, Toyota’s practices have, in fact, heavily influenced the IT industry both in software development (see “lean software development“) and in DevOps (see “Kanban: from Toyota to DevOps?” and “Using the Toyota Production System to explain DevOps“).

这不仅适用于软件开发，而且适用于许多行业。 例如，以日本汽车制造商丰田公司为例，该公司多年来一直秉承减少生产链中所谓的“废物”的强烈文化，以便加快从开发到运营的变革流程。 此外，事实上，丰田的做法在软件开发(请参阅“ 精益软件开发 ”)和DevOps(请参阅“ 看板：从丰田到DevOps？ ”和“ 使用丰田生产系统来解释DevOps ”)中都对IT行业产生了重大影响。 ”)。

DevOps：文化变革的胜利 (DevOps: A Cultural Change for the Win)

DevOps as the intersection of development, operations and quality assurance. Image from Wikimedia, via Gary Stevens of HostingCanada.org.

DevOps是开发，运营和质量保证的交集。 图片来自Wikimedia ，由HostingCanada.org的 Gary Stevens提供。

Much like with agile development, DevOps isn’t a particular tool or technique that you can implement and you’re done. Rather, it’s a culture — even a mindset — that your team and organization can adopt and that will make processes smoother.

与敏捷开发很像，DevOps并不是您可以实现的特定工具或技术，但是您已经完成了。 而是，您的团队和组织可以采用这种文化，甚至可以是一种思维定式，可以使流程更加顺畅。

But what is it exactly? Think of developers being able to do some of the tasks that are normally assigned to system administrators, such as creating new servers, making updates to production sites, deploying apps. Also think of sysadmins sharing some duties with developers, and being able to manage multiple servers at once.

但是到底是什么呢？ 考虑开发人员能够执行通常分配给系统管理员的某些任务，例如创建新服务器，对生产站点进行更新，部署应用程序。 还可以想到系统管理员与开发人员分担一些职责，并且能够一次管理多台服务器。

好处 (Benefits)

Companies embracing a DevOps culture report significant improvements, and different surveys conducted among some of them seem to confirm these claims (see “Continuous Delivery: Huge Benefits, but Challenges Too“).

拥护DevOps文化的公司报告了重大改进，其中一些公司进行的不同调查似乎证实了这些主张(请参阅“ 持续交付：巨大的收益，但也面临挑战 ”)。

Some of the these improvements include:

其中的一些改进包括：

• Accelerated time-to-market: shorten the time it takes from when an idea is conceived until it’s available for sale or in production.

  加快上市时间：缩短从构思构思到将其出售或投入生产所需的时间。

• Building the right product: developers get faster feedback from users with more frequent releases and live testing of ideas (more on this later on the “A/B Testing” section).

  构建正确的产品 ：开发人员可以通过更频繁地发布和实时测试想法来从用户那里获得更快的反馈(有关更多信息，请参见“ A / B测试”部分)。

• Cost reduction: reports average a 20% reduction.

  降低成本 ：报告平均降低20％。

• Improved productivity: with continuous delivery, developers and testers save time setting up and fixing their working environments. Also, deployments are significantly faster (more on this later in the “Continuous Integration with Jenkins” section).

  更高的生产率 ：通过持续交付，开发人员和测试人员可以节省设置和修复工作环境的时间。 而且，部署速度明显更快(稍后在“与Jenkins的持续集成”部分中将对此进行详细介绍)。

• Reliable releases: with smaller and more frequent releases, the changes in code — and therefore the bugs introduced and their impact — are also smaller.

  可靠的发行版 ： 发行版较小且更频繁时，代码中的更改(因此引入的错误及其影响)也较小。

• Improved product quality: companies report a very significant reduction in open bugs and other issues (in some cases, by more than 90%).

  提高产品质量 ：公司报告显着减少了打开的错误和其他问题(在某些情况下，降低了90％以上)。

• Improved customer satisfaction: this is, not surprisingly, a byproduct of all of the previous improvements.

  更高的客户满意度 ：毫无疑问，这是以前所有改进的副产品。

例子 (Examples)

与Docker相同的生产和开发环境 (Same Production and Development Environments with Docker)

The conventional wisdom goes that one shouldn’t mix production with development environments — that these two should be carefully separated in order to avoid disasters. And while it’s true that making changes to a live platform without testing and rollback mechanisms is, in fact, a formula for disaster, having multiple environments comes at a high operational cost.

传统观点认为，不应将生产与开发环境混合在一起-应当将两者仔细分开以避免灾难。 而且，确实的是，无需测试和回滚机制即可对实时平台进行更改实际上是灾难的解决方案，但拥有多个环境会带来很高的运营成本。

Automating the creation of environments is key in DevOps, and one technology that enables this is Docker. We won’t get into the full details here, but the principle is that, with Docker, you can create a well-tested and functional environment (called an image) that developers and engineers in the operations side will be able to launch as software containers. Whenever an update or patch is required, the QA team will just patch the image, and the changes will be replicated in every new container that’s launched.

自动创建环境是DevOps的关键，而实现这一目标的一项技术就是Docker 。 我们不会在这里详细介绍所有细节，但是原理是，使用Docker，您可以创建一个经过良好测试的功能性环境(称为image )，操作方面的开发人员和工程师可以将其作为软件启动。 容器 。 每当需要更新或修补程序时，QA团队便会修补映像，更改将复制到启动的每个新容器中。

This gives independence to programmers and designers to launch environments that are constantly updated and known to work (and as many of them as they need), and even deploy changes to live platforms, because the QA people are maintaining these environments and have already set the appropriate tests. It also provides a communication channel with the server administrators, because they’re all basically working together in having a working environment that’s good for both production and development.

这使程序员和设计人员具有独立性，可以启动不断更新并已知可以正常工作的环境(以及所需的许多环境)，甚至可以将更改部署到实时平台上，因为质量检查人员正在维护这些环境并且已经设置了环境。适当的测试。 它还提供了与服务器管理员的沟通渠道，因为他们基本上都在一起工作，以提供一个既有利于生产又有利于开发的工作环境。

Notice that this is also valid if development and deployment are carried out by the same people — as in a single freelance developer — because these concerns for testing and implementing a live application in different environments are still valid regardless of who’s in charge of doing it.

请注意，如果开发和部署是由同一个人(如在一个自由开发人员中)进行的，那么这也是有效的，因为在不同环境中测试和实现实时应用程序的这些顾虑仍然有效，无论由谁来负责。

For more info about what you can do with Docker, see Understanding Docker, Containers and Safer Software Delivery.

有关您可以对Docker进行的操作的更多信息，请参阅了解Docker，容器和更安全的软件交付 。

A / B测试 (A/B Testing)

Wikipedia describes A/B testing as follows:

维基百科对 A / B测试的描述如下：

In marketing and business intelligence, A/B testing is a term for a randomized experiment with two variants, A and B, which are the control and variation in the controlled experiment.

在市场营销和商业智能中，A / B测试是具有两个变体A和B的随机实验的术语，这两个变体是受控实验中的对照和变异。

The principle is that you can test variants of an idea on live environments to make improvements in usability and other areas, based on popularity or users feedback. The reckless part is that you perform these tests with your actual audience — who are the ones best qualified for feedback anyway — which is something that Facebook, for example, does on a big scale to conduct social experiments. In the web dev field, think of experiments for testing landing pages with Google Analytics.

原则是您可以根据流行度或用户反馈在实时环境中测试某个想法的变体，以在可用性和其他方面进行改进。 鲁ck的部分是您与实际的受众(无论如何都是最有资格获得反馈的受众)一起执行这些测试，例如Facebook进行大规模的社交实验。 在网络开发人员领域，考虑使用Google Analytics(分析)测试登录页面的实验 。

How is all of this related to DevOps? Well, with automated deployment processes you give the parties involved — be they designers, developers, or even scientists with no background whatsoever in programming or engineering — the autonomy they need to conduct the experiments — again, with the safeguard mechanisms in place to test, pull or rollback changes.

所有这些与DevOps有什么关系？ 好吧，有了自动部署流程，您就可以让参与的各方(无论是设计人员，开发人员，甚至是没有编程或工程背景的科学家)都可以进行试验，这是他们进行实验所需的自主权，同时可以使用保护机制进行测试，拉或回滚更改。

与Jenkins的持续集成 (Continuous Integration with Jenkins)

Jenkins logo (wikimedia)

Jenkins徽标( Wikimedia )

Jenkins is a continuous integration (CI) and continuous delivery (CD) software — an orchestration system with hundreds of plugins to automate everything from building an application and testing it, to the final deployment. These plugins can integrate building software from source code platforms such as Git or Mercurial, to cloud services such as Amazon Web Services (AWS) or the Google Cloud Platform (GCP), passing through all of the scheduled tests. It is, essentially, a pipeline from source to delivery that’s becoming the engine of DevOps.

Jenkins是一个持续集成 (CI)和持续交付 (CD)软件-一个具有数百个插件的编排系统，可以自动完成从构建应用程序，测试应用程序到最终部署的所有过程。 这些插件可以通过所有计划的测试，将构建软件从源代码平台(如Git或Mercurial)集成到云服务(如Amazon Web Services(AWS)或Google Cloud Platform(GCP))。 从本质上讲，这是从源到交付的管道，它正在成为DevOps的引擎 。

Again, we see how everyone involved (developers, QA and sysadmins) work together on an effective and automated workflow:

再次，我们看到每个参与人员(开发人员，质量检查人员和系统管理员)如何在有效且自动化的工作流程中共同努力：

• Do developers need a new working environment? Jenkins will fire up Docker to launch it.

  开发人员需要新的工作环境吗？ Jenkins将启动Docker来启动它。

• Do sysadmins require a new QA test to pass before an update can go live? They just add it to the Jenkins pipeline.

  系统管理员是否需要通过新的QA测试才能使更新生效 ？ 他们只是将其添加到Jenkins管道中。

• Do developers want to pull changes to a production site and launch new servers with it? No problem: sysadmins have already instructed Jenkins what tests to run, and if everything goes fine, how to launch the servers.

  开发人员是否要将更改拉到生产站点并使用它启动新服务器 ？ 没问题：系统管理员已经指示Jenkins运行哪些测试，如果一切正常，则如何启动服务器。

As you can see, there’s a lot of automation in the process, and a fair amount of trust between the parties — all of which requires a lot of work to set up, but which, once in place, also gives everyone a lot of room to operate on their own.

如您所见，过程中有很多自动化，而且各方之间也有相当多的信任-所有这些都需要大量的工作来建立，但是一旦建立，它也为每个人提供了很大的空间自己经营。

挑战与失败 (Challenges and Fails)

Switching to a DevOps culture may bring a number of benefits, but it also comes with certain challenges to overcome.

切换到DevOps文化可能会带来很多好处，但同时也要克服一些挑战。

The first one is at an organization level. As development and deployment constraints are removed and programmers and sysadmins have more independence, the people involved will need to adopt a different mindset, and the appropriate mechanisms for a feedback loop from ops to dev will need to be set in place — such as issue trackers, boards of discussions (think of Slack), and the like.

第一个是在组织级别。 由于消除了开发和部署方面的限制，并且程序员和系统管理员具有更大的独立性，因此相关人员将需要采用不同的思维方式，并且需要建立从操作到开发的反馈循环的适当机制，例如问题跟踪程序。 ，讨论区(例如Slack )等。

The second key challenge is regarding processes. You no longer want developers and server administrators themselves using their time to individually test after changes. What you’ll want is to automate the testing processes, so that you can allow different teams to make changes and quickly check that things are still in place, and reverse those changes should problems arise.

第二个关键挑战是关于流程 。 您不再希望开发人员和服务器管理员自己花费时间来进行更改后的单独测试。 您想要的是使测试过程自动化，以便您可以允许不同的团队进行更改并快速检查一切是否仍在进行中，并在出现问题时撤消这些更改。

Finally, there’s a technology challenge. As mentioned, once your organization has carefully reviewed the processes from end to end, you may need either to adopt or create a technology that addresses the kind of automation and feedback loop that better suits your processes and organization.

最后，存在技术挑战。 如前所述，一旦您的组织从头到尾仔细审查了流程，您可能需要采用或创建一种技术，以解决更适合您的流程和组织的自动化和反馈回路。

It isn’t trivial: you can’t simply copy/paste the processes and technologies others are using. These issues need to be addressed individually, and there has to be a fair level of trust between the parties involved.

这并不简单： 您不能简单地复制/粘贴其他人正在使用的过程和技术。 这些问题需要单独解决，有关各方之间必须有一个公平的信任水平。

As Dave Roberts comments in “Why ‘Enterprise DevOps’ Doesn’t Make Sense“:

正如戴夫·罗伯茨(Dave Roberts)在“ 为什么'Enterprise DevOps'没道理 ”中的评论：

The key is to understand that simply deploying a tool or even a broad solution without thinking through your unique situation and the current state of your value stream and its current constraints is foolish.

关键是要了解，仅部署工具甚至是广泛的解决方案，而无需考虑自己的独特情况 ，价值流的当前状态及其当前约束是愚蠢的。

回顾 (Recap)

It’s not about the Apps. You can use tools such as Docker, Jenkins, Kanban and yet never be doing any actual DevOps if you can’t rely on the people at the other side of your chain.

与Apps无关 。 您可以使用诸如Docker，Jenkins，Kanban之类的工具，但是如果您不能依靠链另一端的人，则永远不会做任何实际的DevOps。

In contrast, you can go without these tools and instead implement your own solutions and set a chain of QA that suits you or your organization. And if you’re having a fluent communication with the colleagues from different teams, and even temporarily do some of their tasks yourself when you need to — trusting that they can to do same because you already have in place everything necessary to reverse changes — then you’re making a cultural shift that very much sounds like DevOps.

相反，您可以不使用这些工具，而是实施自己的解决方案，并设置适合您或您的组织的质量检查链。 而且，如果您与不同团队的同事进行了流利的沟通，甚至在需要时自己临时完成一些任务-相信他们可以做到，因为您已经准备好了所有必要的变更更改-那么您正在进行文化上的转变，听起来像是DevOps。

The benefits ahead may very well be worth the effort.

未来的收益很值得努力。

翻译自: https://www.sitepoint.com/devops-by-example-tools-pros-and-cons-of-a-devops-culture/

devops工具