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

devops工具

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 exactlyThink 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)

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 environmentJenkins will fire up Docker to launch it.

开发人员需要新的工作环境吗Jenkins将启动Docker来启动它。
Do sysadmins require a new QA test to pass before an update can go liveThey just add it to the Jenkins pipeline.

系统管理员是否需要通过新的QA测试才能使更新生效 他们只是将其添加到Jenkins管道中。
Do developers want to pull changes to a production site and launch new servers with itNo 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/