DevOps are getting more and more popular for a reason. They enable a quick, secure and reliable way of developing, testing and shipping new features to the customers, so no wonder that many companies can’t imagine life without them. That’s why we have decided to investigate the topic and prepare a lightweight summary that will help non-technical audiences understand the concept and tools used in the process as well as highlight potential investment opportunities for us — the Venture Capital investors.
由于某种原因，DevOps越来越受欢迎。 它们为开发，测试和向客户交付新功能提供了一种快速，安全和可靠的方式，因此，难怪许多公司无法想象没有它们的生活。 因此，我们决定调查此主题并准备一个简短的摘要，以帮助非技术受众了解该过程中使用的概念和工具，并为我们(风险资本投资者)强调潜在的投资机会。
DevOps革命 (DevOps revolution)
The DevOps movement gained momentum in 2018, but it had its beginnings around 2009 when John Allspaw and Paul Hammond from Flickr presented how Dev and Ops can cooperate to deliver 10+ deploys per day (deployed code is the code shipped to the customers). According to a survey from 2017 DevOps is becoming the norm. Roughly 2 years ago almost 50% of companies had DevOps implemented to some extent and the next 30% was planning to follow suit.
DevOps运动在2018年获得发展势头，但它始于2009年左右，当时Flickr的John Allspaw和Paul Hammond介绍了Dev和Ops如何合作以每天交付10多个部署 (部署的代码是交付给客户的代码)。 根据2017年的一项调查 ，DevOps正在成为常态。 大约2年前，近50％的公司已在一定程度上实施了DevOps，接下来的30％的公司计划效仿。
The best and biggest companies such as Netflix, Amazon, Facebook, CD Projekt, Ikea or Lego, have DevOps engineers in their ranks, but you can also spot dozens of them at startups like Revolut, Docplanner, Booksy, or Brainly.
Netflix，亚马逊，Facebook，CD Projekt，宜家或Lego等最好，最大的公司都拥有DevOps工程师，但您也可以在Revolut，Docplanner，Booksy或Brainly等初创公司中找到很多。
但是DevOps到底是什么？ (But what exactly is DevOps?)
Developers (Devs) build & ship features as quickly as possible while the IT Operations (Ops) deploy code from Devs and make sure systems never go down and fix them if they do so. Before DevOps, there was a conflict of interest because Ops were protecting the stability of systems, and they didn’t welcome changes made by Developers with open arms as they were constantly bringing instability.
开发人员(Devs)尽可能快地构建和发布功能，而IT运营(Ops)则从Devs部署代码，并确保系统永远不会宕机并对其进行修复。 在DevOps之前，存在利益冲突，因为Ops在保护系统的稳定性，并且他们不欢迎开发人员张开双臂进行更改，因为它们不断带来不稳定。
After DevOps was introduced the conflict still exists, but now the relationship between these two parties is much more productive. But going back to the main question: the ultimate goal of DevOps is to build digital pipelines taking code from the Developer and shipping it to customers in an automated, reliable and secure way. DevOps is what you get when you take Devs and make them do Ops. They repeatedly automate themselves out of their (current) job by building tools that replace previously manual processes. It wasn’t possible for Ops, who usually don’t have enough coding experience.
在引入DevOps之后，冲突仍然存在，但是现在这两方之间的关系更加富有成效。 但是回到主要问题：DevOps的最终目标是建立从开发人员那里获取代码并以自动化，可靠和安全的方式将其交付给客户的数字管道。 DevOps是您获得Devs并让他们执行Ops时所获得的。 他们通过构建替代以前的手动流程的工具，使自己从当前(当前)工作中反复自动化。 对于Ops来说是不可能的，他们通常没有足够的编码经验。
DevOps的简短故事 (Brief story of DevOps)
Long time ago IT companies used to have servers in their basements and System Administrators (IT Operations) had to configure them by hand. At the beginning it was manageable as you had 1 or 2 servers only, but over time you needed more and more of them and you started to experience troubles. Servers had different configurations and it was causing unexpected errors that were difficult to resolve as you had to check manually each of the servers to find out how they were configured. And time was money — each hour of outage can be measured in thousands of USD lost.
很久以前，IT公司曾经在其地下室安装了服务器，而系统管理员(IT运营)则必须手动配置它们。 最初，它只有1或2台服务器，这是可管理的，但是随着时间的流逝，您需要越来越多的服务器，并且开始遇到麻烦。 服务器具有不同的配置，并导致难以解决的意外错误，因为您必须手动检查每台服务器以了解它们的配置方式。 时间就是金钱–停机的每一小时都可以用数千美元的损失来衡量。
At some point tools used in the Development department were slowly introduced to the Operations e.g. Version Control Systems. After some time it was possible to define the target state of the infrastructure as a code (IaaC) and from now on Ops were aware of what’s going on at any time, what were the changes, and who did them. It made scaling of your infrastructure much easier, because thanks to IaaC you can simply copy-paste the servers’ configurations instead of setting up everything manually step by step. It also enabled testing of the infrastructure configuration before it was deployed, which decreased downtime. Less manual work resulting from automation means that the deployments can be more frequent, so the code can be tested in smaller batches, the bugs can be found quicker, and the features to the customers can be shipped faster. In short, we can say that DevOps is the application of Dev methodologies to Ops work, and it’s getting more and more common.
在某些时候，开发部门使用的工具逐渐引入了运营部门，例如版本控制系统。 一段时间后，可以将基础结构的目标状态定义为代码(IaaC)，从那时起，Ops会随时了解发生了什么，发生了哪些更改以及由谁进行了更改。 它使基础架构的扩展变得更加容易，因为有了IaaC，您可以简单地复制粘贴服务器的配置，而不必一步一步地手动设置所有内容。 它还可以在部署基础结构之前对其进行测试，从而减少了停机时间。 自动化导致的手动工作量减少，意味着部署可能更加频繁，因此可以以较小的批次进行测试，可以更快地发现错误，并可以更快地向客户交付功能。 简而言之，我们可以说DevOps是Dev方法论在Ops工作中的应用，并且它变得越来越普遍。
The time it takes to go from code submitted by a developer as a ready to the moment when customers see it in their product (deploy lead time) is probably the best metric to assess a company’s maturity in terms of DevOps adoption and the top companies are able to do it in minutes, while it still takes months for laggards.
从开发人员提交的代码到准备就绪，直到客户在其产品中看到它的时间 ( 部署提前期)，这可能是评估公司在DevOps采用率方面的成熟度的最佳指标，而顶级公司则是可以在几分钟内完成，而落后者仍需要数月。
Shorter deploy lead time allows you to amuse your customers with new features faster than your competition. By looking at the table above you can also see how fast tech is moving forward: in 2011 Amazon did more than 7,000 deployments daily while in 2017 the number surpassed 23,000/day (don’t forget that in 2009 there was a conference talk on how to do 10 daily!).
较短的部署准备时间使您可以比竞争对手更快地用新功能吸引客户。 通过查看上表，您还可以了解技术的发展速度：2011年，亚马逊每天进行超过7,000个部署，而在2017年，这一数字超过了每天23,000个 (别忘了2009年有一次关于如何每天做10次！)。
DevOps运动宣言 (The DevOps movement manifesto)
According to Google, the DevOps manifesto can be summarized in 5 points:
根据Google的说法，DevOps 宣言可以归纳为5点：
1. Reduce organization silos — It’s about merging your Dev & Ops teams — sometimes it’s as easy as putting them in one room. These two teams should share ownership and use the same tools.
1.减少组织孤岛 -这是关于合并您的Dev＆Ops团队-有时就像将它们放在一个房间中一样容易。 这两个团队应共享所有权并使用相同的工具。
2. Accept failure as normal — It’s almost impossible to develop without any bugs at all, and the only way to deal with them is to have a plan of how to resolve the problems e.g. have a script to roll back deployment when it fails.
2.像往常一样接受失败 -几乎没有任何bug几乎不可能进行开发，并且解决它们的唯一方法是制定一个解决问题的计划，例如拥有一个脚本，以在失败时回滚部署。
3. Implement gradual change — Long time ago some companies used to release large, annual software updates which caused total chaos and disruption. If you deploy 100k lines of code at once finding all bugs would be a miracle. It’s much safer to do it more often in small chunks — preferably in CI/CD methodology.
3.实施渐进式变更 —很久以前，一些公司曾经发布过大型的年度软件更新，这些更新导致了整个混乱和中断。 如果您一次部署10万行代码，发现所有错误将是一个奇迹。 小批量地执行此操作更为安全-最好采用CI / CD方法。
4. Leverage tooling & automation — Ops had a lot of manual work that doesn’t scale — think about installing packages, monitoring, log analysis and so on. In the DevOps world, it has to be automated to increase the velocity of deployments as well as stability & reliability — people are bad at dull, repeatable tasks and often make mistakes.
4.利用工具和自动化 -Ops进行了大量无法扩展的手动工作-考虑安装软件包，监视，日志分析等。 在DevOps世界中，必须对其进行自动化以提高部署速度以及稳定性和可靠性-人们不擅长乏味，可重复的任务并且经常犯错误。
5. Measure everything — You always have to have numbers to prove that what you are doing makes sense and it’s worth to continue living the DevOps way. You can do it by introducing measurement, monitoring (e.g. how much CPU you are using), and alerting tools which can tell you or alert you if any of the crucial parts of your services go down. Alerting should be very selective and focused on symptoms that are painful for end-users.
5.衡量一切 -您始终必须有数字来证明您所做的事情是有意义的，并且值得继续使用DevOps方式。 您可以通过引入测量，监视(例如，正在使用多少CPU)和警报工具来做到这一点，这些工具可以告诉您或提醒您服务中的关键部分是否出现故障。 警报应该非常有选择性，并且应集中在使最终用户感到痛苦的症状上 。
DevOps堆栈 (DevOps Stack)
Let’s have a look at the DevOps pipeline, most popular tools, and their pros and cons.
让我们看一下DevOps管道，最流行的工具以及它们的优缺点。
Continuous Integration & Continuous Delivery/Deployment
持续集成与持续交付/部署
Integration can be understood as merging code from different Developers into one. More frequent integrations mean that the merge conflicts are easier to resolve, so there is a preference for doing it several times a day — almost continuously. Before the code is integrated into the mutual repository, it should be built (building is converting source code into working software) and tested.
集成可以理解为将来自不同开发人员的代码合并为一个。 更频繁的集成意味着合并冲突更容易解决，因此，每天进行几次(几乎是连续的)是一种可取的选择。 在将代码集成到共同存储库之前，应先对其进行构建 (构建过程是将源代码转换为工作软件)并进行测试。
Continuous Integration (CI) tools are often combined with CD tools which can stand either for Continuous Delivery or Deployment. Continuous delivery is an extension of Continuous Integration and means that the code is not only built and tested but also ready to deploy with one click of a button. Continuous Deployment also automates this last click and automatically ships the code to your customers.
持续集成(CI)工具通常与CD工具结合使用，它们可以代表持续交付或部署 。 持续交付是持续集成的扩展，意味着不仅可以构建和测试代码，而且还可以通过单击按钮的方式随时进行部署。 持续部署还可以自动完成最后一次点击，并将代码自动交付给客户。
CI/CD tools usually don’t bring much value on their own, but they serve as a central place to which other parts of the pipeline are connected to. Jenkins is probably the most common tool in this space, but as it was created almost a decade ago, there are some opinions that it’s complex to set up and maintain. It has tons of plugins and integrations which, unfortunately, happen to break from the time to time, so it’s worth giving a try to newcomers like Buddy, or Buildkite, which recently raised $20m Series A.
CI / CD工具通常不会自己带来太多价值，但它们是管道其他部分所连接的中心位置。 Jenkins可能是该领域中最常用的工具，但是由于它是将近十年前创建的，因此有些人认为它的设置和维护很复杂。 它拥有大量的插件和集成，不幸的是，有时会不时中断，因此值得尝试的是像Buddy或Buildkite这样的新手 ，该公司最近筹集了2000万美元的 A 轮融资 。
1. Version Control — when you are programming alone it’s not a problem to store code in a local directory and make copies of it as you go. However, startups and enterprises tend to have dev teams consisting of hundreds or thousands of employees. In such a setup you need to have a tool helping you to avoid code merge conflicts and to recover previous versions of code. This category of tools is called Version Control Systems (VCS) or Source Control Management (SCM). The king of the category is GitHub, much more user friendly than clunky solutions from the past like SVN.
1.版本控制 -仅当您进行编程时，将代码存储在本地目录中并随便进行复制就没问题。 但是，初创企业和企业往往拥有由数百或数千名员工组成的开发团队。 在这种设置中，您需要有一个工具来帮助您避免代码合并冲突并恢复以前的代码版本。 这类工具称为版本控制系统(VCS)或源代码管理管理(SCM)。 类别的王者是GitHub ，它比SVN等过去的笨拙解决方案更加易于使用。
2. Build Automation — tools in this category automate the compilation process (compilation = building = turning your code into a working software), and you usually need to find a tool specific for the programming language you use in the project. There are a lot of open-source options available. Depending on the type of projects, Maven has 35% to 60% market share.
2.构建自动化 -此类别中的工具使编译过程自动化(编译=构建=将您的代码转换为可运行的软件)，并且通常需要找到特定于项目中使用的编程语言的工具。 有很多可用的开源选项。 根据项目类型的不同， Maven拥有35％至60％的市场份额。
3. Artifact Repository — the definitions of artifacts are quite fuzzy but in general they are one of the software development by-products e.g. project source code, dependencies or diagrams explaining how the software should work. Artifacts can vary between versions of software so you need to have a way of managing them. As JFrog has one of the leading Artifact Repository Managers (ARM), it has prepared whitepaper with 10 reasons to use it.
3.神器库 -的定义文物都相当模糊，但一般他们是副产品如项目的源代码，相关性或说明的图软件应该如何工作的软件发展方向之一。 工件因软件版本而异，因此您需要一种管理它们的方法。 由于JFrog拥有领先的Artifact Repository Manager(ARM)之一，因此它已准备了白皮书，并提出了十个使用理由。
4. Testing — As DevOps make development more rapid, security is getting more and more important. Tests can (and should) be run at many points of the pipeline, not only after the building process. Recently this area received a lot of attention, so we will dive deep into it in the next blogpost.
4.测试 -随着DevOps使开发更加快速，安全性变得越来越重要。 测试可以(并且应该)在管道的许多点上运行，而不仅仅是在构建过程之后。 最近，这个领域引起了很多关注，因此我们将在下一篇博文中深入探讨该领域。
5. Infrastructure Provisioning (IP) — Tools for launching your infrastructure. In the past this part of the process was lengthy — you had to order hardware (servers), wait for it to arrive, then set up everything, connect via wires and so on. With the cloud, it’s much easier, and tools like Terraform enable you to manage your infrastructure as a code (IaaC). Spacelift, on top of it, enables collaboration between DevOps, introduces more security, versioning and understanding of your costs.
5.基础结构设置(IP) -用于启动基础结构的工具。 过去，这部分过程很漫长-您必须订购硬件(服务器)，等待其到达，然后进行所有设置，通过电线连接等。 有了云，它变得更容易了，Terraform之类的工具使您可以将基础架构作为代码(IaaC)进行管理。 最重要的是， Spacelift支持DevOps之间的协作，引入了更多的安全性，版本控制以及对成本的理解。
According to DevOps 2019 survey from JetBrains, 65% of the respondents didn’t use any IP tool, which might be partly explained by the fact that some of the Configuration Management tools have IP features, but using them for this purpose has some cons e.g. lower control of your infrastructure.
根据JetBrains的DevOps 2019调查 ，65％的受访者未使用任何IP工具，这可能部分是由于一些Configuration Management工具具有IP功能这一事实而做出的解释，但将其用于此目的有一些弊端，例如降低对基础设施的控制 。
6. Configuration Management (CM) — is another part of IaaC. It lets you maintain IT systems, servers, or software that you have on your infrastructure in a desired state by managing settings, patches or updates. Interestingly 27% of DevOps teams has a custom CM solution. The leading commercial tool with a 23% share is Ansible, which is especially recommended for small infrastructure. Although CM tools have some IP features as already mentioned, and some IP tools have CM features, the best practice is to have separate IP tool like Terraform and CM tool like Ansible.
6.配置管理 (CM) -是IaaC的另一部分。 通过管理设置，补丁程序或更新，它使您可以将基础结构上具有的IT系统，服务器或软件维持在所需状态。 有趣的是，有27％的DevOps团队拥有定制的CM解决方案。 占23％份额的领先商业工具是Ansible， 特别推荐用于小型基础架构。 尽管CM工具已经具有某些IP功能，并且某些IP工具具有CM功能， 但最佳实践是拥有单独的IP工具(例如Terraform)和CM工具(例如Ansible)。
7. Cloud — for scaling up you need to choose your cloud provider. The most popular ones are Azure, AWS, and Google Cloud Platform.
7.云 —要进行扩展，您需要选择云提供商。 最受欢迎的是Azure，AWS和Google Cloud Platform。
8. Containers — in the past there were Virtual Machines with separate operating systems (OS) on the servers. Now, containers are taking their place. Instead of dividing infrastructure into blocks with their separate OS like Virtual Machines, containers are dividing the infrastructure at the level above the OS. They are much faster and more lightweight as a result. In 2018 Docker had 83% of the market (99% in 2017). Containers require orchestration tools to automate their deployment, management and scaling.
8.容器 —过去，服务器上有虚拟机，它们具有单独的操作系统(OS)。 现在，容器正在取代它们。 容器不是将基础架构通过虚拟机等独立的操作系统划分为多个块，而是将基础架构划分为操作系统之上的级别。 结果，它们更快，更轻便 。 Docker在2018年占据了83％的市场份额(2017年为99％)。 容器需要编排工具来自动化其部署，管理和扩展。
DevOps的未来 (The future of DevOps)
What are the most important trends that emerge or might emerge in the DevOps space?
DevOps空间中出现或可能出现的最重要趋势是什么？
Safety first — Implementation of Security in the DevOps pipeline is getting more and more popular. It means not only changing the name from DevOps to DevSecOps but also change in mentality and implementation of many solutions. This trend is so broad, that I decided to prepare a separate blogpost about it.
安全第一 -在DevOps管道中实施安全性越来越受欢迎。 这不仅意味着将名称从DevOps更改为DevSecOps，而且还改变了许多解决方案的思路和实现。 这种趋势是如此广泛，以至于我决定准备一个单独的博客文章。
2. Containers everywhere — Containers are more efficient and cheaper than Virtual Machines, so no wonder that their adoption is increasing and they become a standard.
2.随处可见的容器 -容器比虚拟机更高效，更便宜，因此，难怪容器的采用正在增加并且已成为标准。
3. Keep it simple — the DevOps pipelines vary from organization to organization and sometimes even inside a single organization, but they have one thing in common — usually they are very complex and are based on many different solutions and plugins. Maybe in the future we will see end-to-end tools aggregating higher chunks of the pipeline and removing boilerplate work needed for setup and maintenance. The interesting approach to this trend is Lean DevOps and SlackOps propagated by Tristan Pollock from cto.ai.
3.保持简单 -DevOps管道因组织而异，有时甚至在单个组织内，但它们有一个共同点-通常它们非常复杂，并且基于许多不同的解决方案和插件。 也许在将来，我们将看到端到端工具聚合更高级别的管道，并消除设置和维护所需的样板工作。 解决这一趋势的有趣方法是Trian Pollock从cto.ai传播的Lean DevOps和SlackOps。
推荐阅读： (Recommended reading:)
I hope that this blogpost increased your understanding of the DevOps space. If you have noticed some security gaps in the pipeline — I did it intentionally. In the next analysis, we are going to focus solely on DevSecOps. If you have any comments, see any non-security gaps in the pipeline or if you know (or are building) better solutions for DevOps that I haven’t mentioned above, make sure to reach out to me on LinkedIn or comment below.
我希望这篇博文能增进您对DevOps空间的了解。 如果您注意到管道中存在一些安全漏洞-我是故意这样做的。 在下一个分析中，我们将仅专注于DevSecOps。 如果您有任何意见，请查看管道中存在的任何非安全漏洞，或者如果您知道(或正在构建)我上面未提到的DevOps更好的解决方案，请确保在LinkedIn上与我联系或在下面发表评论。
Inovo Venture Partners is a CEE focused Venture Capital fund investing in top entrepreneurs on Late Seed and Series A stage. Subscribe Inside Inovo and our LinkedIn to learn more about technology in Central Eastern Europe.
Inovo Venture Partners是专注于CEE的风险投资基金，主要投资后期种子和A 轮融资阶段的顶尖企业家。 订阅Inside Inovo和我们的LinkedIn，以了解有关中东欧技术的更多信息。
翻译自: https://medium.com/inside-inovo/devops-explained-venture-capital-perspective-156c5705e774
扫一扫
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
