document/TranslateProject
2
0
Fork 0
mirror of https://github.com/LCTT/TranslateProject.git synced 2025-01-01 21:50:13 +08:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #8759 from wxy/20171129-5-best-practices-for-getting-started-with-DevOps

Browse Source 
PRF&PUB:20171129 5 best practices for getting started with DevOps
This commit is contained in:
Xingyu.Wang 2018-05-13 07:49:37 +08:00 committed by GitHub
commit 0e2b61f0c0
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 21 additions and 21 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

42
translated/tech/20171129 5 best practices for getting started with DevOps.md → published/20171129 5 best practices for getting started with DevOps.md
View File

@ -1,55 +1,55 @@
5 个最佳实践开始你的 DevOps 之旅
============================================================
### 想要实现 DevOps 但是不知道如何开始吗？试试这 5 个最佳实践吧。
> 想要实现 DevOps 但是不知道如何开始吗？试试这 5 个最佳实践吧。
![5 best practices for getting started with DevOps](https://opensource.com/sites/default/files/styles/image-full-size/public/lead-images/devops-gears.png?itok=rUejbLQX "5 best practices for getting started with DevOps")
Image by : [Andrew Magill][8]. Modified by Opensource.com. [CC BY 4.0][9]
想要采用 DevOps 的人通常会过早的被它的歧义性给吓跑，更不要说更加深入的使用了。当一些人开始使用 DevOps 的时候都会问：“如何开始使用呢？”，”怎么才算使用了呢？“。这 5 个最佳实践是很好的路线图来指导你的 DevOps 之旅。
想要采用 DevOps 的人通常会过早的被它的歧义性给吓跑，更不要说更加深入的使用了。当一些人开始使用 DevOps 的时候都会问：“如何开始使用呢？”，”怎么才算使用了呢？“。这 5 个最佳实践是指导你的 DevOps 之旅的很好的路线图。
### 1\. 衡量所有的事情
### 1、 衡量所有的事情
除非你能量化输出结果，否则你并不能确认你的努力能否使事情变得更好。新功能能否快速的输出给客户？有更少的漏洞泄漏给他们吗？出错了能快速应对和恢复吗？
除非你能够量化输出结果，否则你并不能确认你的努力能否使事情变得更好。新功能能否快速的输出给客户？带给他们的缺陷更少吗？出错了能快速应对和恢复吗？
在你开始做任何修改之前，思考一下你切换到 DevOps 之后想要一些什么样的输出。随着你的 DevOps 之旅，将享受到服务的所有内容的丰富的实时报告，从这两个指标考虑一下：
* **上架时间** 衡量端到端，通常是面向客户的业务经验。这通常从一个功能被正式提出而开始，客户在产品中开始使用这个功能而结束。上架时间不是团队的主要指标；更加重要的是，当开发出一个有价值的新功能时，它表明了你完成业务的效率，为系统改进提供了一个机会。
* **上架时间** 衡量端到端，通常是面向客户的业务经验。这通常从一个功能被正式提出而开始，客户在产品中开始使用这个功能而结束。上架时间不是工程团队的主要指标；更加重要的是，当开发出一个有价值的新功能时，它表明了你完成业务的效率，为系统改进提供了一个机会。
* **时间周期** 衡量工程团队的进度。从开始开发一个新功能开始，到在产品中运行需要多久？这个指标对于你理解团队的效率是非常有用的，为团队等级的提升提供了一个机会。
* **时间周期** 衡量工程团队的进度。从开始开发一个新功能开始，到在产品环境中运行需要多久？这个指标对于你了解团队的效率是非常有用的，为团队层面的提升提供了一个机会。
### 2\. 放飞你的流程
### 2、 放飞你的流程
DevOps 的成功需要团队布置一个定期流程并且持续提升它。这不总是有效的，但是必须是一个定期（希望有效）的流程。通常它有一些敏捷开发的味道，就像 Scrum 或者 Scrumban 一样；一些时候它也像精益开发。不论你用的什么方法，挑选一个正式的流程，开始使用它，并且做好这些基础。
DevOps 的成功需要团队布置一个定期（但愿有效）流程并且持续提升它。这不总是有效的，但是必须是一个定期的流程。通常它有一些敏捷开发的味道，就像 Scrum 或者 Scrumban 一样；一些时候它也像精益开发。不论你用的什么方法，挑选一个正式的流程，开始使用它，并且做好这些基础。
定期检查和调整流程是 DevOps 成功的关键，抓住相关演示，团队回顾，每日会议的机会来提升你的流程。
定期检查和调整流程是 DevOps 成功的关键，抓住相关演示、团队回顾、每日会议的机会来提升你的流程。
DevOps 的成功取决于大家一起有效的工作。团队的成员需要在一个有权改进的公共流程中工作。他们也需要定期找机会分享从这个流程中上游或下游的其他人那里学到的东西。
随着你构建成功。好的流程规范能帮助你的团队以很快的速度体会到 DevOps 其他的好处
随着你构建成功，好的流程规范能帮助你的团队以很快的速度体会到 DevOps 其他的好处
尽管更多面向开发的团队采用 Scrum 是常见的，但是以运营为中心的团队（或者其他中断驱动的团队）可能选用一个更短期的流程，例如 Kanban。
### 3\. 可视化工作流程
### 3、 可视化工作流程
这是很强大的，能够看到哪个人在给定的时间做哪一部分工作，可视化你的工作流程能帮助大家知道接下来应该做什么，流程中有多少工作以及流程中的瓶颈在哪里。
在你看到和衡量之前你并不能有效的限制流程中的工作。同样的，你也不能有效的排除瓶颈直到你清楚的看到它。
全部工作可视化能帮助团队中的成员了解他们在整个工作中的贡献。这样可以促进跨组织边界的关系建设，帮助您的团队更有效地协作，实现共同的成就感。
### 4\. 持续化所有的事情
### 4、 持续化所有的事情
DevOps 应该是强制自动化的。然而罗马不是一日建成的。你应该注意的第一个事情应该是努力的持续集成（CI），但是不要停留到这里；紧接着的是持续交付（CD）以及最终的持续部署。
DevOps 应该是强制自动化的。然而罗马不是一日建成的。你应该注意的第一个事情应该是努力的[持续集成（CI）][10]，但是不要停留到这里；紧接着的是[持续交付（CD）][11]以及最终的持续部署。
持续部署的过程中是个注入自动测试的好时机。这个时候新代码刚被提交，你的持续部署应该运行测试代码来测试你的代码和构建成功的加工品。这个加工品经受流程的考验被产出直到最终被客户看到。
持续部署的过程中是个注入自动测试的好时机。这个时候新代码刚被提交，你的持续部署应该运行测试代码来测试你的代码和构建成功的加工品。这个加工品经受流程的考验被产出，直到最终被客户看到。
另一个“持续”是不太引人注意的持续改进。一个简单的场景是每天询问你旁边的同事：“今天做些什么能使工作变得更好？”，随着时间的推移，这些日常的小改进融合到一起会引起很大的结果，你将很惊喜！但是这也会让人一直思考着如何改进。
另一个“持续”是不太引人注意的持续改进。一个简单的场景是每天询问你旁边的同事：“今天做些什么能使工作变得更好？”，随着时间的推移，这些日常的小改进融合到一起会带来很大的结果，你将很惊喜！但是这也会让人一直思考着如何改进。
### 5\. Gherkinize
### 5、 Gherkinize
促进组织间更有效的沟通对于成功的 DevOps 的系统思想至关重要。在程序员和业务员之间直接使用共享语言来描述新功能的需求文档对于沟通是个好办法。一个好的产品经理能在一天内学会 [Gherkin][12] 然后使用它构造出明确的英语来描述需求文档，工程师会使用 Gherkin 描述的需求文档来写功能测试，之后开发功能代码直到代码通过测试。这是一个简化的 [验收测试驱动开发][13](ATDD)，这样就开始了你的 DevOps 文化和开发实践。
促进组织间更有效的沟通对于成功的 DevOps 的系统思想至关重要。在程序员和业务员之间直接使用共享语言来描述新功能的需求文档对于沟通是个好办法。一个好的产品经理能在一天内学会 [Gherkin][12] 然后使用它以平实的英语构造出明确的描述需求文档，工程师会使用 Gherkin 描述的需求文档来写功能测试，之后开发功能代码直到代码通过测试。这是一个简化的 [验收测试驱动开发][13](ATDD)，能够帮助你开始你的 DevOps 文化和开发实践。
### 开始你旅程
@ -60,15 +60,15 @@ DevOps 应该是强制自动化的。然而罗马不是一日建成的。你应
[![](https://opensource.com/sites/default/files/styles/profile_pictures/public/pictures/headshot_4.jpg?itok=jntfDCfX)][14]
Magnus Hedemark - Magnus 在IT行业已有20多年，并且一直热衷于技术。他目前是 nitedHealth Group 的 DevOps 工程师。在业余时间，Magnus 喜欢摄影和划独木舟。
Magnus Hedemark - Magnus 在 IT 行业已有 20 多年，并且一直热衷于技术。他目前是 nitedHealth Group 的 DevOps 工程师。在业余时间，Magnus 喜欢摄影和划独木舟。
--------------------------------------------------------------------------------
via: https://opensource.com/article/17/11/5-keys-get-started-devops
作者：[Magnus Hedemark ][a]
作者：[Magnus Hedemark][a]
译者：[aiwhj](https://github.com/aiwhj)
校对：[校对者ID](https://github.com/校对者ID)
校对：[wxy](https://github.com/wxy)
本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创编译，[Linux中国](https://linux.cn/) 荣誉推出