文档结构  
翻译进度:53%     翻译赏金:0 元 (?)    ¥ 我要打赏

底特律、密歇根已经成为美国汽车制造业的中心,自从二十世纪之交亨利·福特每天在他的麦克道工厂制造汽车。如今,除了福特、别克、凯迪拉克,其余的通用汽车家庭称汽车城为他们的家。在所有的马力和金属板的生产线,汽车制造商还聘请了众多的软件应用程序和不同工具的供应商作为他们的业务的一部分。一个这样的你从没听过的汽车行业组织——底特律的优赛斯,一个正在改变汽车行业的经营方式的公司。

第 1 段(可获 1.36 积分)

优赛斯是一个全球性的汽车零售专家,为70多个国家几乎每一个汽车制造商服务。从Acura到Volvo的几乎每一个制造商之间,优赛斯研究出了汽车公司增加市场份额,提高盈利能力的创新的方法。他们的目标是找出和解决这个庞大的行业最棘手的商业挑战。他们与制造商合作,以帮助他们了解人们是如何购买,维修他们的汽车和使用他们的汽车。基本上,如果在汽车行业有任何统计数据,优赛斯都会研究它和解释它。他们的工作有助于制造商获在整个产品生命周期中看穿一切。例如,他们不仅能告诉你哪个福特经销商销售了最多的黄色敞篷野马,还可以告诉福特经销商客户带车回到同一个经销商维修的可能性有多大。如果他们这么做了,这意味着客户下一次买了一辆新车之后也会这么做。

第 2 段(可获 2.2 积分)

你可以想象基础设施和软件的更新需要支持这样的操作和满足苛刻的客户,还要承担高风险的业务,和每时每刻都要分析从世界各地收集的大量数据。

Mark Priolo,优赛斯的软件配置方面的经理,他正面临着这项挑战。跨越了配置管理和发布管理之间的界限,Priolo负责建设和管理软件发布流程和IT环境,把优赛斯的产品提供给客户。他是通过DevOps自动化实现的,而持续交付(CD)是软件交付实践的一部分。

第 3 段(可获 1.25 积分)

司机

在其投资组合和各种服务范围内,优赛斯研发了几十个应用程序,并让数百名开发人员和研究人员对它们进行优化和管理。

当优赛斯的应用不断变得更复杂,他们的相应的研究和发布过程也变得更加复杂。有限的测试覆盖率、标准化的流程的缺乏以及环境因素拖延了把关键软件展示给客户,导致错过了发布时机。此外,随着基础设施成本的增加和管理开销的增加,基础设施利用效率变得低下。为公司保持竞争力,并有效地为客户服务,是时候要做一些事情了。

第 4 段(可获 1.25 积分)

虽然优赛斯的运营团队是令人难以置信的强大,但这些部署的复杂性不断增加错误发生的可能性。被问及的行动小组被指出是根本是不可持续的。例如,有团队准备推出需要15页的文件,在他们的跳跃式逻辑里产生(即“看到第7页,这样做…然后转到第3页,再这样做”)的应用程序。不仅是部署复杂并且非常耗时的发展计划,而且部署过程本身可能就需要几个小时。

所以,Priolo着手实施自动化和CD的做法,加快流水线生产以减少手动任务,一次性的配置和减少部署错误,同时提高测试覆盖率,增加反馈环,和加快部署的节奏。

 

第 5 段(可获 1.56 积分)

然而,这样做并不是没有它成长的痛苦。

连续交货的路径上的挑战

Priolo的第一个难题就是找出什么是需要自动化的。当然,做事情的老方法是艰难的,但同时也是有用的。然而,事实是仍然有大部分人力投入到工作中。即使决定是要这样,“是的,我们应该自动化,”。问题仍然存在:他们应该要自动化现有的工作抑或是把自动化投入到新工艺中,让新工艺从最初的步骤就是自动化的?最开始的决定是把交付流程自动化,只用于新的应用程序和工作流程。在时间上对旧的流程保持原样。

第 6 段(可获 1.59 积分)

自动化的另一个难题是团队运用。虽然行政管理认识到需要采取DevOps来实施和尝试应用持续交付功能,但这些做法不是团队必须要做的。相反,团队被给予选择权,他们是想自动化,或是继续用人力的老方法。

过了一会儿,组织退回来分析和重新评估他们的部署策略。明显这个是可以优化的——这种认知有一部分直接来源于看着2年前的老方法的发布过程得到支持,但是它并没有进步。而较新的,持续交付功能的发展是通过流水线飞速发展的。现在,人们都在问:“我们也可以把旧的程序自动化吗?”

第 7 段(可获 1.49 积分)

简化持续交付的流程

你比你所意识到的更相似

事实上,每一个应用程序的代码是独一无二的,一些部署过程需要非常独特的配置或测试——在所有程序中,90 %的交付过程在整个汽车的生命周期中是相同的。Priolo和他的团队开始在不同的应用中的承诺生产的流水线上找到这些相似之处。当他们能复现这个过程,他们就提出了一个强大的管道模型,将实现90%的交付过程。然后,他们开始推出这条流水线管道,以及其固有的自动化任务,到大约有六个团队开始使用它。

第 8 段(可获 1.36 积分)

The results were extremely encouraging: with a relatively small number of teams and applications included, the project had already saved over 1,800 man hours annually.

Look at the Big Picture, Focus on the Biggest Pain for the Biggest Impact

Priolo approached automation by looking at it from the perspective of identifying the opportunities for big wins and focusing on those. The goal wasn’t to fix local processes that were broken along the way, but rather to discern pain points and give the most bang for the buck.

Being a small team, Priolo didn’t want to have automation creep—ad-hoc fixing of different processes for various teams to address specific scenarios. The focus had to have been on reusability, system-level view, and the ability to scale. These would allow his efforts to have the most impact for the entire organization, rather than achieving only local optimizations, which may not amount to much in the large scheme of things (- or – may just be moving the bottlenecks to other areas in the pipelines.)

第 9 段(可获 2.18 积分)

Therefore, Urban Science focused on three different pipeline models that would be applicable for the vast majority of use cases. By doubling down on those three, Urban Science can service the majority of teams and application, giving them just about everything they need.

Bring Others on Board!

While the initial efforts to implement automation started off with just that half dozen teams buying-in, Urban Science now has over 70 teams taking advantage of that model. Depending on the specific application and use case, some teams have chosen to release monthly, weekly, and even multiple times a day.

第 10 段(可获 1.21 积分)

These three pipeline models and the standardization across teams allow the entire organization to become more agile, and increase product quality and release velocity and throughput. This sort of release cadence and speed was just not possible with trying to schedule times for manually manage all the processes and environments configurations involved in the delivery pipeline.

Think ‘Process As Code’

After modeling the key release pipelines and standardizing their processes, Urban Science turned their focus on treating their Process as Code. Using a technology that enabled them to essentially export their pipeline models and all related automation as code, they were able to have their DevOps processes themselves be programmable. This meant that they could be versioned, reused, and stored in their source code repository—along with their application code and environment configuration.

第 11 段(可获 1.66 积分)

With the process itself being codified, Urban Science could more easily onboard new applications and teams, update their code to support additional use cases, and more easily extend certain pipelines for specific needs—achieving predictable, repeatable, releases processes across the organization.

Do It End-To-End

To accomplish all this, Urban Science leveraged Electric Flow—an end-to-end DevOps Release Automation platform from Electric Cloud, to simplify build, test, deployment, and release of multi-tiered applications.

A successful DevOps transformation takes the right people and culture, the right processes, and also the right tooling. From a tooling perspective, it was crucial for Urban Science to have a unified, single platform that can support their entire end-to-end delivery process, across all teams, and be able to orchestrate all the point tools, workflows, and environments that are part of the process.

第 12 段(可获 1.69 积分)

This ensured the ability to standardize their pipelines across teams and applications, and scale to support the entire organization (rather than cobble together a different chain of tools or snowflake configurations for various tasks). In addition, this provided both Development and IT shared control and visibility into their software pipeline, across development, testing, and packaging stages.

To ensure compliance and organizational control, the pipeline also supports both automated and manual approval gates as code is promoted to further stages along the pipelines and into higher environments. (For example, code can be promoted automatically upon passing a battery of test, or await a confirmation from a supervisor via the platform, before proceeding to the next stage.)

第 13 段(可获 1.44 积分)

Continuous Improvement and the Bottom Line:

By adapting new ways of thinking and new technology solutions, Urban Science is now able to drive their software production within a Release Pipeline model. In this approach, all the tasks and workflows throughout the pipeline—from code commit to Release into Production—are being completely automated and standardized as much as possible across teams.

This has had a great impact on the business.

DevOps and CD are essentially a journey along a path to continuously optimize your software delivery, to improve IT and organizational performance. Automating the end-to-end Release pipeline is what “greases the wheels” for Urban Science software innovation. Now, the teams are freed to focus on developing great features, rather than on building ad-hoc workflows or doing manual work to manage the path that the code has to go through until it is ready to be released to end users.

第 14 段(可获 1.86 积分)

DevOps release automation and Continuous Delivery practices have enabled Urban Science to accelerate their software delivery—saving time, lowering costs, and increasing productivity. They are now able to better serve their automotive clients—building new and innovative solutions that are changing the way auto manufacturers produce, sell, and services their cars.

Urban Science Achieved:

  • Faster and more frequent deployments. Urban Science went from 12 deployments per week to 40 deployments a week.
  • Fewer person resources required. Manual processes replaced by automation reduced person resources needed for deployment by 78%.
  • Fewer process errors. Tedious, error-prone manual operations have been eliminated, improving predictability and reliability, and reducing the number of deployments needed.
  • Better software quality. Automated deployments mean more time is spent testing instead of on the deploy process.

For a deeper dive into this story, watch the video replay of Marc Priolo talking about his experience.

第 15 段(可获 1.81 积分)

文章评论