
Spanish: 
Bienvenidos, me llamo Rob Brigham
y ella es Clare Liguiori.
Somos del Grupo de Herramientas
para Desarrolladores de AWS.
Diseñamos herramientas
para los desarrolladores de Amazon
y servicios de código AWS
para nuestros clientes.
Hoy vamos a hablar de DevOps en Amazon,
y explicaremos cómo se desarrollan
las aplicaciones y los servicios web
de Amazon desde dentro.
Dividiremos la charla en dos partes.
Primero les voy a contar cómo Amazon
transformó las DevOps,
y cómo conseguimos ser más ágiles
en la producción de software.
Después, volveremos a la actualidad
para presentarles tres servicios nuevos:
AWS CodeCommit, CodePipeline y CodeDeploy.
Y después, Clare tomará la palabra
y nos hará una demostración
de cómo usar estos nuevos
servicios de código

English: 
ROB BRIGHAM: Welcome everyone, my
name's Rob Brigham
and this Clare Liguiori.
We're from the AWS Developer Tools Group
where we build the tools that developers
inside of Amazon use
as well as a new set of AWS code services
that all of our customers can use.
Today, we're going to talk about
DevOps at Amazon
and give you an inside peek at how
Amazon develops
our web applications and web services.
We're going to divide the talk into two parts.
First, I'm going to tell you the
story of how Amazon
made its own DevOps transformation
and how we became more agile at delivering software.
After covering that history, we're
going to come back to the present
and I'll introduce to you three new services,
AWS CodeCommit, CodePipeline, and
CodeDeploy.
After that, Clare's going to come up
and give us a great in-depth demonstration
of how to use these new code services

Chinese: 
欢迎大家，我是 Rob Brigham，
这位是 Clare Liguiori。
我们来自 AWS 开发人员工具小组，
负责构建可供 Amazon 内部的开发人员使用的工具
以及可供我们所有客户
使用的一系列新的 AWS 代码服务。
今天，我们将谈谈 Amazon 的运营开发，
并为你介绍 Amazon 开发
我们的 Web 应用程序和 Web 服务的方式。
我们将本次演讲分为两个部分。
首先，我将介绍 Amazon
如何对其自己的开发运营进行转型
以及我们如何更灵活地交付软件。
了解发展过程后，我们回到当下，
我将介绍
AWS CodeCommit、CodePipeline 和 CodeDeploy 这三种新服务。
之后，Clare 将为我们进行一次精彩的深入演示，
说明如何使用这些新的代码服务

Portuguese: 
Sejam todos bem-vindos.
Meu nome é Rob Brigham
e esta é Clare Liguiori.
Somos do grupo de desenvolvedores
de ferramentas do AWS,
onde criamos as ferramentas usadas
pelos desenvolvedores da Amazon.
Também criamos um novo
conjunto de serviços de código
para o uso dos nossos clientes.
Hoje, falaremos sobre as operações de
desenvolvimento (DevOps) da Amazon.
Também explicaremos como a Amazon desenvolve
nossas aplicações e serviços da Web.
Esta apresentação será
dividida em duas partes.
Primeiro, contarei como a Amazon
revolucionou seu DevOps
e como agilizamos a entrega de software.
Depois, voltaremos para o presente
e eu apresentarei três novos serviços:
AWS CodeCommit, CodePipeline e CodeDeploy.
Em seguida, a Clare se juntará a nós
para fazer uma demonstração detalhada
do uso desses novos serviços de código

Portuguese: 
para a criação das suas próprias operações.
Antes de começarmos, peço desculpas
e tenho uma confissão a fazer.
Peço desculpas pela minha voz,
eu não sou rouco desse jeito.
Juro que dormi cedo ontem, não
fiquei acordado até tarde,
mas, ainda assim, estou um pouco mal.
Talvez eu faça pequenas pausas
para beber um pouco de água
durante a apresentação.
E agora, faço a confissão:
eu odeio o termo "DevOps".
Sempre me incomodou.
E isso porque é um termo muito vago.
As pessoas usam "DevOps" em contextos
diferentes com significados diferentes.
Assim, sempre que alguém diz
"DevOps", as outras pessoas
não sabem exatamente sobre
o que estão falando.
Mas no começo do ano, cedi à pressão
e comecei a usar esse termo
nas minhas apresentações.
É o melhor termo disponível
para descrever esse estilo
moderno de desenvolvimento
e fornecimento de software.
Mas como passei a usar esse
termo, tenho que defini-lo.
Não darei uma definição direta do termo,
mas farei uma relação entre ele

Spanish: 
para crear sus propios procesos de DevOps.
Pero antes de comenzar,
debo disculparme
y confesar una cosa.
Lo primero es disculparme por mi voz,
normalmente no estoy ronco.
Les prometo que ayer me acosté temprano,
no me quedé hasta las tantas,
pero aún así estoy un poco tocado.
Por eso iré parando de vez en cuando y
bebiendo un poco de agua durante la charla.
Y ahora, la confesión:
antes no soportaba el término DevOps.
Me ponía de los nervios.
Era muy confuso.
Se usaba de muchas formas
para referirse a cosas muy distintas.
Cuando alguien hablaba de DevOps,
los demás no sabían muy bien
de qué se trataba.
Pero este año finalmente
me dejé llevar
y comencé a utilizar
el término DevOps en mis charlas.
En realidad es el mejor
término para definir
este nuevo estilo moderno
de desarrollo y producción
de software.
Así que, como lo voy a usar,
voy a tener que definirlo.
Pero no lo voy a definir directamente,
sino que lo voy a relacionar

Chinese: 
来创建你自己的开发运营流程。
不过，在我们开始之前，我要致歉和坦白一下。
首先，我为自己嘶哑的嗓音深表歉意。
我向大家保证，我昨晚很早就上床休息了，我并没有熬夜，
但嗓音仍有点嘶哑。
因此，在演讲过程中，
我可能必须休息一下，喝点水。
现在我想坦白的是，我过去讨厌开发运营这个词。
它真的让我感到烦恼。
我烦它是因为它不明确。
人们通过多种不同的方式
使用它来表示许多不同的事情。
当有人说起开发运营时，其他人
将无法确定他们谈论的内容。
但今年早些时候，我最终屈服于压力，
开始在我的演讲中使用开发运营这个词。
它实际上只是一个术语，最准确地
描述了这种新型的软件开发和交付方式。
由于我将在演讲中使用这个词，因此我必须定义它。
我不会直接定义它，
而是将它关联到

English: 
to create your own DevOps processes.
But before we get started I have
both an apology
and a confession to make.
So, first I apologize for my voice,
it's not normally this hoarse.
I promise I went to bed early last
night, I did not stay up late,
but still, I'm losing it a little bit.
So, I might have to take some breaks
and have some water in between the talk.
Now for my confession, I used to
hate the term DevOps.
It just really, really bugged me.
And it bugged me because it's fuzzy.
People would use it in many different ways
to mean many different things.
So, whenever anyone said DevOps,
other people
weren't really sure what they were
talking about.
But earlier this year I finally caved
to the pressure
and I started using DevOps in my talks.
It just really is the best term out there
that captures this new modern style
of software development
and delivery.
So, since I'm using it in my talk,
I'm going to have to define it.
And I'm not going to define it directly,
but I'm going to relate it to something

English: 
that we're all very familiar with,
and that is
the software development lifecycle.
So, this is a typical lifecycle for any kind
of web application or web service.
On one side you're going to have
your customers
and then the other side you're going
to have the developers.
Every new feature that you build
in that application
is going to go through this lifecycle.
Developers are going to come up with the idea,
they're going to implement that,
they're going take the codes
that they write, then they're going
to build it, test it,
put it through the release process
until it finally
gets out into production where your
customers can use it.
After your customers get their hands on it
then you can start to learn from it.
Your development team can look at
the customer usage data of the application,
they can get feedback directly from
the customers,
and they can start to learn to make
educated decisions
on what they want to do next.
So, they might choose to refine that
feature to improve it,
or they could chose to build a whole
new feature
and then this whole loop starts again.
So, there are two important things to note
about this development lifecycle.
First, is that the speed at which
you're able to complete this loop

Portuguese: 
e outro conceito que conhecemos bem:
o ciclo de vida de
desenvolvimento de software.
Trata-se do ciclo típico
de todos os serviços ou aplicações da Web.
De um lado, temos os clientes
e do outro, temos os desenvolvedores.
Todos os novos recursos
criados para uma aplicação
passarão por esse ciclo de vida.
Os desenvolvedores têm uma ideia
e são responsáveis pela implementação dela.
Eles escrevem, desenvolvem
e testam o código, além de
implementá-lo durante todo
o processo de liberação
até o produto ser disponibilizado
para os clientes.
Quando os clientes começam a usar o produto,
começa nosso aprendizado.
A equipe de desenvolvimento analisa
os dados de uso da aplicação pelos clientes.
Ela recebe comentários
diretamente dos clientes
e, em seguida, consegue tomar
decisões fundamentadas
sobre os próximos desenvolvimentos.
A equipe escolhe entre melhorar esse produto
ou desenvolver outro recurso da estaca zero,
e nesse caso todo o processo recomeça.
Existem dois aspectos importantes
nesse ciclo de vida de desenvolvimento.
O primeiro é a velocidade de
conclusão desse processo:

Chinese: 
大家都非常熟悉的内容，也就是
软件开发生命周期。
这是任何类型的 Web 应用程序或 Web 服务的
典型生命周期。
你的一边是客户，
另一边是开发人员。
你在该应用程序中构建的每项新功能
都将经历此生命周期。
开发人员将提出这个想法，
实现这个想法，利用自己编写的
代码，然后他们将构建应用程序，测试应用程序，
将应用程序放入发布流程中直至应用程序最终
投产，以便你的客户可使用它。
在你的客户获得应用程序后，
你可以开始从中获得见解。
你的开发团队可以查看
应用程序的客户使用数据，
可以直接获得客户反馈，
并且可以开始学着做出有关下一步行动的成熟决策。
他们可能选择优化该功能以进行改进，
也可能选择构建全新功能，
整个循环将重新开始。
关于此开发生命周期，要注意
两个重要事项。
第一个重要事项是你完成构建新功能、

Spanish: 
con algo que todos conocemos,
que es el ciclo de vida
para el desarrollo de un software.
Esto es un ciclo
de vida típico de cualquier
aplicación o servicio web.
Por un lado están los clientes;
y por otro, los desarrolladores.
Cada nueva función
que se incluya en la aplicación
va a pasar por este ciclo de vida.
Los desarrolladores tienen una idea,
la implementan, escriben el código,
lo montan, lo prueban,
y lo llevan a un proceso de
lanzamiento hasta que finalmente
pasa a producción, donde llegará
a manos de los clientes.
Una vez que llega a los clientes
ya se puede empezar a aprender.
El equipo de desarrolladores puede analizar
los datos de uso de la aplicación,
puede recibir comentarios
directamente de los clientes,
y puede tomar decisiones
bien fundamentadas
para el futuro.
De esta manera, se puede retocar
la función y mejorarla, o se puede
diseñar una función totalmente nueva
y comenzar todo el proceso de nuevo.
De manera que hay dos
cosas importantes a tener
en cuenta sobre este ciclo
de vida de desarrollo.
En primer lugar, la velocidad necesaria
para completar este proceso

Chinese: 
向客户交付新功能
以及让客户开始使用新功能这个循环
以便获得见解的速度，
完成此循环的速度决定了你的业务的敏捷性。
你完成此循环的速度越快，
你响应客户的能力越高，
并且你创新的速度越快。
在 Amazon，我们非常注重尽快完成此循环。
第二个重要事项是，当你的开发人员
在左边编写新代码时，不仅仅是增加客户眼中的价值。
你的开发人员在构建交付管道
或处理管道中变更方面
花费的任何时间，
在客户看来都是白费的。
你的客户只关注你的开发人员
所编写的新功能。
因此，你需要最大程度地增加你的开发人员编写
新功能的时间，
同时最大程度地减少他们在中间花费的时间。
对我来说，这两个方面
构成了开发运营的核心。
对我来说，开发运营是可推动此流程

Spanish: 
de creación de una nueva función,
ponerla en manos de los clientes
y que la comiencen a usar
y se pueda aprender de ello,
la velocidad a la que se completa ese proceso
determina la agilidad de su empresa.
Cuanto más rápido se pueda hacer,
más capacidad de respuesta
tendrá para sus clientes,
y podrá innovar más rápido.
En Amazon, intentamos completar
este proceso lo más rápido posible.
El segundo punto a tener en cuenta
es que, para sus clientes,
los desarrolladores solo añaden
valor cuando trabajan
en esta fase,
escribiendo código nuevo.
El tiempo que pasan los desarrolladores en la
fase del medio diseñando
un proceso de entrega,
o gestionando cambios en ese proceso,
para los clientes es tiempo perdido.
Los clientes solo verán
las nuevas funciones
que escriben los desarrolladores.
Por eso, lo que más nos interesa
es maximizar el tiempo
que dedican sus desarrolladores
a escribir nuevas funciones
y minimizar el tiempo que
dedican a la fase del medio.
Y esas dos cosas
son el núcleo de lo que hacemos en DevOps.
Para mí, DevOps es la eficiencia
que puede impulsar este proceso

Portuguese: 
criar um novo produto e
disponibilizá-lo para os clientes
para que eles comecem a usar e você
possa aprender com os dados de uso.
A velocidade de conclusão desse processo
determina a agilidade da sua empresa.
Quanto mais rápido você fizer esse processo,
maior será seu poder de resposta aos clientes
e, assim, sua capacidade de inovar.
Na Amazon, nós nos comprometemos a concluir
esse processo o mais rapidamente possível.
O segundo aspecto importante é
que, na visão dos clientes,
nossos desenvolvedores
agregam valor ao processo
quando eles se concentram mais
na escrita de novos códigos.
O tempo que os desenvolvedores
gastam no decorrer
de tudo, seja criando o processo de entrega
ou fazendo alterações nesse processo,
é uma perda de tempo, na visão dos clientes.
Os clientes veem apenas os produtos
que seus desenvolvedores criam.
Ou seja, é necessário maximizar o tempo
de desenvolvimento de novos produtos
e minimizar o tempo gasto
no meio do processo.
E, na minha opinião,
esses duas aspectos são a essência do DevOps.
Para mim, o DevOps é a eficiência
usada nesse processo para que você conclua

English: 
to build a new feature, get it in
the hands of your customers,
and have your customers start using
it and so you can learn from that,
the speed of completing that loop
determines your business agility.
The faster you're able to go through it,
the more responsive you'll be to customers,
and the quicker you'll be able to innovate.
At Amazon, we focus intently on completing this loop
as quickly as we can.
The second thing to note is that
your developers are
only adding value in the eyes of
your customers
when they're working over here on
the left side, writing new code.
Any time that your developers spend
in the middle
either building the delivery pipeline,
or handholding changes through that pipeline,
all of that time is lost in the eyes
of your customers.
Your customers will only see the
new features
that your developers are writing.
So, what you want to do is maximize
the amount of time
that your developers are writing
new features
and minimize the amount of time that
they're spending in the middle.
And it's really those two things
that make up the heart of DevOps to me.
To me, DevOps is any efficiency
that you can drive into this process
that helps you move

Chinese: 
的任何效能，可帮助你更快地通过此循环。
这就是它如此令人困惑的原因，
因为你在开发运营中可做许多事情。
你可进行组织更改、文化更改、
流程更改、工具更改，我认为都是没问题的。
对我来说，你做出的改进中可加速通过
此生命周期的任何改进都可视为开发运营。
因此，为了使此主题更具体，
我将介绍 Amazon 背后
的开发运营转型故事。
像大多数公司一样，我们一开始并未走开发运营之路。
实际上，如果你追溯到 2001 年，
amazon.com 零售网站是一个大型的结构巨石。
别误会，它是一个多层结构，
这些层包含许多组件，
但它们全部紧密地结合在一起，
从而它们的行为方式就像一个巨石。
许多初创公司，甚至大公司内的项目
最初都采用这种结构。
它们采用巨石开路的方式，因为这种方式能够
快速取得成效，
但随着时间的推移，在项目成熟时，

Spanish: 
y realizar estas tareas más rápidamente.
Por eso es tan confuso,
porque se pueden hacer
muchas cosas en ese sentido.
Cambios organizativos,
cambios culturales,
cambios en el proceso, cambios
de herramientas, y todo eso está bien.
Para mí, DevOps son las mejoras
que se pueden incluir
para agilizar todo ese ciclo de vida.
Para concretar un poco más,
les voy a contar cómo fue
la transformación de Amazon
para llegar a DevOps.
Y como en la mayoría de las empresas,
no empezamos de esa manera.
De hecho, en 2001,
el sitio web de amazon.com era
una gran arquitectura monolítica.
Pero no me malinterpreten: era
una arquitectura con muchos niveles,
y cada uno de ellos
con muchos componentes,
pero todos estaban
muy emparejados entre sí,
comportándose de una forma monolítica.
Actualmente, muchas empresas emergentes y
también proyectos dentro de grandes empresas
comienzan de esa forma.
Con un enfoque monolítico
porque es muy rápido,
para empezar rápido,
pero a medida que el proyecto avanza

Portuguese: 
esse processo mais rapidamente.
E daí a confusão do conceito:
esse processo é extremamente abrangente.
Você pode fazer mudanças
organizacionais e culturais
ou mudanças de processo ou
nas ferramentas, e tudo bem.
A meu ver, todas essas melhorias
para agilizar o ciclo de vida
são contabilizadas como DevOps.
Para dar um exemplo mais concreto,
vou contar sobre os bastidores
da transformação do DevOps
da própria Amazon.
Como a maioria das empresas,
não começamos com o DevOps.
Na verdade, se analisarmos o ano de 2001,
o website de varejo amazon.com era um
grande bloco de arquitetura única.
Não me entendam mal: ele tinha várias camadas
e essas camadas tinham vários componentes,
mas era tudo tão engessado
que parecia um bloco único.
Várias startups e até mesmo alguns
projetos de empresas grandes
começam assim.
Eles são lançados como um bloco
único, o que é mais prático
para começar com rapidez.
Mas com o tempo,

English: 
through this loop faster.
And this is why it's so confusing
because there are many things you
can do here.
You can make organizational changes,
cultural changes,
process changes, tool changes, and
I think that's okay.
To me, any of those improvements
that you can do
to move faster through this lifecycle
count as DevOps.
So, to make this more concrete,
I'm going to tell you the backstory
of Amazon's own
transformation to DevOps.
And like most companies, we did not
start out that way.
In fact, if you go back to 2001,
the amazon.com retail website was
a large architectural monolith.
Now, don't get me wrong, it was architected
in multiple tiers
and those tiers had many components in them,
but they're all very tightly coupled together
where they behaved d like one big monolith.
Now, a lot of startups and even projects
inside of big companies
start out this way.
They take a monolith first approach
because it's very quick
to get moving quickly,
but over time, as that project matures,

Portuguese: 
à medida que mais desenvolvedores se
juntam à equipe, o projeto avança,
o banco de códigos aumenta
e a arquitetura fica mais complexa,
essa abordagem passa a
adicionar custos indiretos
e atrasar o ciclo de vida de
desenvolvimento desse software.
Para descrever o modo como
isso afetou a Amazon,
eu tive que fazer uma nova
renderização do ciclo
dessa aplicação em bloco único.
Como consequência, tivemos que ter
um número enorme de desenvolvedores
para operar esse website gigante,
muitos mais do que ilustrado desse slide.
E embora cada desenvolvedor
trabalhe em uma parte pequena da aplicação,
eles precisam encarar os custos indiretos
da coordenação de todas as alterações
com os outros profissionais do projeto.
Para adicionar um recurso
ou consertar um bug,
é necessário assegurar que aquela alteração
não afetará outras partes do projeto.
Se um desenvolvedor precisar
atualizar uma biblioteca compartilhada,
ele terá de convencer todos
os envolvidos no projeto
a fazer a mesma atualização no mesmo momento.

Spanish: 
y se van incorporando
más desarrolladores y va creciendo,
el código base se incrementa
y la arquitectura se vuelve más compleja,
ese monolito incrementará los gastos
generales del proceso,
y el ciclo de vida del desarrollo
del software será más lento.
Para reflejar de qué manera
esto ha afectado a Amazon,
hemos pasado el ciclo
de desarrollo del software
a una aplicación monolítica.
Había un número muy elevado
de desarrolladores
trabajando en este sitio web monolítico,
muchos más de los que tenemos
en esta diapositiva.
Incluso si cada uno de esos desarrolladores
trabajase en una parte muy pequeña
de la aplicación,
seguirían teniendo que reducir el
trabajo adicional de coordinar
sus cambios con los del resto
de miembros del equipo.
Si están añadiendo una nueva función
o corrigiendo errores,
deben asegurarse de que ese cambio no va a
interrumpir el trabajo de otra persona.
Si quieren actualizar
una biblioteca compartida
para aprovechar una función nueva,
deben convencer a los demás
para que actualicen la biblioteca
compartida al mismo tiempo.

Chinese: 
你添加的开发人员越来越多，它开始发展，
代码库变得更大，
并且架构变得更复杂，
该巨石将增加流程的负担，
软件开发生命周期将开始变慢。
为了描述这将给 Amazon 带来的影响，
我已重新呈现整体应用程序的
软件开发生命周期。
我们有大量开发人员
处理这个大的整体网站，
数量大大超出我们在这张幻灯片上列出的数量。
即使每位开发人员
仅处理应用程序的非常小的一部分，
他们仍需负责
与项目中所有其他人员协调其更改。
如果他们要添加新功能或修复错误，
他们需要确保更改不会中断
项目中其他人员的工作。
如果他们要升级共享库
以利用新功能，
他们需要说服项目中的其他人员
同时升级到新的共享库。

English: 
as you add more developers on it,
as it grows
and the codebase gets more large
and the architecture gets more complex,
that monolith is going to add overhead
into your process
and that software development lifecycle
is going to begin to slow down.
So, to depict how this was affecting Amazon,
I've re-renderd the software development lifecycle
for a monolithic application.
So, what we had was a very large
number of developers
working on this one big monolithic website,
many more than what we have up on
this slide.
And even though each one of these developers
is only working on a very small piece
of that application,
they still need to bite off the overhead
of coordinating their changes with
everyone else in the project.
If they're adding a new feature or
making a bug fix,
they need to make sure that change
is not going to break
someone else on that project.
If they want to upgrade a shared library
to take advantage of a new feature,
they need to convince everyone else
on that project
to upgrade to the new shared library
at the same time.

Chinese: 
如果他们要进行快速修复
以快速推送给其客户，
他们无法按照自己的时间表来完成这个任务，
他们将需要与同时正在进行更改的
所有其他开发人员进行协调。
这将导致产生类似合并星期五
或可能合并周的影响，其中所有开发人员
汇总其正在进行的更改，将更改一起合并到一个版本中，
解决其所有冲突，并最终创建一个可进入
生产阶段的主版本。
即使你有一个大型的新版本，
仍会给此交付管道增加大量负担。
需要重新构建全新的代码库，
所有测试用例需要重新运行
以确保无回归。
之后，你需要获取整个应用程序
并将其部署到你的整个生产机群中。
在 Amazon，我们于 2000 年年初组建了一个工程小组，
这个小组专门负责获取新版本的应用程序
并跨我们的生产环境推送应用程序。
这不仅为我们的交付流程增加了许多负担，

English: 
And if they want to make a quick fix
to push out to their customers quickly,
they can't just do it on their own schedule,
they're going to need to coordinate
that with all the other developers
who have in-process changes at the same time.
And this leads to the effect of something
like a merge Friday,
or maybe even a merge week, where
all the developers
take their in-process changes, merge
them together into one version,
resolve all their conflicts, and
finally create a master version
that's ready to move out into production.
And even when you have that big,
large new version,
it still adds a lot of overhead on
this delivery pipeline.
That whole new codebase needs to
be rebuilt,
all of the test cases need to be rerun
to make sure that there's no regressions.
and then you need to take that entire
application
and deploy it all to your full production fleet.
At Amazon in the early 2000s, we
had a single engineering group
whose sole job it was to take these
new versions of the application
and manually push it across our production
environment.
So, this was adding a lot of overhead
not only to our delivery process,

Portuguese: 
E se ele quiser fazer um reparo rápido
para fazer uma entrega ao cliente, não poderá
se ater somente seu próprio cronograma.
Ele precisará coordenar sua parte
com todos os outros desenvolvedores
atingidos pelas alterações.
Isso leva àquele cenário que todos conhecemos
e dura um dia ou até mesmo
uma semana inteira:
todas as alterações individuais são
implementadas em um único processo
para resolver todos os conflitos e
finalmente criar a versão final
que esteja pronta para a produção.
E mesmo que você consiga
essa enorme versão final,
são adicionados muitos custos
indiretos no processo de entrega.
Todo o banco de código precisa ser recriado,
e todos os testes precisam ser refeitos
para garantir que não haverá regressões.
Em seguida, toda essa aplicação
precisa ser implementada na fase de produção.
No começo dos anos 2000, a Amazon
tinha um grupo de engenheiros
cuja tarefa exclusiva era pegar
essas novas versões da aplicação
e implementá-las manualmente
no nosso ambiente de produção.
Isso implicava muitos custos indiretos
ao nosso processo de entrega,

Spanish: 
Y si quieren hacer un arreglo rápido
para devolver el software
a los clientes rápidamente,
no pueden hacerlo según sus tiempos,
sino que tendrán que coordinarse
con el resto de desarrolladores
para implementar
los cambios al mismo tiempo.
Y todo esto nos lleva al efecto
que yo llamo "viernes de unificación",
o incluso "semana de unificación",
donde todos los desarrolladores
recopilan sus cambios y los
unifican en una sola versión,
resolviendo los conflictos y
creando una versión maestra
que pueda pasar a producción.
E incluso cuando ya esté disponible
esa versión grande,
se seguirá añadiendo mucho trabajo
adicional al proceso de entrega.
Hay que reconstruir
el nuevo código base y
volver a realizar pruebas
para asegurarse de que no hay regresiones.
Y luego tendrá que
distribuir e implementar la
aplicación para toda la flota de producción.
A comienzos de la década del 2000 en Amazon,
teníamos un solo equipo de ingeniería
cuyo única tarea era tomar
estas versiones de la aplicación
y pasarlas como fuera a producción.
Eso no solo añadía mucho trabajo adicional
al proceso de entrega,

Spanish: 
sino que era frustrante
para los desarrolladores y, además,
ralentizaba el ciclo de vida
de desarrollo del software
y nuestra capacidad para innovar.
Por eso hicimos cambios,
algunos de ellos muy grandes.
El primero fue en la arquitectura.
Revisamos esa aplicación monolítica
y la fragmentamos
para convertirla en una arquitectura
orientada a servicios.
Revisamos el código, retiramos
las unidades funcionales
que tenían un objetivo único,
y las colocamos dentro
de una interfaz de servicio web.
Retiramos varios
servicios de objetivo único,
por ejemplo, uno cuya única tarea
era que el botón de comprar funcionase bien
en las páginas de detalle de producto;
también había otro cuya única función
era calcular los impuestos correctamente
en el proceso de pago.
Cuando creamos estos servicios
de objetivo único
y los retiramos individualmente,
también decidimos
que solo podrían hablar entre sí
a través de la API del servicio web.
No se permitía el acceso
a datos compartidos de back-end.
Esto nos permitió crear
una arquitectura muy

English: 
it was frustrating our developers,
and most importantly
it was slowing down our software
development lifecycle,
it was slowing down our ability to innovate.
So, we made some changes and we made
a couple big ones.
The first was architectural.
We went through that monolithic application
and we teased it apart into a Service-Oriented
Architecture.
We went through the code and we pulled
out functional units
that served a single purpose, and
we wrapped those
with a web service interface.
So, some of these single-purpose
services that we pulled out,
some examples are one, whose sole job is was
to render the buy button correctly
on the product detail pages,
we also had a single-purpose service
whose sole job it was
to calculate the tax correctly on
the checkout process.
So, when we created these single-purpose services
and pulled them out individually,
we also had a rule that they could
only talk to each other
through their web service APIs.
There was no backend shared data
access allowed.
What this enable us is to create
a very highly

Chinese: 
而且让我们的开发人员感到沮丧，最重要的是，
它会拖慢我们的软件开发生命周期，
从而削弱我们的创新能力。
因此，我们做出了一些改变，一些大的改变。
首先是结构。
我们仔细检查整体应用程序，
我们将它划分到面向服务的架构中。
我们仔细检查代码并提取出具有单一用途的
功能单位，我们将其包含在
一个 Web 服务接口中。
我们提取出的部分单一用途服务，
部分示例的特点是，其唯一任务是
在产品详细信息页面上正确呈现购买按钮。
我们还具有单一用途服务，其唯一任务是
在结算流程中准确计算税款。
当我们创建这些单一用途服务并
将它们单独拉出时，
我们还有一个规则，它们只能通过其 Web 服务 API
相互交互。
不允许访问任何后端共享数据。
这使我们能够创建高度

Portuguese: 
era frustrante para os
desenvolvedores e, principalmente,
atrasava nosso ciclo de vida de
desenvolvimento de software.
Isso atrasava nossa capacidade de inovação.
Assim, decidimos que faríamos
duas mudanças principais.
A primeira foi de arquitetura
Aquela aplicação em bloco único
foi transformada em uma
arquitetura orientada a serviços.
Analisamos nosso código,
extraímos as unidades funcionais
que tinham uma única função
e as agrupamos em pacotes
com uma interface de serviço da Web.
Tenho um exemplo desses serviços
com uma única finalidade:
um deles tinha a única função
de renderizar o botão "Comprar" corretamente
nas páginas de detalhes do produto.
Havia outro serviço com a única tarefa
de calcular os impostos corretamente
na finalização da compra.
Quando criamos esses serviços de função única
e os extraímos individualmente,
estabelecemos uma regra:
eles só se comunicariam
por meio das suas APIs de serviço da Web.
Proibimos o acesso a dados
compartilhados de back-end.
Isso nos permitiu criar uma
arquitetura muito independente

English: 
decoupled architecture where these services
could iterate independently from each other
without any coordination between
those services
as long as they adhered to that standard
web service interface.
To give you an idea of what this
architecture looked like,
I've included this graphic.
And what this represents is the amazon.com
retail website
circa 2009, and all of these individual services
that made up that experience.
So, back then when we made this architectural shift
we didn't have this term,
but today we call this a microservices
architecture.
In addition to that architectural change
we also made an organizational change.
So, before, we had one central hierarchical
product development team.
We ended up teasing that apart as well
and we broke it down into small,
what we call, two-pizza teams.
And the idea behind that name is
that we wanted the teams
to be small enough so you could feed
them with just two pizzas.
Now, full disclaimer here, we're
really targeting around
six to eight developers per team,

Portuguese: 
onde esses serviços
podem se repetir de modo autônomo
sem a necessidade de coordenação entre eles,
contanto que eles se mantivessem
nessa interface de serviço da Web.
Para dar uma ideia da
organização dessa arquitetura,
incluí este gráfico.
Essa é a representação do website
de varejo amazon.com em 2009.
Todos os serviços individuais
compunham essa experiência.
Naquela época, esse novo
paradigma de arquitetura
ainda não tinha um nome.
Hoje, ela é chamada de
"arquitetura de microsserviços".
Além dessa mudança de arquitetura,
também implementamos uma
mudança organizacional.
Antes, tínhamos uma
hierarquia central dentro de
uma única equipe de
desenvolvimento de produtos.
Essa estrutura também foi desmontada
e recriada de um modo que chamamos
de "equipes das duas pizzas".
A ideia é que essas equipes
fossem enxutas o bastante
de modo que duas pizzas fossem suficientes
para elas na hora do intervalo.
Mas já aviso de antemão: idealmente, buscamos
seis ou oito desenvolvedores por equipe,

Spanish: 
desacoplada donde los servicios
podían iterar independientemente
sin necesidad de coordinarse,
siempre y cuando cumplieran con la
interfaz de servicio web estándar.
Para darles una idea
de la apariencia de esta arquitectura,
he incluido este gráfico.
Representa la web de venta minorista
de amazon.com
alrededor del 2009,
y todos los servicios independientes
que componían esa experiencia.
En aquella época,
cuando cambiamos la arquitectura,
no teníamos este término,
pero hoy lo llamamos una arquitectura
de microservicios.
Además del cambio en la arquitectura,
también hicimos un cambio organizativo.
Antes teníamos un único equipo de desarrollo
de producto jerárquico y centralizado.
Decidimos fragmentarlo
y lo dividimos en equipos pequeños,
lo que solemos llamar "equipos de dos pizzas".
Les pusimos ese nombre
porque queríamos que los equipos
fueran tan pequeños que pudieran comer
con solo dos pizzas.
Aquí debo hacer una aclaración:
pensábamos en equipos
de seis a ocho desarrolladores,

Chinese: 
分离的架构，其中这些服务
可单独相互迭代，
无需在这些服务之间进行协调，
前提是它们遵循标准 Web 服务界面。
为了向你解释这种架构，
我加入了这张图形。
它呈现的是 amazon.com 零售网站
circa 2009，以及构成该体验的
所有独立服务。
当我们进行此架构转变时，
这个词还未出现，
但今天我们将它称作微服务架构。
除了架构更改之外，
我们还进行了组织更改。
之前，我们有一个中央分层产品开发团队。
最终，我们将它细分
成多个小团队，并将它称作双披萨团队。
这个名称蕴含的意思是，希望团队
足够小，用两块披萨就能够喂饱它们。
现在，在这里发表完整的免责声明，我们的目标是
每个团队的 6 到 8 位开发人员，

English: 
so depending on how hungry your teammates are
your mileage may very on that name.
So, each of these two-pizza teams
was give full ownership
of one or maybe a few of these microservices,
and when I say full ownership I mean
everything.
They owned talking with their customers,
whether they be internal or external,
they owned defining their feature roadmap,
designing their features, implementing them,
writing the test for them, deploying
those services into production,
and also operating those services.
So, if anything went wrong anywhere
in that full lifecycle,
they were the ones accountable for fixing it.
If they chose to skimp on their testing
and were unknowingly releasing bad
changes into production,
they were breaking in the middle
of the night,
it was those same engineers that were paged
and had to wake up to fix it.
So, what that did is that it properly
aligned incentives
so the engineering team was fully motivated
to make the entire end to end lifecycle
operated efficiently.
So, again, we didn't have this term back then,

Spanish: 
pero el número de pizzas
depende del hambre que tengan los compañeros.
Así que dimos a estos "equipos de dos pizzas"
la responsabilidad total
de uno o varios microservicios,
y cuando digo total
me refiero a total y absoluta.
Sus responsabilidades consistían en hablar
con clientes, ya fueran externos o internos,
definir la estrategia de su función,
diseñar sus funciones, implementarlas,
preparar pruebas, implementar
esos servicios en producción,
y operar esos servicios.
De esta manera, si algo salía mal
en alguna fase del ciclo de vida,
ellos eran responsables de arreglarlo.
Si se les ocurría escaquearse al hacer pruebas
o si enviaban cambios mal hechos
a producción sin darse cuenta,
se les despertaba en mitad de la noche,
se les contactaba inmediatamente y
tenían que levantarse y arreglarlo.
Así conseguimos unificar incentivos
para que el equipo de ingenieros
estuviera motivado
y el ciclo de vida
funcionase de forma eficiente.
Por aquel entonces no teníamos este término,

Portuguese: 
então dependendo da fome dos colegas,
seu número de fatias pode variar.
Cada uma dessas equipes era
totalmente responsável
por um ou mais microsserviços,
e quando digo "totalmente
responsável", isso é para valer.
A equipe tinha que se
comunicar com os clientes,
fossem eles internos ou externos,
definir um mapa do produto,
criar e implementar os recursos,
criar os testes, implementar
os serviços na produção
e gerenciar a operação desses serviços.
Se algo desse errado em qualquer
parte daquele ciclo de vida,
eles eram responsáveis por corrigir o erro.
Se a equipe decidisse não fazer testes
e implementar alterações incompletas
que davam problemas no meio da madrugada,
eram os mesmos engenheiros da equipe
que tinham que acordar
para consertar os erros.
Isso fez com que os interesses se alinhassem.
Assim, a equipe de engenharia
estava totalmente motivada
a fazer com que todo o ciclo de
vida funcionasse com eficiência.
Repito: naquela época, o termo nem existia,

Chinese: 
根据你的队友的饥饿情况，
你的好处可能与该名称存在差异。
因此，每个双披萨团队都将提供一个或一些
微服务的完整所有权，
我所说的完整所有权是指一切所有权。
他们负责与其客户讨论，
无论他们是内部还是外部客户，
他们负责定义其功能路线图、
设计其功能、实现它们、
为功能编写测试，将这些服务部署到生产环境中，
以及运行这些服务。
如果完整生命周期中出现任何错误，
他们就是负责纠正错误的人。
如果他们选择草草应付其测试
并且不知不觉将不良更改发布到生产环境中，
他们需要半夜加班，
这同样是已联系并且必须起床
解决问题的工程师。
此团队所做的工作是正确调整激励措施，
充分调动工程团队的积极性，
以使整个端到端生命周期有效运行。
那时，这个词尚未出现，

Chinese: 
而今天我们称它为开发运营组织，
因为我们负责开发、测试
和运营以及将它们全部并入一个工程团队。
在我们进行结构和组织更改
这两项更改后，
我们大大改进了开发生命周期的前端。
这些小型双披萨团队能够快速做出决策、
为其微服务快速创建新功能，
但当他们将新功能部署到其客户时，
会出现问题。
在旧模式中，我们拥有一个中央工程小组，
该小组手动将整个应用程序
部署到生产机组中，这不适合此模式，
即我们的数千种微服务
都需要按其自己的时间表部署。
因此，工具方面就出现了缺口。
为了解决这个问题，我们启动了一个新的工具小组
来构建新类型的开发人员工具。
这些工具拥有一些独特的特征。
首先，它们必须是自助服务。
如果涉及任何处理任务，

Portuguese: 
mas hoje isso é o que chamamos
de organização de DevOps.
É uma forma de se responsabilizar
pelo desenvolvimento, pelos testes
e pelas operações de forma centralizada,
trabalhando como uma única equipe.
Depois de implementar
essas mudanças organizacional
e de arquitetura,
houve uma melhora sensível no front-end
do ciclo de desenvolvimento.
Essa pequenas equipes de duas
pizzas tinham autonomia para tomar
decisões e lançar novos recursos
do seu microsserviço com rapidez,
mas no momento de implementar
para os clientes,
tivemos um problema.
O modelo antigo com um grupo
de engenharia central
que implementava toda a aplicação manualmente
na fase de produção não era
compatível com o novo modelo,
que tinha milhares de microsserviços
para implementação em um
cronograma específico.
Dessa forma, tínhamos um
problema de ferramentas.
A solução foi montar um novo grupo para criar
uma nova geração de ferramentas
para os desenvolvedores.
Essa ferramentas têm características únicas.
Primeiro: elas tinham que
funcionar independentemente.
Não há como um único grupo de ferramentas

English: 
but today we'd call this a DevOps
organization
because we took those responsibilities
of development, and test,
and operations, and merged those
all onto a single engineering team.
So, after we made these two changes,
the architectural and organizational change,
we dramatically improved the front
end of that development lifecycle.
These small two-pizza teams were
able to quickly make decisions,
quickly crank out new features for
their microservice,
but when they went to deploy that
to their customers
we had a problem.
That old model where we had that
central engineering group
that manually deployed the entire
application out
to the production fleet, just would
not fit this model
where we had thousands of these microservices
all wanting to deploy on their own schedule.
So, we had a tools gap.
And to fix that, we started a new
tools group
that built a new breed of developer tools.
These tools had some unique characteristics.
The first is that they had to be
self-service.
There's just no way one tools group

Spanish: 
pero hoy lo llamamos una organización DevOps,
porque agrupamos las responsabilidades
de desarrollo, pruebas y funcionamiento
y las fusionamos
en un único equipo de ingeniería.
Después de hacer estos cambios,
el organizativo y el de arquitectura,
mejoramos la parte principal
del ciclo de vida de desarrollo.
Esos "equipos de dos pizzas"
podían tomar decisiones y
producir nuevas funciones rápidamente
para su microservicio,
pero cuando iban a implementarlas
para sus clientes,
teníamos un problema.
El antiguo modelo donde
un grupo central de ingenieros
implementaba manualmente
toda la aplicación
para la flota de producción,
no encajaba en este modelo
donde miles de microservicios
querían hacer la implementación
según su propia programación.
Resumiendo: nos faltaban herramientas.
Para solucionarlo,
creamos un grupo
que diseñase nuevas herramientas
para desarrolladores.
Estas herramientas tenían
unas características únicas.
La primera era que tenían que
ser de autoservicio.
Un solo grupo de herramientas

Portuguese: 
conseguir integrar milhares
dessas pequenas equipes
se isso envolver qualquer
grau de dependência.
Assim, esse grupo criou um portal na Web
que as equipes acessavam para conhecer
essas novas ferramentas. Elas
aprendiam os primeiros passos
e descobriam como provisionar
os recursos necessários
para usar as novas ferramentas.
Isso lembra bastante a essência do AWS,
que naquela época ainda nem existia.
Segundo: elas tinham que ser
compatíveis com todas as tecnologias.
As equipes tinham total autonomia
para tomar as decisões necessárias,
e elas usaram essa autonomia.
As equipes escolheram sistemas
operacionais, linguagens de programação
e estruturas de arquitetura diferentes
para implementar os serviços.
As ferramentas tinham que ser adaptáveis
para funcionar com essas
tecnologias diferentes.
Terceiro: queríamos que as ferramentas
incentivassem as práticas recomendadas.
Nós dividimos aquela equipe central
de desenvolvimento produtos
entre pequenas equipes autônomas,
mas queríamos que elas
compartilhassem os aprendizados.
E descobrimos que a maneira
mais eficaz de fazer isso

Spanish: 
no podía incorporar
a miles de "equipos de dos pizzas"
si tenían que ayudarles en todo.
Así que crearon un portal web
donde estos equipos podían informarse
sobre los nuevos servicios
de herramientas para desarrolladores,
podían ver cómo empezar,
y conseguir los recursos que necesitaban
para empezar a usarlos.
Se puede decir que era muy parecido a AWS,
antes de que se crease AWS.
La segunda: debían ser
independientes de la tecnología.
Habíamos dado total autonomía
a estos "equipos de dos pizzas"
para tomar las decisiones que quisieran
y la aprovecharon.
Usaban diferentes sistemas operativos,
lenguajes de programación, y marcos
y arquitecturas de aplicaciones diferentes
para implementar sus servicios.
Las herramientas tenían que ser adaptables
para trabajar
con todas esas tecnologías diferentes.
En tercer lugar, queríamos fomentar
las practicas recomendadas.
Aunque dividimos el equipo
de desarrollo de producto central
en "equipos de dos pizzas" autónomos,
queríamos que compartiesen sus conocimientos.
Y descubrimos que la forma
más efectiva de hacerlo era

English: 
would be able to onboard thousands
of these different two-pizza teams
if it involved any handholding.
So, what they did is they created
a web portal
where these teams could come learn
about these
new developer tool services, they
could figure out how to get started,
and they could also provision whatever
resources they needed
to start using it.
So, you can say this is very AWS-like
even before AWS had started.
Second, these tools had to be technology-agnostic.
We had given these two-pizza teams
full autonomy
to make whatever decision they wanted
and they took full advantage of that.
They chose different operating systems,
different programing languages,
architectures app frameworks to implement
their services.
So, the tools were going to have
to be adaptable enough so
that they could work with all of
these different technologies.
Third, we wanted these tools to encourage
best practices.
Even though we split that central
product development team
up into all of these autonomous two-pizza teams,
we still wanted them to share their learnings.
And we found the most effective way
of doing that is

Chinese: 
一个工具小组无论如何也无法充当数千种不同的
双披萨团队。
此小组所做的是创建一个 Web 门户
来让这些团队了解这些
新的开发人员工具服务，他们可以弄清如何开始，
并且可以预置开始使用服务所需的资源。
你可以说这非常像 AWS，甚至在 AWS 未开始之前也可这么说。
第二，这些工具必须与技术无关。
我们为这些双披萨团队提供了完全自主权，
以便他们做出所需的决策
并充分利用此权限。
他们选择不同的操作系统、不同的编程语言、
架构应用程序框架来实现其服务。
因此，工具必须完全适应，
它们可与所有不同的技术配合使用。
第三，我们希望这些工具能够支持最佳实践。
即使我们将中央产品开发团队
拆分为所有这些自主的双披萨团队，
我们仍希望他们分享其知识。
我们发现，最有效的分享方式是，

English: 
that if a team learned a best practice,
we would take that an bake it into
the toolset
and that made it very easy for other teams
to both discover this new best practice
as well as to adopt it themselves.
And finally, you can say we drank
the microservices Kool-Aid,
and just as we were teasing apart
the website architecture,
we didn’t want to deliver an end
to end tool chain
that was very tightly coupled together,
we wanted to deliver it as these
functional building block units
that the teams could pick the pieces
that worked best for them
and then tie them together in the
way they wanted.
So, I want to talk about a couple of these
building block tool services that
we use internally at Amazon.
The first is Apollo, which is our
deployment engine.
Its job is essentially to get bits
onto a box.
We've been using Apollo to deploy
the retail website
for over a dozen years now,
and we also use it to deploy our
Amazon Web Services.
And over that time we've learned a lot
about how to do deployments well.

Portuguese: 
é quando uma equipe percebe
uma prática recomendada
e consegue transformá-la em ferramentas
que facilitam o aprendizado
dessa prática pelas outras equipes,
além de facilitar a adoção para todos.
Assim, podemos dizer que compramos
a ideia dos microsserviços.
Ao destrinchar a arquitetura do website,
não queríamos criar uma cadeia end-to-end
que fosse totalmente integrada,
mas criar unidades autônomas funcionais,
como peças que as equipes usassem
da melhor maneira possível
e combinassem como desejado.
Portanto, quero falar sobre esses serviços
em forma de blocos independentes
que usamos internamente na Amazon.
O primeiro deles é o Apollo,
nosso mecanismo de implantação.
A função dele é basicamente juntar as peças.
Estamos usando o Apollo para
implementar o website de varejo
há mais de doze anos,
e também o usamos para implementar
os Amazon Web Services.
Ao longo desse período, aprendemos bastante
sobre como fazer
implementações de modo eficaz.

Chinese: 
如果一个团队学到了一个最佳实践，
我们会将该最佳实践放入工具集中，
并使其他团队能够轻松
发现此新的最佳实践
并自行采用。
最后，你可以说我们已经离不开微服务了，
就像我们分离网站架构一样，
我们不需要交付端到端的工具链，
此链是紧密结合的，
我们需要将它作为这些功能构建基块单元交付，
以便团队能够选取最适合他们的部分，
然后按他们所需的方式关联它们。
我想谈谈我们在 Amazon 内部
使用的一些构建基块工具服务。
第一个是 Apollo，它是我们的部署引擎。
其任务主要是将位获取到框中。
十几年来，我们一直使用 Apollo 部署零售网站，
我们还使用它部署我们的 Amazon Web Services。
经过这十几年的时间，我们已了解
如何执行部署。

Spanish: 
que el equipo conociera
una práctica recomendada,
nosotros la incluiríamos
en el conjunto de herramientas,
y eso permitiría que otros equipos
descubrieran esta práctica
y la incorporasen.
Finalmente, nos tuvimos que tragar
la idea de los microservicios,
pero cuando estábamos fragmentando
la arquitectura de la web,
no queríamos producir
una cadena de herramientas integral
que estuviera muy vinculada entre sí,
queríamos producir
unidades de componentes funcionales,
que los equipos pudieran aprovechar
las partes que más les interesaran,
y que luego las vincularan como quisieran.
Ahora les hablaré de los servicios
de herramientas en forma de componentes
que utilizamos en Amazon.
El primero es Apollo,
nuestro motor de implementación.
Su tarea consiste en colocar
piezas en una caja.
Usamos Apollo para implementar
el sitio web de venta
desde unos doce años,
y también lo usamos
para implementar Amazon Web Services.
En este tiempo hemos aprendido muchas cosas
sobre implementaciones.

Portuguese: 
Nós aproveitamos esses aprendizados
para aperfeiçoar a ferramenta.
Uma das melhorias foi a capacidade de
implementação sem gerar tempo de inatividade.
Como você podem imaginar, não é
possível desativar o website de varejo
quando bem entendemos para implementar
alguma alteração de código.
Por isso, criamos o recurso
de atualizações graduais.
Durante a atualização
dos servidores da aplicação,
o Apollo atualiza
somente alguns deles de cada vez.
Assim, ele vai atualizando
os servidores gradualmente
até que todos eles estejam
operando com a nova versão da aplicação.
Também adicionamos um
recurso para acompanhar a
integridade do código, pois,
embora seja algo raro,
às vezes uma alteração indesejada
do código passa pelos testes
e chega à fase de produção.
E precisamos assegurar que
esse alteração indesejada
do código não afete todo
o sistema de servidores.
Durante o lançamento da atualização,
se o Apollo detectar erros ou
falhas nos serviços implementados,
ele automaticamente para o processo
e impede a continuação da atualização.

Spanish: 
Y hemos revertido toda esa experiencia
en la herramienta.
Una de las características es poder
implementar sin tiempo de inactividad.
Como se pueden imaginar, no podemos bloquear
la web de ventas cuando queramos
para cambiar el código.
La solución fueron
las "actualizaciones acumulativas".
Cuando Apollo actualiza
una flota de servidores de aplicaciones,
solo actualizará una pequeña parte cada vez,
y luego avanzará por la flota
hasta implementar la nueva versión de la
aplicación en toda la flota de servidores.
También añadimos la función
de seguimiento de estado,
porque aunque ocurre pocas veces,
puede que, al cambiar código, un error
se cuele de la fase de pruebas
a la de producción
y nos queremos asegurar de que
ese cambio de código
no repercuta en toda la flota.
Cuando Apollo hace
estas actualizaciones acumulativas,
si detecta errores o fallos
en los servicios que ha implementado,
cortará y detendrá
automáticamente la implementación.

Chinese: 
我们已利用学到的知识并将它们融入此工具中。
其中一个特点就是能够在不停机的情况下执行部署。
可想而知，当我们需要推送
代码更改时，将无法停止零售网站，
因此我们提出了一项称为滚动更新的功能。
Apollo 的作用是，在它更新
一组应用程序服务器时，它一次将
仅更新一小部分服务器，
然后慢慢增加更新工作量，
直至将整队服务器
更新到新版应用程序。
我们添加的另一种功能是运行状况跟踪，
不良代码更改很少出现，
它偶尔会出现在测试期间
并应用于生产环境中。
我们需要确保不良代码更改
不会导致整队服务器停机。
当 Apollo 执行此滚动更新时，
如果它在所部署到的服务器上检测到错误或故障，
它将自动切断部署
并阻止部署继续进行。

English: 
And we've taken those learnings and
we've baked them back into the tool.
One of those features is the ability
to deploy without any downtime.
So, as you can imagine, we're not
allowed to take down
the retail website any time we want
to push a code change,
so we came up a feature called rolling updates.
And what Apollo will do is when it's updating
a fleet of application servers, it's
only going to
update a small fraction of those at a time
and then incrementally work its way
across the fleet
until it brings the whole fleet of servers
up to the new version of the application.
Another feature that we added was
health tracking,
and that's because it happens rarely,
but occasionally a bad code change
can make its way through testing
and roll out into production.
And what we want to make sure is
that that bad code change
is not going to take down the entire fleet.
So, as Apollo is doing this rolling update,
if it detects errors or failures
on the services that it deployed to,
it will automatically cut off that deployment
and stop it from progressing further.

English: 
And since Apollo versions these deployments,
it makes it real easy for a developer
to roll back
to a past known good version of that
application.
Next service I want to talk about
is Pipelines,
which is our internal continuous
delivery engine.
So, even after we built Apollo and
had automated deployments
we still noticed that it took a long
time for a code change
to go from a developer check in
to be running in production where
customers could use it.
So, being a data driven company we
did a study on that
and we measured the amount of time
it took a code change
to make its way through that deployment lifecycle
across a number of teams.
When we added up that data and looked
at the results
and saw the average time it took,
we were frankly embarrassed.
It was on the order of weeks.
So, we dug into that data and we
looked exactly for detailed breakdowns
how long it was taking at the different steps.
And what we saw, it wasn't so much
the duration
of any one of those actions, it wasn't
the duration of a build,

Portuguese: 
Como as implementações são feitas em versões,
fica mais fácil para o desenvolvedor
voltar à última versão
válida daquela aplicação.
O próximo serviço que
apresento é o Pipelines,
que é nosso mecanismo interno
de entrega contínua.
Mesmo após criar o Apollo e as
implementações automatizadas,
percebemos que levava muito tempo
para que uma alteração de código
fosse verificada pelo desenvolvedor
e passasse à produção para uso dos clientes.
Como acreditamos em dados,
fizemos um estudo para avaliar
o período necessário para
uma alteração de código
completar todo o ciclo de
vida da implementação,
passando por várias equipes.
Quando coletamos os dados e
analisamos os resultados,
chegamos ao tempo médio e, honestamente,
nos sentimos envergonhados.
Era algo em torno de semanas.
Decidimos então investigar
os dados e ver em detalhes
quanto tempo levava cada uma das etapas.
Percebemos que o problema não era a duração
dessas ações, nem tampouco
do desenvolvimento,

Spanish: 
Como Apollo hace versiones
de las implementaciones,
para el desarrollador es muy fácil
volver a la versión correcta
más reciente de la aplicación.
Ahora hablaré de nuestro servicio
de canalizaciones,
nuestro motor interno
de entrega continua.
Tras diseñar Apollo y automatizar
las implementaciones, vimos que
pasaba demasiado el tiempo
desde el cambio de código
a la comprobación del desarrollador
y su ejecución en producción,
donde lo aprovecharían los clientes.
Al ser una empresa basada en datos,
hicimos un estudio
y analizamos el tiempo
que tardaba un cambio de código
en completar el ciclo de vida de
implementación en varios equipos.
Cuando añadimos los datos
y vimos los resultados
y la media de tiempo necesario,
nos dio verdadera vergüenza.
Eran semanas.
Así que analizamos los datos y
buscamos análisis detallados
del tiempo necesario en cada paso.
Vimos que el problema no era la duración
de las acciones, la duración del montaje,

Chinese: 
由于 Apollo 对这些部署进行版本控制，
使开发人员能够轻松地回滚
到应用程序过去已知的良好版本。
我要介绍的下一个服务是 Pipelines，
它是我们内部的持续交付引擎。
即使在我们构建 Apollo 并实现部署自动化之后，
我们仍发现代码更改从开发人员签入
到能够在可供客户使用的
生产环境中运行需要很长一段时间。
作为一家数据驱动型公司，我们对此进行了研究，
我们计算了许多
团队的代码更改在部署生命周期内
生效的时间。
当我们汇总相关数据并查看结果时，
此过程所花费的平均时间令我们感到非常尴尬。
这是按周的顺序排列的。
我们深入探究相关数据，并了解各个步骤
所花时间的详细细分。
我们发现，这些操作中任一操作的
持续时间都不长，它没有构建持续时间、

English: 
or the duration of a test run, or
the duration of a deployment,
it was all of this dead time in between.
We had a bunch of inefficient manual handoffs
where after one task was run, a person
would take that
and then notify another person that
the next job is ready to run.
And that usually happened in the
form of an e-mail,
it could be cutting a ticket, but
these requests
were sitting in these queues and
sitting idle for a very long time.
And for a company like Amazon that
prides itself on efficiency,
for a company that uses robots inside
of our fulfillment centers
to move around physical goods, a
company that wants
to deploy packages to your doorstep
using drones,
you could imagine how crazy it was
that we're using humans
to pass around these virtual bits
in our software delivery process.
So, we had to fix that, and we did
that using Pipelines.
Pipelines allowed these teams to
model out their complete
and end release process.
They could specify how they wanted
their source code changes
to be automatically built and unit tested,

Spanish: 
la duración de una ejecución de prueba
ni la de una implementación,
sino el tiempo de inactividad entre estos pasos.
Hubo varias entregas manuales ineficientes
donde después de terminar una tarea,
una persona se encargaba de notificar
a otra que podía pasar a la siguiente tarea.
Lo hacíamos casi siempre por correo
electrónico, con un ticket, pero estas
peticiones se quedaban en la cola y
permanecían inactivas durante mucho tiempo.
Para una empresa como Amazon
que se enorgullece de su eficiencia,
que utiliza robots en sus
centros de distribución
para transportar mercancías, que quiere
llevar paquetes a la casa
de sus clientes con drones,
se podrán imaginar
lo que nos gustaba usar a personas
para distribuir estas piezas virtuales
en nuestro proceso de entrega de software.
Había que encontrar una solución:
fueron las canalizaciones.
Las canalizaciones permitían
que estos equipos modelasen
su proceso de lanzamiento integral.
Podían especificar cómo querían
que se integrasen los cambios
de código fuente de manera
automática y probados en la unidad,

Chinese: 
测试运行持续时间或部署持续时间，
它包含这三者之间的所有停滞时间。
我们有一堆低效的手动交接，
其中一个任务运行后，一个人将负责接手，
然后通知其他人下一个作业已准备运行。
一般通过电子邮件方式通知，
可能会缩减计划，但这些请求
位于这些队列中并在很长一段时间内保持空闲状态。
对于像 Amazon 这样以效率为傲的公司，
我们在运营中心内使用
机器人搬动物质产品，希望
使用无人机将包裹送至你的门口，
你可以想象得到，我们在软件交付流程中
使用人力来传递这些虚拟部分是多么疯狂。
我们必须解决这个问题，我们已使用 Pipelines 解决这个问题。
Pipelines 允许这些团队模制其完整的
最终发布流程。
他们可指定其希望其源代码更改
的自动构建和单元测试方式，

Portuguese: 
nem a duração dos testes ou da implementação,
mas sim todo o tempo de
inatividade entre essas tarefas.
Tínhamos vários relatórios
manuais burocráticos
para notificar sobre uma tarefa concluída
e avisar as outras pessoas sobre
a próxima etapa a ser cumprida.
Isso normalmente era feito
na forma de um e-mail.
Podia ser muito mais
prático, mas a verdade é que
essas solicitações formavam uma
fila e aguardavam muito tempo.
E para uma empresa como a Amazon,
que se orgulha de ser eficiente,
uma empresa que usa robôs para transportar
os produtos físicos nos estoques,
uma empresa que quer entregar
as encomendas na porta do
cliente usando drones,
percebemos que é uma loucura
contar com seres humanos
para processar as informações virtuais do
nosso processo de entrega de software.
Então, para consertar essa
situação, criamos o Pipelines.
O Pipelines permite que as equipes simulem
o processo final de liberação.
Ele especifica como as principais
alterações do código-fonte
serão criadas e testadas automaticamente,

Spanish: 
cómo querían que se implementasen
en los entornos de prueba,
qué tipo de pruebas se iban
a ejecutar en ellos,
y cómo querían llevar esos cambios
a la implementación de producción.
Una vez perfeccionado el
proceso de lanzamiento,
las canalizaciones se encargarían
automáticamente de los cambios de código
y los conducirían
a lo largo del proceso de lanzamiento.
Dinamizan automáticamente las versiones,
comprueban los resultados automáticamente,
y los envían al siguiente paso
para los equipos de desarrollo.
Cuando implementamos las canalizaciones
y se incorporaron internamente,
observamos clara una mejora
en la velocidad de lanzamiento de software.
Pero también observamos otra mejora
que no esperábamos.
Los lanzamientos de los equipos
con canalizaciones totalmente
automatizadas eran más fiables
que los que realizaban pruebas
o aplicaban pasos manuales.
Eso era poco intuitivo, al principio.
Pensábamos que si una persona
tomaba decisiones inteligentes
y analizaba detalladamente el lanzamiento,

Portuguese: 
como elas devem ser implementadas
nos ambientes de testes,
quais testes devem ser
realizados nesses ambientes
e como essas alterações
devem prosseguir para a etapa de produção.
Depois de simular todo o
processo de liberação,
o Pipelines gerencia automaticamente
todas essas alterações de códigos,
distribuindo-as pelo planejamento
de todo o processo de liberação.
Ele dispara as versões,
verifica os resultados e
prossegue para a próxima etapa,
e faz tudo isso automaticamente.
Quando implementamos o Pipelines e ele
passou a ser adotado internamente,
vimos uma melhora sensível na
velocidade de lançamento dos softwares.
Mas também observamos outro
benefício inesperado.
Verificamos que as equipes que usavam
todo o potencial da ferramenta
faziam entregas mais confiáveis
do que aquelas que adotavam
etapas manuais no processo.
E, a princípio, isso pareceu contraintuitivo.
Nós imaginávamos que um ser humano
poderia tomar decisões inteligentes
e ter uma dose extra de
cuidado com o produto,

English: 
how they wanted those to then be
deployed to their test environments,
what tests they wanted to run on
those in those environments,
and then how they wanted those changes
to move out into a production deployment.
After they modeled out that release process,
Pipelines would automatically handle
all those code changes
and marshal all those code changes
through the release process for them.
So, it automatically trigger off
the builds,
automatically checked the results,
and automatically move it off
to the next step for the development teams.
So, when we implemented Pipelines
and it began to be adopted internally,
we saw dramatic improvement in the
speed of these software releases.
But we also saw another improvement
that we didn't expect.
We saw that the teams that had fully
automated Pipelines
had actually more reliable releases than those
that had manual tests or manual steps involved.
And that was a little unintuitive at first.
We thought that if you put a human
who can make intelligent decisions
and an extra scrutiny on your release,

Chinese: 
希望如何将源代码更改部署到其测试环境，
希望在这些环境中运行什么测试，
以及希望这些更改
如何移至生产部署中。
在他们模制发布流程之后，
Pipelines 将自动处理所有代码更改，
并通过发布流程封送所有代码更改。
这将自动触发构建，
自动检查结果并为开发团队
自动移至下一步。
当我们实现 Pipelines 并且已在内部开始采用它后，
我们发现这些软件发布的速度已显著加快。
而我们还看到另一个意外的改进。
我们发现，已完全实现 Pipelines 自动化的团队的
发布实际上比包含手动测试或手动步骤的
团队的发布更可靠。
最迟并不知道这一点。
我们认为，如果你安排人员做出明智决策
并额外监视你的发布，

English: 
that might help make a release more reliable,
but what we saw was the opposite.
What we saw is that the teams that
fully dedicated themselves
to making sure every validation step
that they wanted
was baked into an automated test,
we saw that those teams had more
reliable releases
that required less roll backs and
had less deployment errors.
So, with these two advantages of
having faster
and more reliable releases, it's
been incredibly successful
inside of Amazon and is used pervasively
across the different teams.
Now, after adding these two tools
for automated deployments
and continuous deliver, we fully
unblocked these two-pizza teams
from operating independently.
So, now these teams can decide what
features they want to work on,
implement those features on their
own schedule
and now they're completely unblocked
to push those changes
to their customers through their
own delivery Pipeline.
When customers ask me how it is that
Amazon is able to move so fast,
this is the answer I give them,
even though from the outside it might
look like Amazon

Portuguese: 
e que isso daria uma maior confiabilidade,
mas constatamos o contrário.
O que observamos foi que
algumas equipes faziam questão
de garantir todas as etapas
de validação desejadas
com um teste automatizado.
No fim do processo, essas equipes
tinham produtos mais confiáveis,
com uma menor necessidade de ajustes
e menos erros de implementação.
Com a vantagem de criar produtos
mais rápidos e confiáveis,
essa ferramenta fez muito
sucesso internamente na Amazon,
com grande frequência de uso
por várias equipes diferentes.
Após criar essa duas ferramentas
para automatizar as implementações
e otimizar a produção, as equipes
autônomas ficaram livres
para operar de modo independente.
Agora, cada equipe escolhe os recursos
nos quais desejam se concentrar,
implementa esses recursos de
acordo com seu próprio cronograma
e está completamente livre
para apresentar as alterações
para os clientes usando seu
próprio planejamento de entrega.
Quando os clientes me perguntam como
a Amazon consegue ser tão ágil,
eu já tenho a resposta:
de fora, parece que a Amazon

Chinese: 
可能有助于提高发布的可靠性，
但我们看到的情况恰恰相反。
我们发现，完全致力于确保
执行所需的每个验证步骤的团队受到
自动化测试的支持，
我们发现这些团队具有更可靠的且
很少需要回滚的发布，并且具有很少的部署错误。
由于实现更快且更可靠的发布
可获得两个优势，因此在 Amazon 内部取得
难以置信的成功并且在各个团队中广泛使用。
在为自动化部署和持续交付
添加这两个工具后，我们彻底扫清了这些双披萨团队
独立运营的障碍。
现在，这些团队可决定要使用的功能，
按其时间表实现这些功能，
并通过其自己的交付管道
轻松将更改推送给其客户。
当客户问我 Amazon 为何能够发展这么快时，
这就是我的答案，
即使从外部看，Amazon 是一个

Spanish: 
ese lanzamiento sería más fiable,
pero vimos que en realidad
ocurría lo contrario.
Observamos que los lanzamientos
de los equipos que se aseguraban
totalmente de que cada paso
de validación que querían
se respaldaba con una prueba automática,
eran más fiables, requerían menos
reversiones a versiones antiguas y
tenían menos errores de implementación.
De modo que estas dos ventajas
de tener lanzamientos
más rápidos y fiables,
han resultado muy exitosas
en Amazon, y se utilizan de manera
generalizada en distintos equipos.
Tras añadir estas dos herramientas
para implementación automática
y entrega continua, dejamos
libres a esos "equipos de dos pizzas"
para poder trabajar de forma independiente.
Ahora podían decidir en qué
funciones querían trabajar,
implementar las funciones
según sus propios tiempos,
y ya eran totalmente libres
para hacer cambios
para sus clientes mediante su
propia canalización de entrega.
Cuando los clientes me preguntan
cómo es posible que Amazon sea tan rápido,
siempre les respondo que
aunque desde fuera parezca que Amazon

Spanish: 
es una organización grande
con sobrecarga de trabajo,
por dentro es más como
muchos equipos de arranque
que funcionan y se organizan
eficazmente, y se mueven
lo más rápido posible.
Hay formas muy distintas
de medir el éxito.
Una de ellas, de la que ya
hemos hablado públicamente,
es contar las implementaciones por año.
Cuando tienes miles
de "equipos de dos pizzas"
trabajando en microservicios,
realizando entregas continuas
en muchos entornos de desarrollo,
pruebas y producción,
todo se multiplica
hasta llegar a una locura de implementaciones.
El año pasado, en 2014,
en un plazo de 12 meses,
hicimos 50 millones de implementaciones.
La media resultante es una implementación
y media cada segundo.
Es una cifra increíble,
y sirve para mostrar
cómo Amazon acelera el ciclo de vida
de desarrollo del software.
Pero cuando le contamos esto a los clientes,

English: 
is a large organization that might
have some internal overhead,
on the inside we're really structured like
a bunch of small startup teams that
are all operating and organized
very efficiently and moving as fast
as they can.
So, there are a lot of different
ways that we can measure success here.
One of the ways is - that we've talked
about publicly -
is how many deployments we do each year.
So, when you have thousands of these
two-pizza teams
that are working on these small microservices,
practicing continuous deliver across
multiple Dev, test,
and production environments, that
multiples out
to an insane number of deployments.
So, last year in 2014, just during
a 12 month period,
we did over 50 million deployments.
That averages out to be a deployment
and a half every second.
So, that's an incredible number,
and it just shows you how quickly
that Amazon is turning the crank
on that software development lifecycle.
Now, when we tell customers this story,

Chinese: 
大型组织，可能有一些内部开销，
而在内部，我们的结构就像是
一群小型初创公司团队，他们非常有效地运营和
组织并且尽力快速发展。
可以通过许多不同的方式来衡量成功。
一种方式是我们每年的部署次数，
我们之前已公开讨论过此方式。
当你有数千个双披萨团队
处理这些小型微服务时，
跨多个开发、测试和生产环境
执行持续交付会将部署数增加一倍。
去年，也就是 2014 年，仅仅 12 个月的时间，
我们就部署了 5000 万次以上。
平均每半秒部署一次。
这是数字令人难以置信，它向你展示了
Amazon 在软件开发生命周期内的转变有多快。
现在，当我们告诉客户这个案例时，

Portuguese: 
é o tipo de empresa grande que
tem custos indiretos internos.
Mas, na verdade, somos organizados em equipes
que se parecem com um grupo de startups,
com operação e organização eficientes
e a maior agilidade possível.
Assim, existem várias métricas
para avaliar nosso sucesso.
Uma delas, e falamos sobre isso publicamente,
é o número de implementações
realizadas por ano.
Quando você tem milhares
de miniequipes autônomas
que se concentram nos microsserviços
e fazem entregas contínuas em vários
ambientes de desenvolvimento,
teste e produção, o resultado é
um número insano de implementações.
Em 2014, durante um período de 12 meses,
fizemos mais de 50 milhões de implementações.
Em média, isso representa uma
implementação e meia por segundo.
É um número incrível, que mostra
a agilidade com que a Amazon
encara o ciclo de vida de
desenvolvimento de software.
Quando compartilhamos isso com os clientes,

Portuguese: 
normalmente a próxima pergunta é: "como
podemos fazer o mesmo na nossa empresa?".
Não quero fazer simplificações rasas,
essa resposta é bastante complexa.
A empresa precisa adotar mudanças
culturais, organizacionais e de processo.
Dito isso, preciso dizer que não há uma
única resposta para todas as empresas.
Todas elas terão que fazer escolhas
e encontrar suas próprias soluções
que se adequem às suas necessidades
e contextos particulares.
Mas há um elemento básico comum
necessário para qualquer
transformação de DevOps:
um planejamento de entrega
contínuo, eficiente e confiável.
E é sobre isso que quero falar no
restante da minha apresentação.
O que é necessário para criar um
planejamento de entrega contínuo?
Existem alguns requisitos.
O primeiro é o mais importante:
você definitivamente precisa ter
implementações totalmente automatizadas.
O motivo é que você fará
muitas implementações.
Para cada produto que você entregar,
será necessário implementá-los
várias vezes no ambiente de
testes durante a etapa de
correção de erros e repetição.

Chinese: 
他们通常会问他们如何才能做到这一点。
这种情况下我不会将答案过于简单化，
因为答案非常复杂。
公司需要着眼于文化更改、组织更改、
流程更改，每家公司的答案不一样。
所有人都会选择适合其特殊需求和环境的解决方案，
并且对其解决方案有自己的主观意见。
但有一个通用构建基块，
每个开发运营转型都需要此基块，并且
具有有效且可靠的持续交付管道。
这是我在本次演讲的剩余时间内要谈到的内容。
设置持续交付管道需要什么？
嗯，有一些设置要求。
第一个要求最重要，那就是
你绝对需要具有完全自动部署。
这是因为你将进行大规模部署。
你拥有的面向客户的每次发布，
在你调试和迭代时
必须多次部署到

Spanish: 
la siguiente pregunta suele ser
"cómo podrían hacerlo ellos".
No voy a simplificar las cosas
porque es una respuesta compleja.
Una empresa debe pensar en cambios
organizativos, culturales y
de proceso, y no hay una única respuesta
válida para cada empresa.
Todos quieren elegir y aportar
su toque personal en la solución,
para que se adapte
a sus necesidades y su entorno.
Pero hay un elemento común
y necesario en toda transformación de DevOps:
una canalización de entrega continua,
eficiente y fiable.
Y de eso me gustaría hablar
durante el resto de la charla.
¿Qué se necesita para crear
una canalización de entrega continua?
Hay algunos requisitos.
El primero y más importante es que
hay que tener implementaciones
completamente automatizadas.
Porque va a haber
muchas implementaciones.
Cada lanzamiento que tenga para un cliente,
tendrá que realizar varias implementaciones
en un entorno de pruebas
para resolver problemas

English: 
typically the next question they
as is how can they do it themselves.
And I'm not going to over simplify
things here
because it is a very complex answer.
A company needs to look at cultural
changes, organizational changes,
process changes, and there's not
one right answer for every company.
Everyone's going to choose and have
their own twist on their solution
that will adapt their particular
needs and environment.
But there is one common building block
that every DevOps transformation
needs, and that is
to have an efficient and reliable
continuous delivery pipeline.
And that's what I want to talk about
for the rest of this talk.
So, what does it take to set up a
continuous delivery pipeline?
Well, there's a few requirements for it.
The first is the most important,
and that is
that you absolutely need to have
fully automated deployments.
That's going to be because you're
going to deploy a lot.
Every release that you have to customers,
you're going to have to deploy multiple times
to your testing environment when
you're debugging it

Spanish: 
y hacer iteraciones, luego
tendrá que implementarlo
en el entorno de ensayo
y comprobar que no haya regresiones,
y luego tendrá que implementar la versión en
producción, donde los clientes podrán usarla.
Si hay pasos manuales en el proceso,
no solo irá todo más lento,
sino que le hará implementar
y lanzar menos a menudo.
Una vez haya configurado
las implementaciones
automatizadas, lo siguiente
será intentar vincular
y automatizar su proceso
de lanzamiento de software.
Es importante que los cambios en el código
fuente se integren automáticamente,
se implementen automáticamente
en sus entornos de prueba,
se pongan en marcha automáticamente
todas las series de pruebas
y finalmente pasen a producción.
Ahora bien, no pasa nada si hay
algunos pasos manuales aquí.
Casi todos los clientes, cuando empiezan,
van a tener pasos manuales,
pero con el tiempo,
a medida que vayan madurando,
querrán que todas esas acciones manuales,
esas validaciones manuales, se conviertan
en pasos automatizados en
la medida de lo posible.

Chinese: 
测试环境，然后你需要将它部署
到你的过渡环境以运行测试
来确保无回归，
之后你将它部署到生产环境
来供你的客户最终使用。
如果此流程中有任何手动步骤，
不仅会减慢速度，而且会促使你
减少部署和发布。
在你设置自动化部署后，
接着要做的是尝试关联
软件发布流程并实现此流程的自动化。
你希望你的源代码更改自动构建，
自动部署到你的测试环境，
自动触发所有测试运行，
并最终进入生产使用。
现在，如果你有一些手动步骤也没关系。
几乎所有客户最初
都有手动步骤，但随着时间的推移，
当你成熟后，你将需要采用拥有的任何手动操作
和手动验证，并尝试将它们尽力
转换为自动化步骤。

English: 
and iterating, then you're going
to need to deploy it
to your staging environment to run tests
to make sure there's no regressions,
then you're going to deploy it to production
where your customers can finally use it.
If there are any manual steps in
this process,
it's not only going to slow you down,
but it's going to incent you
to deploy and release less often.
So, after you set up automated deployments,
the next thing you're going to do
is try to tie together
and automate your software release process.
You want your source code changes
to automatically be built,
automatically be deployed to your
test environments,
automatically trigger off all of
your test runs,
and finally move into a production
employment.
Now, it's going to be okay if you
have some manual steps here.
Almost all customers, when they're
starting off,
are going to have manual steps, but over time,
as you mature here, you're going
to want to take any manual actions,
and manual validations that you have,
and try to convert those
into automated steps as much as you can.

Portuguese: 
Depois, você precisará implementá-los
no ambiente de preparação
para realizar testes
e descartar o risco de regressão.
Depois, você implementará
no ambiente de produção,
onde o produto será usado pelo cliente.
Se houver etapas manuais nesse planejamento,
o processo ficará mais lento
e você terá menos tempo para
implementar e entregar o produto.
Depois de configurar as
implementações automatizadas,
a próxima etapa é tentar unificar
e automatizar o processo
de liberação do software.
Convém que as alterações do
código-fonte sejam realizadas,
implementadas nos ambientes de teste
e disparem todos os testes,
tudo isso automaticamente.
Depois disso, você implementa essas
alterações no ambiente de produção.
Neste ponto, não haverá problema
se você usar etapas manuais.
Quando estão começando,
quase todos os clientes
usam etapas manuais, mas ao longo do tempo,
à medida que você ganhar experiência,
convém converter o máximo possível
as ações e validações manuais
em processos automatizados.

Spanish: 
Nosotros tenemos herramientas y servicios
que sirven para eso.
Tenemos CodeDeploy,
para implementaciones automatizadas;
CodePipeline, para automatización
del lanzamiento integral,
y si quiere pasar su código
fuente a la nube
para tener toda su canalización,
todo desde el origen,
la integración, la creación,
las fases de prueba hasta la
producción, si quiere que toda su
canalización esté alojada en AWS,
puede usar CodeCommit para almacenar
también su código fuente.
Ahora voy a presentar brevemente
estos tres servicios,
y quiero hacerlo muy rápido
para dejar tiempo
para que Clare les haga
una demostración detallada
e interesante
de cómo es hacer uso de estos servicios.
El primer servicio del que voy a hablar
es CodeDeploy.
CodeDeploy funciona como Apollo.
Primero hay que especificar qué versión
de su aplicación quiere implementar y
en qué grupo de servidores,
y el servicio gestionará
la distribución por usted.
Comparte las funciones de Apollo
con actualizaciones acumulativas

Chinese: 
因此，我们有一些工具和服务可帮助你做到这一点。
我们有 CodeDeploy，你可将其用于自动化部署，
有 CodePipeline，你可将其用于端到端的发布自动化，
如果你需要将你的源代码移至云，
以便获得整个管道，从源到
构建到测试阶段再到生产的一切内容，
如果你希望你的整个管道托管在 AWS 中，
则还可使用 CodeCommit 存储你的源代码。
我现在将为你快速
介绍一下这三种服务，
我想快点介绍，因为我要节省时间，
以便 Clare 为你提供一个精彩而深入的巡回演讲，
演讲内容关于在演示中使用这三种服务。
我要谈论的第一个服务是 CodeDeploy。
CodeDeploy 的工作原理与 Apollo 的类似。
你指定要部署到
目标服务器组的应用程序的版本，
它将为你处理后面的工作。
它具有与带滚动更新的 Apollo 相同的功能，

Portuguese: 
Temos algumas ferramentas e
serviços que podem ajudar você.
Por exemplo, o CodeDeploy, para uso
em implementações automatizadas.
Temos também o CodePipeline, usado
na automação da liberação final.
Alguns clientes preferem levar o
código-fonte deles para a nuvem,
para ter todo o planejamento
hospedado no AWS,
desde as etapas iniciais até a criação,
passando pelos testes e pela produção.
Se for seu caso, use o CodeCommit para
também armazenar seu código-fonte.
Agora, quero fazer uma breve apresentação
desses três serviços.
Farei isso rapidamente
porque não quero invadir
o tempo da Clare, que fará uma demonstração
para ensinar vocês a usar
todos esses serviços.
O primeiro serviço que quero
mostrar é o CodeDeploy.
Ele funciona de maneira
parecida com o Apollo.
Você especifica que versão do seu aplicativo
deseja implementar em
qual grupo de servidores
e ele cuida do processo para você.
Ele tem os mesmos recursos de
atualizações graduais do Apollo

English: 
So, we have a few tools and services
that can help you out here.
We have CodeDeploy, which you can
use for automated deployments,
CodePipeline that you can use for
end to end release automation,
and then if you want to move your
source code to the cloud
so that you have your entire pipeline,
everything from source,
to build, to your test stages, to
production,
if you want your entire pipeline
hosted in AWS,
you can use CodeCommit to store your
source code also.
So, what I'm going to do now is give
you a very quick
introduction to these three services,
and I want to do that very quickly
because I want to save time
for Clare to come up here and give
you nice, in-depth tour
of what it's like to use these through
a demonstration.
So, the first service I'm going to
talk about is CodeDeploy.
And CodeDeploy works just like Apollo.
It's going - you're going to specify
what version
of your application you want to deploy
to what target group of servers,
and it's going to handle that roll
out for you.
It has the same features of Apollo
with rolling updates

Spanish: 
para evitar tiempos de inactividad
en las implementaciones.
Su seguimiento de estado permite
detener una mala implementación antes
de que se distribuya por toda la aplicación.
Cuando lanzamos CodeDeploy,
solo era compatible
con instancias de Amazon EC2,
pero este año comenzamos a proporcionar
soporte para implementaciones locales.
Esto le permite implementar su aplicación
en servidores de su propio
centro de datos privado,
y también le permite implementar
en máquinas virtuales en otras nubes.
Lo cual significa que ahora pueden usar
CodeDeploy como herramienta principal
para gestionar todas sus implementaciones,
para todas sus aplicaciones
y en distintos entornos.
El siguiente servicio del que
les quiero hablar es CodePipeline,
inspirado en nuestro servicio
de canalización interna.
Funciona de la misma manera.
Se puede especificar cómo funcionará
el proceso de lanzamiento,
cómo se quieren vincular los cambios
de código fuente en la fase de montaje,
en qué entornos de prueba
se quiere implementar,

Chinese: 
以便你能够在不停机的情况下进行部署，
允许你执行运行状况跟踪
以在不良部署中断整个应用程序之前将其关闭。
当我们启动 CodeDeploy 时，
我们仅支持部署到 Amazon EC2 实例，
但今年年初，我们发布了本地部署支持。
这允许你将应用程序部署
到你自己的私有数据中心内的服务器，
它还允许你部署到其他云中的 VM。
这意味着，你现在可使用 CodeDeploy 作为你的中心工具
来管理到你的各个环境中的所有不同应用程序的所有部署。
我要谈论的下一个服务是 CodePipeline，
它由我们内部的 Pipeline 服务激发。
它的工作原理很大程度上与此服务相似。
你将指定你希望发布流程如何运行，
希望如何将源代码更改关联到构建阶段，
你需要部署到的测试环境

Portuguese: 
para a implementação ocorrer
sem tempo de inatividade.
Isso permite acompanhar
a integridade do código
para evitar a implementação
de trechos indesejados
antes que eles derrubem
sua aplicação inteira.
Quando lançamos o CodeDeploy,
ele só oferecia suporte para
as instâncias do Amazon EC2,
mas no começo do ano nós passamos a oferecer
suporte para as implementações nos locais.
Agora, você pode implementar sua aplicação
nos servidores do seu próprio datacenter,
assim como implementá-la
em VMs de outras nuvens.
Ou seja, agora você pode usar o
CodeDeploy como sua principal ferramenta
para gerenciar as implementações
de todas as suas aplicações
e em todos os seus ambientes.
O próximo serviço que
apresento é o CodePipeline,
que foi inspirado no nosso
serviço interno Pipeline.
Ele funciona basicamente da mesma forma.
Você especifica como o processo
de liberação deve funcionar,
como deseja agrupar as alterações do
código-fonte na etapa de criação,
em quais ambientes de
testes deseja implementar

English: 
so that you can deploy without downtime,
it's going to allow you to do health tracking
to cut of bad deployments before
it takes down your entire application.
And when we launched CodeDeploy
we only supported deploying to Amazon
EC2 instances,
but earlier this year we released
support from on-premises deployments.
This allows you to deploy your application now
to servers in your own private data center,
and it also allows you to deploy
to VMs in other clouds.
This means that you can now use CodeDeploy
as your central tool
to manage all your deployments to
all your different applications
in all of your different environments.
The next service I want to talk about
is CodePipeline,
which it was inspired by our internal
Pipeline service.
It's going to work in much the same way.
You're going to specify how you want
your release process to work,
how you want to tie your source code
changes into your build stage,
what test environments you want to deploy to

Portuguese: 
e que testes deseja
realizar nesses ambientes.
Em última instância, você define como
deseja implementar no ambiente de produção.
Esse serviço foi criado com
recursividade e flexibilidade
para que você tenha o
controle do fluxo de trabalho
e dos sistemas aos quais você se conecta
em cada etapa do processo.
Se você deseja usar um serviço
da AWS como o CodeDeploy
ou o Elastic Beanstalk para fazer
as implementações, isso é possível.
Se você deseja usar uma
ferramenta integrada de parceiros
como o GitHub para controlar as etapas
iniciais, isso também é possível.
E se houver servidores próprios no seu local
que você deseja integrar nesse processo,
como o Jenkins, por exemplo,
para criação ou testes,
você também poderá usá-los.
Depois de definir seu próprio
processo de liberação,
o CodePipeline irá gerenciar todas
as alterações de código para você.
Ele inicia automaticamente as etapas
no decorrer do seu processo,
garantindo que todas as alterações
passem pelas validações que você definiu.
O último serviço que
apresento é o CodeCommit.
O CodeCommit usa controle de código-fonte
Git reimplementado em um armazenamento S3.

Chinese: 
以及你需要在这些环境中运行的测试，
最后指定你希望它如何部署到生产中。
此服务设计为高度可扩展和可插拔，
因此你不仅可以控制工作流程，
而且可以控制连接到此流程每个步骤的系统。
如果你需要将 CodeDeploy
或 Elastic Beanstalk 等 AWS 服务用于部署，
则可以这样做。
如果你需要将 GitHub 等集成合作伙伴工具
用于源代码控制，则可以这样做。
如果你有自己的服务器，此服务器可能是你需要
集成到此流程中的本地服务器，
则你可使用 Jenkins 进行构建或测试，
你也可以对其进行挂钩。
在你定义自己的自定义发布流程之后，
CodePipeline 将为你管理你的所有代码更改，
它将一路自动触发
你的流程的每个步骤并确保每个更改
将通过你定义的验证。
我要介绍的最后一个服务是 CodeCommit。
CodeCommit 是基于 S3 存储重新实现的一个 Git 源代码控制。

English: 
and what tests you want to run in
those environments,
and ultimately how you want it to
deploy into production.
This service was designed to be very
extensible and pluggable
so you not only have control of that workflow,
you have control over what systems
you connect
to each step of this process.
If you want to use an AWS service
like CodeDeploy
or Elastic Beanstalk for your deployments
you can do that.
If you want to use an integrated
partner tool
like GitHub for source control you
can do that.
And if you have your own servers,
maybe on-premise servers
that you want to integrate into this process -
you might be using Jenkins for build or test -
you can hook those in as well.
So, after you define your own custom
release process
then CodePipeline is going to manage
all of your code changes for you,
so it automatically will trigger each step
of your process along the way and
make sure that every change
goes through the validations that
you define.
The last service that I want to introduce
is CodeCommit.
CodeCommit is git, git source control
re-implemented on top of S3 storage.

Spanish: 
y qué pruebas se ejecutarán
en esos entornos,
y finalmente cómo se quiere
implementar en producción.
Este servicio está concebido
para ser ampliable y conectable,
para que no solo tenga control
sobre el flujo de trabajo,
sino también sobre los sistemas
a los que se conecta
en cada paso del proceso.
Si quieren usar un servicio AWS
como CodeDeploy
o Elastic Beanstalk para sus
implementaciones, pueden hacerlo.
Si quieren usar una herramienta
de colaboración integrada
como GitHub para el control del
código fuente, pueden hacerlo.
Y si tienen servidores propios,
quizá en sus instalaciones,
y los quieren integrar en este proceso
(puede que estén usando Jenkins
para creación o pruebas),
también pueden enlazarlos.
Cuando definan su propio
proceso de lanzamiento
personalizado, CodePipeline
gestionará sus cambios de código
para que activen automáticamente
cada paso de su proceso y
asegurarse de que cada cambio
supera las validaciones
que ustedes definan.
El último servicio que quiero
presentar es CodeCommit.
CodeCommit es Git, control de origen Git
reimplementado sobre el almacenamiento S3.

English: 
On the front end it works like
any other git source control system out there.
Use the same git tools, issue the
same git commands,
so there's nothing new there.
But on the backend is where it's
really unique.
We've implemented git on top of S3
and DynamoDB.
So, this brings us the advantages
of that cloud scale storage
plus a few interesting bnus features.
One of those is that CodeCommit will
automatically
encrypt your repositories using customer
specific keys.
That means that every customer will have
their repository encrypted differently
when it's stored into S3.
So, I think I lived up to my promise,
I gave you a really quick introduction
to those three.
And now, I'm going to turn things
over to Clare for the rest of the talk,
and she's going to give us a hands
on tour of what it's like
to actually use these services to
set up your own DevOps processes.
Thank you.
CLARE LIGUIORI: Thanks, Rob.
So, I'm Clare Liguiori, I'm an engineer
in the Code Services,

Spanish: 
En el front-end funciona como
cualquier otro sistema
de control de origen Git.
Usa las mismas herramientas Git,
los mismos comandos Git,
así que no hay nada nuevo.
Pero en el back-end
es realmente único.
Hemos implementado Git sobre S3 y DynamoDB.
Esto aporta las ventajas
de un almacenamiento tipo nube
más algunas funciones extra.
Una de ellas es que CodeCommit
cifra automáticamente
sus repositorios mediante
claves específicas de cliente.
Eso implica que cada cliente
tendrá su repositorio cifrado de manera
diferente cuando se almacene en S3.
Bueno, creo que he cumplido mi promesa, les
he presentado brevemente los tres servicios.
Ahora voy a dar paso
a Clare para que termine la charla,
y ella nos hará una demostración
práctica de lo que supone utilizar
estos servicios para configurar
tus propios procesos en DevOps.
CLARE LIGUIORI: Gracias, Rob.
Me llamo Clare Liguiori,
soy ingeniera en Servicios de código,

Chinese: 
在前端，它的工作原理类似于
任何其他 Git 源代码管理系统。
使用相同的 Git 工具，发出相同的 Git 命令，
其中并无任何新内容。
但此服务的独特之处在于后端。
我们已基于 S3 和 DynamoDB 实现 Git。
这为我们带来了云规模存储的优势
以及一些有趣的额外功能。
其中之一是，CodeCommit 将自动
使用客户特定的密钥加密你的存储库。
这意味着，每个客户将
在其存储库存储到 S3 中时以不同的方式加密存储库。
我认为我兑现了我的承诺，
我为你快速介绍了这三种服务。
现在，我将演讲的剩余时间留给 Clare，
她将帮助我们了解如何
实际使用这些服务来设置你自己的开发运营流程。
Rob，谢谢。
我叫 Clare Liguiori，是一名 Code Services 工程师，

Portuguese: 
No front-end, ele funciona como
qualquer outro sistema Git
disponível no mercado.
Ele usa as mesmas ferramentas
e tem os mesmos comandos.
Até aqui, nenhuma novidade.
Mas é no back-end que ele se revela único.
Nós implementamos Git em S3 e DynamoDB.
Isso nos oferece as vantagens do
armazenamento em escala de nuvem
com outros recursos bem interessantes.
Uma delas é que o CodeCommit
criptografa seus repositórios
automaticamente usando chaves específicas.
Ou seja, cada cliente terá
uma criptografia diferente quando o
repositório estiver armazenado no S3.
Acho que cumpri minha promessa
de fazer uma breve apresentação
desses três serviços.
Agora, passo a palavra para a
Clare, que fará uma apresentação
para mostrar na prática
como usar esses serviços
para configurar seus próprios
processos de DevOps.
Obrigada, Rob.
Meu nome é Clare Liguiori, sou
engenheira de serviços de código.

Chinese: 
我想使用我创建的简单应用程序来为你实时演示，
内容与 Rob 所讲的有点类似。
作为两个独立团队获得了两种微服务，
Rob 和我将是此情况下的独立团队。
它具有微服务架构。
对于执行加减运算的简单计算器应用程序，
我有已写入作为我的计算器 API 的 Go 的
Web 服务。
我将用它来加减给定输入。
前端服务将是一个网站，
非常简单的 HTML 网站，将调入
Web 服务上的计算器 API 中。
Rob 处理 Go 中的 Web 服务，然后我处理网站。
我还将为你提供一些选项，
你使用这些选项
基于 CodeDeploy 和 CodePipeline
以及你可搭配使用的一些功能管理你的发布流程。
我们将运行的方案是，

English: 
and I want to give you a live demo
using a simple app that I've created
that gives a little bit of a flavor
of what Rob was talking about.
So, it's got two microservices as
two independent teams -
Rob and I are going to be the independent
teams for this scenario.
And it has that microservices architecture.
So, for a simple calculator app that
does add and subtract
I have a web service that's written in Go
that is my calculator API.
So, that's what I'm going to be using to add
and subtract given inputs.
The front end service is going to
be a website,
very simple HTML website, that's
going to call
into that calculator API on the web service.
Rob worked on the web service in
Go and then I worked on the website.
I'm also going to give you a little
bit of a flavor
of some of the options that you have for
managing your release process on
top of CodeDeploy and CodePipeline
and some of the features that you
can mix and match.
So, the scenario that we're going
to run through is

Spanish: 
y les voy a mostrar cómo usar
una aplicación sencilla que he creado
y que servirá para ilustrar
la intervención de Rob.
Tiene dos microservicios que funcionan
como dos equipos independientes:
Rob y yo seremos los equipos
independientes en este caso.
Y tiene una arquitectura de microservicios.
Como aplicación sencilla de calculadora
que hace sumas y restas,
tengo un servicio web escrito en Go
que es mi API de calculadora.
Es lo que voy a usar
para hacer sumas y restas.
El servicio de front-end
será un sitio web,
uno muy sencillo en HTML, que llamará
a la API de la calculadora en el servicio web.
Rob trabajó en el servicio web
en Go y yo en el sitio web.
También les haré una pequeña muestra
de algunas opciones
para gestionar el proceso de lanzamiento,
además de CodeDeploy y CodePipeline,
y algunas funciones que se pueden
mezclar y combinar.
Imaginemos que Rob

Portuguese: 
Farei uma demonstração em tempo real do
uso de uma aplicação que eu mesma criei
para mostrar um pouco
daquilo de que o Rob falou.
Teremos dois microsserviços gerenciados
por duas equipes independentes.
Rob e eu faremos o papel
das equipes independentes.
A aplicação usa a arquitetura
de microsserviços.
Para um aplicativo simples de
calculadora que faz somas e subtrações,
usarei um serviço da Web escrito em Go
como a API da minha calculadora.
É isso que usarei para adicionar
e subtrair os dados de entrada.
O serviço de front-end será um
website HTML bastante simples.
Esse website chamará
a API da calculadora no serviço da Web.
O Rob preparou o serviço da Web
em Go e eu preparei o website.
Também mostrarei brevemente
algumas das opções de gerenciamento
do processo de liberação com o
CodeDeploy e o CodePipeline,
além de outros recursos
que podem ser combinados.
O cenário que mostraremos é o seguinte:

English: 
that recently Rob added multiple
and divide to that web service,
and so we're going to go into the website
and actually add that as a feature
for our customers on the website.
But it turns out that Rob has a bug
in his code,
bad Rob. He has a divide by arrow
- divide by zero error.
So, we'll look at what you can do
to stop those types of bugs
from getting out to production.
We'll first start with that change
the website that I talked about,
adding multiply and divide to the website.
I'm using GitHub for my source, and
I'm going to use CodeDeploy
to deploy that change into test environment.
We'll do a little bit of smoke testing on it
and then promote it to production
with CodeDeploy as well.
For the web service, it's a little
bit more complicated
because it's written in Go, so I
need to compile that code
in order to get build artifacts that
I can actually deploy.
We're going to use CodePipeline to
hook that entire process up

Chinese: 
最近 Rob 多次为 Web 服务添加乘除运算，
我们将进入网站
并为网站客户将乘除作为一项功能添加。
但结果是，Rob 的代码出现错误，
Rob 犯了错。他具有除以箭头 - 被零除错误。
我们看看你如何阻止这些类型的错误
在生产中出现。
首先，我们将更改我谈论过的网站，
并为网站添加乘除运算。
我将使用 GitHub 作为我的源，将使用 CodeDeploy
来将更改部署到测试环境。
我们将对其执行冒烟测试，
然后使用 CodeDeploy 将其提升到生产中。
对于 Web 服务，稍微复杂一点，
因为它已写入 Go 中，因此我需要编译代码
以便获取我实际能够部署的构建项目。
我们将使用 CodePipeline 在 GitHub 中从源挂钩

Spanish: 
ha añadido la función de multiplicar
y dividir a ese servicio web,
iremos al sitio web
y las añadiremos como funciones
para nuestros clientes en el sitio web.
Pero resulta que Rob encuentra
un error 5en su código;
muy mal, Rob.  Dividir por flecha
y dividir por cero le da error.
Veremos qué podemos hacer
para evitar que estos errores
lleguen a producción.
Empezaremos con el cambio
que les comentaba en el sitio web,
añadiendo multiplicaciones
y divisiones al sitio web.
Estoy usando GitHub para mi código fuente,
y voy a usar CodeDeploy
para implementar ese cambio
en el entorno de pruebas.
Haremos algunas pruebas
y luego lo pasaremos a producción
con CodeDeploy también.
Para el servicio web,
es un poco complicado
porque está escrito en Go,
así que tengo que compilar ese código
para conseguir elementos de versión
que pueda realmente implementar.
Vamos a usar CodePipeline
para vincular ese proceso

Portuguese: 
o Rob adicionou multiplicação e
divisão àquele serviço da Web,
então precisamos acessar o website
e adicionar essas operações para que
os clientes possam usar o recurso.
Mas parece que há um bug no código.
Que vacilo, Rob! O código apresenta
um erro de divisão por zero.
Então, vejamos o que
podemos fazer para evitar
esse tipo de bug na produção.
Primeiro, vamos fazer a alteração no website,
adicionando multiplicação e divisão.
Estou usando GitHub como
código-fonte e usarei o CodeDeploy
para implementar essa alteração
no ambiente de teste.
Realizaremos alguns testes
e a implementaremos na produção,
também com o CodeDeploy.
Em relação ao serviço da Web,
é um pouco mais complicado
porque como ele foi escrito em
Go, preciso compilar o código
para criar os artefatos que eu implementarei.
Usaremos o CodePipeline para
acompanhar todo esse processo

Portuguese: 
desde o código-fonte em GitHub até
a criação e compilar o código Go.
Adicionaremos testes automatizados
para detectar os bugs do Rob
e implementaremos com o CodeDeploy.
Finalmente, mostrarei para vocês
como mover os repositórios para o CodeCommit
e como gerenciar o código-fonte na nuvem.
Então, primeiro vamos fazer
a alteração no website,
adicionar multiplicação e divisão.
Esse é o meu aplicativo de
calculadora, é muito simples.
Repito: no momento, ela só
tem adição e subtração.
Depois ela chamará o serviço da Web
para que a API da calculadora
gere e exiba um resultado.
Aqui temos o website em
execução no ambiente de teste,
e aqui ele está em execução
no ambiente de produção.
No momento, eles têm a mesma
versão do aplicativo.
O ambiente de produção é um pouco diferente
porque quero que ele esteja
disponível e seja confiável.
Na verdade, estou executando
três instâncias do EC2
por trás do Elastic Load Balancer.

Chinese: 
整个流程，以及构建以编译 Go 代码，
添加一些自动测试，以便我们可捕获 Rob 的错误，
然后使用 CodeDeploy 进行部署。
最后，我将介绍
你如何将这些存储库移至 CodeCommit 中
以及如何开始在云中管理源代码。
我们先对网站做出此更改，
即添加乘除运算。
这是我的非常简单的计算器应用程序。
它现在只有加减运算，
之后它将回调到 Web 服务
的计算器 API 以获取并显示结果。
这是我的测试环境中运行的网站，
这是我的生产环境中运行的网站，
今天它们运行的是同一版本的应用程序。
生产环境稍有不同，
因为我希望它可用且可靠，
实际上我在 Elastic Load Balancer 后有
三个 EC2 实例正在运行。

English: 
from the source in GitHub, and to
build to compile that Go code,
add some automated tests so we can
catch Rob's bugs,
and then deploy that with CodeDeploy as well.
And then finally, I'm going to show you
how you can move those repositories
into CodeCommit
and start managing that source code
in the cloud.
So, let's first go and make this
change for the website,
add multiply and divide.
This is my very, very simple calculator
application.
Again, it only has addition and subtraction right now,
and then it will call back into that
web service
to that calculator API to get the
result and display that.
This is my website running in my
test environment,
this is my website running in my
production environment,
today they're running the same version
of the application.
The production environment is a little
bit different
because I want it to be available
and reliable,
I actually have three EC2 instances
running behind Elastic Load Balancer.

Spanish: 
desde el código fuente en GitHub y
construir y compilar el código Go,
añadir pruebas automatizadas,
detectar los errores de Rob
e implementar con CodeDeploy.
Y finalmente, les mostraré
cómo llevar esos repositorios a CodeCommit
y comenzar a gestionar
ese código fuente en la nube.
Pero empecemos por hacer
este cambio en el sitio web:
añadir multiplicaciones y divisiones.
Es una aplicación de calculadora
muy sencilla.
Ahora solo tiene sumas y restas,
pero hará una llamada al servicio web
para que la API de la calculadora
consiga el resultado y lo muestre.
Este es mi sitio web
en mi entorno de prueba,
este es mi sitio web
en mi entorno de producción,
hoy están ejecutando la misma versión
de la aplicación.
El entorno de producción
es algo diferente,
porque quiero que esté disponible
y sea fiable,
de hecho tengo tres instancias de EC2
ejecutándose tras Elastic Load Balancer.

English: 
So, I've created this heads up view
to show you
exactly what version of the application is running
on each of the EC2 instances.
So, today we have this addition and
subtraction
running on all three instances.
The first step for using CodeDeploy
for your release process
is going to be packaging up your
application for CodeDeploy
in order to deploy it onto your instances.
So, like I said, I have my calculator
website source stored in GitHub
and I'm using this really package
it up for CodeDeploy.
I have all of my application artifacts,
today it's just a simple HTML page,
but if it was more complex, had separate
Java Script files
or image assets, those would go into
this repository as well.
I have a scripts folder, that's going to hold
all of my installation and configuration
tools and scripts
that I need to deploy this onto a server.
And then the most important part
for CodeDeploy

Chinese: 
我已创建此前导视图以便为你演示
各个 EC2 实例上正在运行的应用程序的准确版本。
今天，我们所有三个
实例上都在运行此加减应用程序。
在发布流程中，使用 CodeDeploy 的第一步是，
针对 CodeDeploy 打包你的应用程序
以便将其部署到你的实例。
就像我说过的，我将我的计算器网站源存储在 GitHub 中，
我将使用此源为 CodeDeploy 打包应用程序。
我已拥有我的所有应用程序项目，
今天的项目只是一个简单的 HTML 页面，
但如果项目更复杂，将具有单独的 Java 脚本文件
或图像资产，也将进入此存储库。
我具有脚本文件夹，该文件夹将保存
我将项目部署到服务器所需的
所有安装和配置工具和脚本。
CodeDeploy 的最重要的部分

Portuguese: 
Eu criei essa visualização para informar
a versão do aplicativo em execução
em cada uma das instâncias do EC2.
No momento, temos adição e subtração
em execução nas três instâncias.
A primeira etapa para o uso do
CodeDeploy no seu processo de liberação
será criar um pacote do
aplicativo para o CodeDeploy
a fim de implementá-lo nas instâncias.
Como disse, o código da minha
calculadora está armazenado no GitHub,
que estou usando somente para criar
um pacote para o CodeDeploy.
Tenho todos os artefatos do aplicativo.
Aqui, temos uma página HTML simples,
mas se ela fosse mais complexa,
com arquivos de Java Script
ou recursos de imagens separados,
usaríamos o repositório da mesma forma.
Tenho uma pasta de scripts que será o local
dos scripts e ferramentas de
instalação e configuração
necessários para implementar
o aplicativo no servidor.
A parte mais importante para o CodeDeploy

Spanish: 
He creado esta vista preliminar
para mostrarles exactamente
qué versión de la aplicación
se está ejecutando
en cada instancia de EC2.
Hoy se está ejecutando la función
de suma y resta
en las tres instancias.
El primer paso para usar CodeDeploy
en su proceso de lanzamiento
será empaquetar su aplicación
para CodeDeploy
e implementarla en sus instancias.
Como decía, tengo el código fuente
de mi sitio web calculadora en GitHub,
y lo voy a usar para empaquetarlo
todo para CodeDeploy.
Tengo todos los elementos de la aplicación,
hoy una sencilla página HTML,
pero si fuera más compleja,
con archivos Java Script
o imágenes aparte, irían también
a este repositorio.
Tengo una carpeta de scripts
con las herramientas y los scripts
de instalación y configuración
necesarios para implementar
esto en un servidor.
Y luego la parte más importante
para CodeDeploy

Chinese: 
是应用程序规格文件。
此文件将定义 CodeDeploy
需要如何在单台计算机上安装此项。
我们将它简称为 AppSpec。
下面我演示一下 AppSpec 文件
并进行细分。
第一部分是文件部分。
告知 CodeDeploy 此应用程序包中
的需要复制到实例的文件以及需要复制到的位置。
我在 HTML 文件中只有一条索引，
并且此索引将进入根 Web 服务器内容目录，
但你可为更复杂的应用程序添加更多索引。
此挂钩部分定义 CodeDeploy 在部署生命周期的
每个阶段需要做的事情。
我们将停止此应用程序，
CodeDeploy 将停止 Web 服务器，
将其从负载均衡器中删除。
安装前，我们需要确保
我们具有所有依赖项，

Portuguese: 
será o arquivo de
especificação do aplicativo.
É isso que define como o CodeDeploy
precisa instalar o aplicativo
em uma única máquina.
Chamaremos isso de AppSpec, por enquanto.
Mostrarei um pouco do arquivo
AppSpec em detalhes.
A primeira parte é a seção de arquivos.
Ela informa ao CodeDeploy quais
arquivos desse grupo de aplicativos
é necessário copiar na sua instância
e onde eles precisam ficar.
Tenho apenas um único índice no arquivo HTML
e ele ficará no diretório principal
de conteúdo do servidor da Web,
mas é possível adicionar muito mais
arquivos em casos mais complexos.
Essa seção define o que o
CodeDeploy precisa fazer
em cada etapa do ciclo de
vida de desenvolvimento.
Encerraremos o aplicativo
e o CodeDeploy irá desativar
o servidor da Web
e retirá-lo do load balancer.
Antes da instalação,
convém ter todas as dependências,

English: 
is going to be the application specification file.
So, that's going to define how CodeDeploy
needs to install this on a single machine.
So, we call that AppSpec for short.
Let me show you a little bit about
the AppSpec file
and break this down.
So, the first section is the files section.
That's going to tell CodeDeploy what
files in this bundle of application
does it need to copy onto your instance
and where does it need to go.
So, I only have my single index at HTML file
and it's going to go into the root
web server content directory,
but you could add many more for more
complex applications.
And then this hook section defines
what does CodeDeploy need to do
in each stage of the development lifecycle.
So, we're going to stop the application,
CodeDeploy is going to bring down
the web server,
take it out of the load balancer.
Before instillation we want to make sure
that we have all of the dependencies,

Spanish: 
será el archivo de
especificación de la aplicación.
Esto definirá la forma en que CodeDeploy
debe instalar esto en una sola máquina.
Para abreviar, llamamos
a este archivo AppSpec.
Permitan que les muestre algo
sobre el archivo AppSpec
con más detalle.
La primera sección es la sección
de los archivos.
Le dirá a CodeDeploy qué archivos
en este paquete de la aplicación
deben copiarse en su instancia
y a dónde debe ir.
Solo tengo un archivo índice HTML
y se va a colocar en el directorio raíz
del contenido del servidor web,
pero se podrían añadir muchos más
en el caso de aplicaciones complejas.
Esta sección de enlace define
lo que debe hacer CodeDeploy
en cada etapa del ciclo de vida de desarrollo.
Así que vamos a detener la aplicación,
CodeDeploy va a desconectar el servidor web,
y a retirarlo del balanceador de carga.
Antes de la instalación
nos interesa asegurarnos
de que tenemos todas las dependencias,

Portuguese: 
que nesse caso é um simples
pacote do servidor.
O CodeDeploy reiniciará o servidor da Web
depois que ele copiar os
arquivos para a máquina
e finalmente validará
que tudo está correto,
ou seja, que receberemos
uma resposta válida do servidor.
Novamente, esse exemplo
é extremamente simples,
mas é possível replicar isso
para aplicativos mais complexos,
com etapas e scripts mais intrincados.
Esses são alguns scripts simples que criei.
Esses são os scripts da minha dependência.
Estou usando Yum para ter certeza
de que há um pacote de servidor instalado,
mas é possível replicar isso para ferramentas
de qualquer configuração que você use.
Você pode usar Chef, Puppet ou Ansible
e copiar neste script.

Chinese: 
在此示例中，只有一个简单的 Web 服务器包。
CodeDeploy 在将文件复制到计算机
之后将启动 Web 服务器备份，
最后它将验证
一切是否运行正常，我们能否获得
来自 Web 服务器的良好响应。
我的示例非常简单，
但你可将它更改为更复杂的应用程序、
更复杂的脚本和步骤。
下面我来演示一些简单脚本。
我们现在看到的是我的依赖脚本。
这里我使用的是 Yum，为的是确保
Web 服务器包已安装，
但你可将此扩展到你今天使用的任何
配置管理工具。
你可使用 Chef、Puppet 或 Ansible，
并且挂钩到此脚本。

Spanish: 
en este caso solo un paquete de servidor web.
CodeDeploy comenzará la copia
de seguridad del servidor
web cuando haya copiado todos
los archivos en la máquina,
y luego comprobará
que todo funciona correctamente,
que podemos tener
una buena respuesta del servidor web.
Mi ejemplo es muy, muy sencillo,
pero se puede trasladar
a aplicaciones más complejas,
a scripts y pasos más complejos.
Les mostraré algunos scripts sencillos.
Estos son los scripts de mi dependencia.
Estoy usando Yum para comprobar
que hay instalado un paquete de servidor web,
pero se puede aplicar en cualquier
herramienta de gestión de configuración
actual.
Pueden usar Chef, o Puppet, o Ansible
y vincularla directamente a este script.

English: 
in this case just a simple web server package.
CodeDeploy is going to start the
web server back up
after it's copied the files onto
that machine,
and then finally it's going to validate
that everything's working correctly,
that we can actually get
a good response from the web server.
Again, my example is very, very,
very simple,
but you can grow this to your more
complex applications,
more complex scripts and steps.
Let me show you a couple of my simple scripts.
We're looking now at my dependency scripts.
I'm using Yum here just to make sure
that a web server package is installed,
but you can grow this to any configuration
management tool
that you're using today.
You can use Chef, or Puppet, or Ansible,
and hook that right into this script.

Spanish: 
Echemos un vistazo a mi script de prueba.
Quiero comprobar que ese servidor web estaba
en marcha antes de volver a añadirle tráfico,
y quiero comprobar que realmente
está sirviendo páginas.
Es un ejemplo muy sencillo,
solo estoy comprobando que se consigue
un código de respuesta correcto.
Lo cual implica también comprobar
que estás recibiendo los contenidos correctos,
que has copiado el archivo
que querías copiar
en esa máquina.
El modelo de scripts funciona
muy bien dentro de Amazon
porque, como dijo Rob, los equipos
son muy independientes.
Como dijo Andy esta mañana,
ellos deciden su propio destino.
Y nosotros queremos
que elijan las mejores tecnologías
para su aplicación.
Este modelo de scripts
es muy flexible y potente,
se puede vincular cualquier software
que se esté usando,
cualquier lenguaje de programación,
cualquier lenguaje de cifrado,
cualquier cosa que lleve su aplicación

English: 
Let's also take a look at my test script.
I want to make sure that that web
server was actually
started property before I add traffic
back to it,
and I want to make sure that it's
actually serving pages.
This is a really simple example, of course,
I'm just making sure that we're getting
a successful response code.
You could extend this to make sure
that you're getting the right content back,
that you have actually copied the
file that you expect to copy
onto that machine.
The scripts model work really well
inside of Amazon
because Rob mentioned that it's very
independent teams there.
As Andy said this morning, they're
determining their own destiny.
And so we want to make sure that they can
choose the technologies that work
for their application.
And so in this scripts model it's
very flexible and powerful,
you can hook into any software that
you're using,
any programming language, any scripting language,
really anything that you need to
get your application

Portuguese: 
Vamos dar uma olhada no meu script de teste.
Antes de retomar o tráfego do servidor,
quero ter certeza de que
ele realmente foi iniciado
e que ele está de fato veiculando conteúdo.
Claro que, como o exemplo é simples,
só preciso receber o código
de uma resposta adequada.
Esse método pode ser usado para verificar
se você está recebendo de volta
o conteúdo certo, se você
realmente copiou o arquivo que
deseja mover para aquela máquina.
O modelo de scripts funciona
muito bem na Amazon
porque, como o Rob mencionou,
as equipes são independentes.
E como o Andy disse mais cedo, elas não
querem complicar suas próprias vidas.
Queremos que elas possam
escolher tecnologias que funcionem
com os aplicativos delas.
Esse modelo de scripts é
bastante flexível e eficiente.
Você pode se conectar aos
softwares que costuma usar
ou a qualquer linguagem de
programação ou de script,
ao que você precisar para que o aplicativo

Chinese: 
下面我们也看看我的测试脚本。
我想确保 Web 服务器实际上
已在我向其添加流量之前启动，
并且我想确保它实际上为页面服务。
这是一个非常简单的示例，当然，
我只是确保我们获得了成功的响应代码。
你可进行扩展以确保
你获得正确的内容，
你已将所需的文件复制
到相应计算机。
脚本模型在 Amazon 内运行得非常好，
因为 Rob 提到过它具有非常独立的团队。
如 Andy 今早所说，他们将决定自己的命运。
我们想确保他们能够
选择适用于其应用的技术。
在此脚本模型中，它非常灵活且功能强大，
你可挂钩到你使用的任何软件、
任何编程语言、任何脚本编写语言，
你的应用程序接触实例

Portuguese: 
funcione na instância.
A próxima etapa para a
implementação com o CodeDeploy
será escolher as instâncias nas
quais você deseja implementar.
À esquerda, você verá os
grupos de implementação.
Esses grupos são simplesmente
um conjunto de servidores
em que você deseja implementar.
Para definir isso, use uma
etiqueta da instância EC2,
uma etiqueta dos seus servidores locais
ou simplesmente um nome para
o grupo de Auto Scaling.
Nesse exemplo, usarei dois
grupos de Auto Scaling.
Meu ambiente de teste tem
um tamanho fixo "um"
e o meu ambiente de produção
tem um tamanho fixo "três".
À direita, você vê a lista de revisões.
Para registrar uma nova
revisão do aplicativo,
é necessário zipar os arquivos
que analisamos no repositório
e registrar isso
como uma visão mais recente do CodeDeploy.

English: 
onto the instance and up and running.
The next step for deploying with CodeDeploy
is going to be choosing the instances
that you want to deploy to.
So, over here on the left hand side,
you're going to see the deployment groups.
A deployment group is simply the
group of servers
that you want to deploy to.
So, that can be defined by an EC2
instance tag,
a tag for your on-premise servers,
or simply the name of an auto scaling group.
So, in this example, I'm using two
auto-scaling groups.
I have my test environment with just
a fixed size of one,
and then my production environment
with a fixed size of three.
And then on the right hand side you'll
see this list of revisions.
What that is, is in order to register
a new revision
of my application, you're going to
zip up all of the files
that we just looked at in the repository
and register
that as a newer vision with CodeDeploy.
So, you can see I've been playing through

Spanish: 
a la instancia y que funcione bien.
El siguiente paso para
implementar con CodeDeploy
es elegir las instancias
donde quieren realizar la implementación.
En la parte de la izquierda
verá los grupos de implementación.
El grupo de implementación
es el grupo de servidores
donde se quiere hacer la implementación.
Se pueden definir con una etiqueta
de instancia EC2,
una etiqueta para sus servidores locales
o simplemente el nombre
de un grupo de Auto Scaling.
En este ejemplo, utilizaré
dos grupos de Auto Scaling.
Tengo mi entorno de prueba con solo
un tamaño fijo de uno,
y luego mi entorno de producción
con un tamaño fijo de tres.
Y en la derecha
verán la lista de revisiones.
Eso significa que para registrar
una nueva revisión
de mi aplicación, voy a tener
que comprimir todos los archivos
que acabamos de ver
en el repositorio y registrarlos
como una visión más reciente con CodeDeploy.
Como pueden ver, he estado jugando

Chinese: 
并正常运行所需的任何内容。
使用 CodeDeploy 进行部署的下一步
是选择要部署到的实例 。
在左侧，
你会看到部署组。
部署组就是你要部署到的服务器组。
它可以由 EC2 实例标签、
你的本地服务器的标签
或仅仅是 Auto Scaling 组的名称定义。
在此示例中，我将使用两个 Auto Scaling 组。
我的测试环境的固定大小为一，
生产环境的固定大小为三。
你将在右侧看到此修订列表。
那是什么呢，为了注册应用程序
的新修订，你要对我们刚刚在存储库中
查看的所有文件进行压缩，并将其作为更新后的修订
注册到 CodeDeploy。
因此，你会看到我

Chinese: 
在这里演示了几个不同的修订。
让我们继续并尝试启动部署。
部署可以通过 AWS CodeDeploy 控制台、
CodeDeploy API 与 AWS CLI
或 SDK 以及某个合作伙伴集成启动。
GitHub 恰好是我们最大的合作伙伴集成之一，
因此我们将使用它。
下面我向你展示如何使用。
我现在正在查看
我在网站的存储库上配置的服务挂钩，
排在第一位的是 GitHub 自动部署。
将执行的操作是配置我的存储库，
以便在每次更改该存储库时触发部署。
每次我将新的提交推送到该存储库时，
都会启动部署。

English: 
a couple different revisions here.
So, let's go and try to kick off
a deployment.
A deployment can be kicked off through
the AWS CodeDeploy console,
it can be through the CodeDeploy
API with the AWS CLI,
or the SDK, or you can do it through
one of our partner integrations.
GitHub just happens to be one of
our great partner integrations,
so we're going to use that.
And let me show you what that looks like.
So, I'm now looking at the service hooks
that I have configured on my repository
for my website,
and the first one at the top is going
to be GitHub auto deployment.
What that's going to do is configure
my repository
to trigger a deployment every time
I make a change to that repository.
So, every time I push a new commit
to the repository
it's going to kick off a deployment.

Spanish: 
con varias revisiones diferentes.
Vamos a empezar con una implementación.
Una implementación se puede iniciar mediante
la consola de AWS CodeDeploy,
mediante la API de CodeDeploy
con la CLI de AWS,
o el SDK, o con uno de nuestros sistemas
integrados de socios.
GitHub es uno de nuestros fantásticos
sistemas integrados de socios,
así que usaremos ese.
Les mostraré qué aspecto tiene.
Ahora estoy mirando los enlaces de servicio
que he configurado en mi repositorio
para mi página web,
y el primero en la parte de arriba
es la autoimplementación de GitHub.
Eso configurará mi repositorio
para activar una implementación cada vez
que haga un cambio en ese repositorio.
Cada vez que envíe una nueva confirmación
al repositorio, se iniciará
una implementación.

Portuguese: 
Notem que eu fiz algumas revisões diferentes.
Agora, vamos tentar iniciar
uma implementação.
É possível iniciar uma implementação
pelo console do AWS CodeDeploy,
pela API do CodeDeploy com o AWS CLI
pelo SDK ou ainda por meio das
integrações com os nossos parceiros.
Por acaso, o GitHub é uma integração
de um dos nossos maiores parceiros,
então podemos usá-lo.
Deixe-me mostrar como fazer isso.
Estou analisando as conexões de serviço
que configurei no repositório
para o meu website.
O primeiro da lista será a
implementação automática do GitHub.
Esse processo configura meu repositório
para acionar uma implementação sempre que
eu fizer uma alteração naquele repositório.
Sempre que eu enviar algo
novo para o repositório,
ele vai lançar uma implementação.

Portuguese: 
A conexão de serviço do CodeDeploy definirá
em qual aplicativo desejo implementar.
Este será o aplicativo do meu website
que eu configurei no CodeDeploy,
e em que grupo de servidores
desejo implementar,
bem como o grupo de implementação.
Não é recomendável implementar
automaticamente na produção.
Como essa não é uma boa ideia, configurei
para implementar automaticamente
para teste quando alguém fizer uma alteração.
Vamos voltar para o website.
A essa altura, ativaremos multiplicação
e divisão para os clientes,
pois a API da calculadora -
já oferece essas novas opções.
Depois de fazer isso, vamos
anunciar para os clientes
que há novos recursos disponíveis.

Spanish: 
Y luego el vínculo de servicio
de CodeDeploy definirá
la aplicación en la que
quiero hacer la implementación.
Esa será la aplicación del sitio web
que he configurado en CodeDeploy,
y el grupo de servidores
donde quiero hacer la implementación,
el grupo de implementación.
No me interesa una implementación automática
hacia producción,
no es buena idea, así que he configurado
la implementación automática
de prueba cuando haya una nueva confirmación.
Así que volvamos al sitio web,
en este punto vamos a permitir
multiplicaciones y divisiones
para nuestros clientes porque
ya es una nueva opción
en la API de calculadora.
Así que haremos eso,
anunciaremos a nuestros clientes
que tenemos una nueva función para ellos.

English: 
And then the CodeDeploy service hook
is going to define
what application do I want to deploy to.
So, that's going to be my website
application
that I've configured within CodeDeploy,
and then what group of servers do
I want to deploy to,
what deployment group.
So, I probably don't want to automatically
deploy into production,
that sounds wrong, so I've configured
it to deploy automatically
into test when someone pushes a new commit.
So, let's go back to the website,
and at this point we're actually
going to enable
multiply and divide for our customers
because it's already an -
it's a new option in the calculator API.
So, we'll do that, and let's announce
to our customers
that we have a new feature for them.

Chinese: 
随后，CodeDeploy 服务挂钩将定义
我要部署到的应用程序。
这将是我在 CodeDeploy 中配置的
网站应用程序、
我要部署到的服务组、部署组。
我可能不希望自动部署到生产中，
好像是弄错了，因此我已将它配置为在有人推送新的提交时
自动部署到测试中。
让我们回到网站，
此时我们实际上将支持
客户的乘除运算，因为它已经是
计算器 API 中的一个新选项。
我们将这样做，我们告知客户
已为其提供新功能。

English: 
And then I'm going to change the
font color and the background color
just so it's really clear to us which
version we're running.
And commit those changes.
So, now what GitHub is doing,
it's taking the updated files in
my repository,
registering that as a new revision
in CodeDeploy,
and kicking off a deployment.
So, we can go back to the CodeDeploy console
and it's already registered this
as a new revision.
And we can go into deployments,
this is the central dashboard for
all deployments
across all of your applications.
You can see all of your deployment activity.
I'm going to drill into this deployment
in progress.
This is the deployment that GitHub kicked off
for my multiply and divide change,
and you can see the instance right here

Spanish: 
Y luego voy a cambiar el color
de la fuente y el color de fondo
para que se vea claramente
la versión que estamos usando.
Y confirmaré esos cambios.
Ahora GitHub está obteniendo
los archivos actualizados en mi repositorio,
registrándolos como una nueva revisión
en CodeDeploy,
e iniciando una nueva implementación.
Podemos volver a la consola de CodeDeploy
y veremos que ya ha registrado
esto como una nueva revisión.
Podemos ir a las implementaciones,
este es el panel central
para todas las implementaciones
en todas las aplicaciones.
Pueden ver toda la actividad
de la implementación.
Voy a profundizar en esta implementación
en proceso.
Esta es la implementación que inició GitHub
por mi cambio de multiplicación y división,
y aquí se puede ver la instancia

Portuguese: 
Vou alterar a cor da fonte
e a cor do segundo plano
só para destacar a versão que estamos usando.
Agora salvo essas alterações.
Nesse momento, o GitHub está
colocando os arquivos
atualizados no meu repositório,
registrando o processo como uma
nova revisão do CodeDeploy
e lançando uma implementação.
Agora, voltamos ao console do CodeDeploy
para ver que foi tudo registrado
como uma nova revisão.
Acessaremos "Implementações",
no painel central de todas as implementações
para todos os seus aplicativos.
Aqui você vê toda a
atividade de implementação.
Vejamos essa implementação
que está em andamento.
Essa é a implementação que o GitHub lançou
para a inclusão de multiplicação e divisão.
Veja que essa instância aqui

Chinese: 
然后，我将更改字体颜色和背景颜色，
以便清楚了解我们正在运行的版本。
然后提交这些更改。
现在，GitHub 所做的是，
选取我的存储库中的更新后的文件，
将其作为新修订注册到 CodeDeploy 中，
然后启动部署。
我们可以回到 CodeDeploy 控制台，
已将其注册为新修订。
我们可以进入部署，
这是跨所有应用程序的所有部署
的中央控制面板。
你会看到所有部署活动。
我将深入介绍这个正在进行的部署。
这是 GitHub 针对我的乘除更改
启动的部署，
你可以在这里看到

Portuguese: 
está implementando naquele
grupo de Auto Scaling.
Vamos esperar um segundo para ele iniciar.
Mostrarei para vocês como fazer
a implementação individual que
fica em uma instância específica.
Vocês devem reconhecer alguns
desses nomes de eventos
daquele arquivo AppSpec.
Os aplicativos param e o
servidor já está desativado.
As dependências foram instaladas,
bem como o servidor da Web
e os arquivos. O índice foi copiado do HTML
para o diretório de conteúdo do servidor.
Nesse momento, estamos iniciando o servidor.
Em seguida, ele chamará meu script de teste
para verificar se está recebendo
uma resposta adequada.
Até esse momento, tudo deu certo.
Vamos atualizar. Ótimo.

Spanish: 
que está implementando
en ese grupo de Auto Scaling.
Un momento antes de empezar.
Les quiero mostrar cómo profundizar
en la implementación concreta
que va a esa instancia específica.
Reconocerán algunos de esos
nombres de evento
por el archivo AppSpec que vimos antes.
Las aplicaciones se detienen,
se ha interrumpido el servidor web
y se han instalado mis dependencias,
mi servidor web
y los archivos, y se ha copiado
mi archivo índice HTML
al directorio de contenido del servidor.
Ahora está iniciando el servidor web
y luego llamará a mi script de prueba
y comprobará que está recibiendo
una respuesta correcta (200).
De momento todo ha salido bien.
Vamos a actualizar.  Bien.

English: 
that it's actually deploying to in
that auto-scaling group.
So, let's give it just a second to
get started.
What I want to show you is I want
to drill into
the individual deployment that goes
onto that specific instance.
You might recognize some of these
event names
from the AppSpec file that we looked at.
So, applications stop, it has already
brought down the web server,
and it has installed my dependencies,
my web server,
it's installed those files, copied
my index out of HTML
to the web server content directory.
And so, right now what it's doing
is starting up the web server
and then it will actually call my
test script
and make sure that it's getting a
200 successful response.
So, everything's succeeded at this point.
Let's refresh. Alright.

Chinese: 
实际部署到该 Auto Scaling 组中的实例。
让我们等待它开始。
我想向你展示的是，我想深入介绍
对该特定实例进行的单个部署。
你可以从我们查看的 AppSpec 文件中识别
这些事件名称中的部分名称。
应用程序将停止，它已终止 Web 服务器，
并安装了我的依赖项、我的 Web 服务器，
并且安装了这些文件，从 HTML 中
将我的索引复制到了 Web 服务器内容目录。
现在，要做的是启动 Web 服务器，
然后将调用我的测试脚本
并确保获得 200 成功响应。
此时，所有操作已成功完成。
我们来刷新一下。好的。

Chinese: 
我们正在查看测试页面，
实际上，我可以进行一些乘法运算。
真的令人感到非常兴奋。我可以进行除法运算。
此时，我们已完成一些冒烟测试，
我们对部署到生产充满信心。
我希望能使其面向客户。
为此，我将回到 CodeDeploy 控制台，
转到我的应用程序、HTML 网站。
利用 CodeDeploy，可以非常轻松地
进入控制台并手动部署你已在其他位置
部署的修订，在此示例中，
执行测试并部署到不同的生产组
或部署组，此情况下为生产组。
现在，我们已经知道修订已部署到测试，
因此下面我们继续并部署此修订。开始部署。
在此发布过程中，这显然是一个手动步骤，

English: 
So, we're looking at the test page,
and I can actually do some multiplication.
Very exciting. I can do divide.
So, at this point we've done a little
bit of smoke testing,
and we feel pretty confident in getting
this out to production.
We want to get it in front of our customers.
In order to do that, I'm going to
go back to the CodeDeploy console,
go to my application, HTML website.
So, CodeDeploy makes it really easy
to go into the console and manually
deploy a revision
that you've already deployed somewhere
else, in this case test,
and then to deploy that to a different
production group,
or deployment group, in this case,
production.
So, we already know that it's deployed
to test right now,
so let's go and deploy this revision.
And deploy.
So, in this release process, this
is obviously a manual step,

Portuguese: 
Estamos na página de teste
e eu consigo fazer multiplicações.
Muito legal. Também consigo fazer divisões.
Neste ponto, fizemos alguns testes
e estamos prontos para enviar
esse código para produção.
Queremos disponibilizá-lo para os clientes.
Assim, voltarei ao console do CodeDeploy
e acessarei meu aplicativo e o website HTML.
O CodeDeploy facilita a tarefa
de acessar o console e implementar
manualmente uma revisão
que já foi feita antes,
nesse caso, em um teste,
e de implementar em um grupo
de produção diferente,
nesse caso, a produção.
Como já sabemos o que foi
enviado para teste agora,
vamos implementar essa revisão. E pronto.
No processo de liberação, sem
dúvida essa é uma etapa manual.

Spanish: 
Ahora estamos viendo la página de prueba,
y puedo multiplicar.
Muy emocionante. Puedo hacer divisiones.
Hemos hecho algunas pruebas,
parece que se puede llevar a producción.
Queremos mostrárselo a nuestros clientes.
Para ello, voy a tener que
volver a la consola de CodeDeploy,
a mi aplicación y a mi sitio web HTML.
Con CodeDeploy es muy fácil
ir a la consola e implementar
una revisión manualmente
que ya hayas implementado en
otro sitio, en este caso uno de
prueba, y luego hacerlo en un
grupo de producción diferente,
o, en este caso, un grupo
de implementación de producción.
Ya sabemos que la implementación
de prueba ya está hecha,
ahora vamos a implementar esta revisión.
E implementamos.
En este proceso de lanzamiento,
este es un paso manual,

Chinese: 
此时必须有人来确定
我们完成了需要执行的所有测试，
继续操作并手动提升至生产。
因此，部署现在正在
我拥有的三个实例的外部运行。
我会让它稍微运行一下，
然后返回并讨论 Rob 已略微谈及的一些功能，
以便你更好地了解这些功能。
Rob 略微介绍了我们如何
对 amazon.com 网站的 Apollo 进行滚动更新。
CodeDeploy 具有相同功能，
因此，你实际上可以在不停机的情况下进行部署。
我们谈论了终止 Web 服务器，
安装所有这些文件，然后重新启动它们，
很明显，我们不希望生产站点出现任何停机。
对于只有一个实例的测试网站来说，这可能没问题，
但我们希望客户始终能够访问我们的网站。
实现的方式是，
我提到过，我们的一个负载均衡器后面有三个 EC2 实例，
CodeDeploy 现在在生产中要做的是，

Portuguese: 
Alguém tem que tomar uma decisão:
"sim, fizemos todos os
testes necessários",
e enviar essa revisão
manualmente para a produção.
Essa implementação está em execução
nas minhas três instâncias.
Enquanto essa implementação está em execução,
quero voltar para mostrar alguns dos recursos
que o Rob mencionou há pouco
com maiores detalhes.
O Rob falou um pouco sobre
as atualizações graduais
com o Apollo para o website da Amazon.
Como o CodeDeploy tem o mesmo recurso,
Você pode implementar sem
gerar tempo de inatividade.
Descrevemos o processo de
desativar o servidor e instalar
todos os arquivos, reativando
o servidor em seguida.
Certamente, tempo de inatividade não é
algo desejável no nosso local de produção.
Para o teste, não há problema,
pois temos uma única instância.
No entanto, queremos que nossos clientes
sempre possam acessar nosso website.
Eu mencionei que tenho
três instâncias EC2 atrás do load balancer.
Agora, na produção, o CodeDeploy

Spanish: 
alguien tiene que decidir que sí,
que hemos hecho todas las
pruebas que necesitábamos
y ahora lo trasladamos
manualmente a producción.
Esta implementación ahora se está ejecutando
en las tres instancias que tengo.
Voy a dejar que se ejecute
y a hablar un poco de las funciones
que mencionó Rob,
y mostrarlas aquí.
Rob explicó cómo hacemos
las actualizaciones acumulativas
con Apollo para el sitio web de amazon.com.
CodeDeploy tiene la misma función,
pueden implementar sin tiempo de inactividad.
Hemos hablado de desconectar el servidor web,
instalar los archivos,
y luego volver a montarlos,
y no queremos tiempo de inactividad
en nuestro sitio de producción.
Esto seguramente funcione en pruebas
donde hay una sola instancia,
pero queremos que los clientes siempre
puedan acceder a nuestro sitio web.
Esto va a funcionar así:
he mencionado que tengo tres instancias EC2
detrás de un balanceador de carga,
CodeDeploy, lo que está haciendo
ahora mismo en producción

English: 
someone has to decide at this point that, yes,
we've done all the tests that we need to do
and go and manually promote that
to production.
So, that deployment is running now
out to the three instances that I have.
I'm going to let that run for a little bit
and I want to go back and talk about
some of the features
that Rob talked about a little bit
and give you a better visual of those.
So, Rob talked a little bit about
how we do rolling updates
with Apollo for the amazon.com website.
And CodeDeploy has the same feature
so you can actually deploy without downtime.
We talked about bringing down the
web server,
installing all those files, and then
bringing them back up,
we obviously don't want any downtime
for our production site.
That's probably fine for test where
we have that single instance,
but we want our customers to always
be able to access our website.
So, how that's going to work is
I mentioned that I have three EC2
instances behind a load balancer, 
CodeDeploy, what it's doing right
now in production,

Chinese: 
将一个实例从负载均衡器中取出，
这样一来，此时所有客户流量
将流向仍然在负载均衡器后的两个实例，
这两个实例仍然在运行该应用程序的版本 1。
在这个实例上，现在已升级到版本 2。
完成升级后，会将该实例
重新放置到负载均衡器中，并滚动到下一个实例，
将下一个实例从负载均衡器中取出。
现在，我们的客户流量大约有 50% 流向 V2，
50% 流向 V1，但我们的客户始终能够访问该网站。
它将滚动到下一个实例，所有实例最终将
回到负载均衡器中，并且所有实例均为版本 2。
对于此功能，实际上我们在 GitHub 上的 AWS 实验室组织中
为你提供了一些示例脚本，你可以将它们用于
自己的应用程序。
我将使用其中几个脚本。

English: 
is it's taking a single instance
out of that load balancer
so that at this point all of your
customer traffic
is flowing to the two that are still
behind the load balancer,
still running that version one of
the application.
So, on that single instance it's
now upgrading it to version two.
Once it's finished with that, it's
going to put that instance
back in the load balancer and roll
onto the next one,
take it out of the load balancer.
Now we have our customer traffic
going to sort of 50% V2
and 50% V1, but our customers are
always able to access that website.
It will roll to the next one, and
finally everything's back
in the load balance, and everything's
on version two.
And for this feature, we actually
have some sample scripts for you
in the AWS Labs Organization on GitHub
that you can use
in your own application.
And I'm using a couple of them.

Portuguese: 
está extraindo uma única
instância desse load balancer
para que todo o tráfego de
clientes, nesse momento,
seja proveniente das outras duas instâncias
que ainda estão atrás do load balancer,
executando a versão um do aplicativo.
Assim, nessa instância específica, ele
está atualizando para a versão dois.
Quando terminar, o CodeDeploy
devolverá essa instância
ao load balancer e seguirá para a próxima,
que também será extraída do load balancer.
Agora, o tráfego de clientes está em
cerca de 50% para cada uma das versões,
mas os clientes conseguem acessar
o website a qualquer momento.
O CodeDeploy prosseguirá
para a próxima instância,
e tudo estará de volta no load balance
e atualizado para a versão dois.
Em relação a esse recurso, disponibilizamos
alguns exemplos de scripts
na Organização de Laboratórios
da AWS no GitHub.
Use-os com o seu próprio aplicativo.
Eu mesma estou usando alguns deles.

Spanish: 
es usar una sola instancia
del balanceador de carga
para que todo el tráfico de cliente
se dirija a las dos que aún están
detrás del balanceador de carga,
que siguen ejecutando esa primera versión
de la aplicación.
En esa única instancia ahora
se está actualizando a la versión dos.
Cuando termine, va a devolver esa instancia
al balanceador de carga
y pasará a la siguiente
para extraerla del balanceador de carga.
Ahora nuestro tráfico de cliente
irá casi al 50% V2
y 50% V1, pero nuestros clientes
siempre podrán acceder al sitio web.
Pasará a la siguiente y
finalmente todo volverá
al balanceador de carga;
todo está en la segunda versión.
Para esta función tenemos
algunos scripts de muestra
en organización de laboratorios de AWS
de GitHub que podrán usar
en sus aplicaciones.
Yo estoy usando algunas de ellas.

English: 
So, deregister from ELB, that's what's
going to take that instance
out of the load balancer and then
register with ELB,
that's going to put it back in the
load balance
and start serving traffic again.
The next feature I want to talk about
is our Auto Scaling integration.
I've mentioned a couple times that
I'm using Auto Scaling
for my test and production environments.
Auto Scaling is an AWS service to
help you scale up
or scale down your fleet of servers.
You can scale it all the way down to one
just like I'm doing in my test environment,
or you can scale it up to thousands
in your production environment.
Obviously, when you're scaling up
your environment
and adding new instances into your
deployment group,
you want to make sure that they have
the latest application version.
You don’t want them to start serving
customer traffic
with some old version of the application
that you had
baked into your army, maybe.
So, CodeDeploy is actually able to
hook into the Auto Scaling lifecycle
and catch that instance before it's added.
CodeDeploy is going to deploy the
latest version

Portuguese: 
Cancele o registro no ELB
para tirar a instância
do load balancer e, em
seguida, refaça o registro
para devolver essa instância ao load balance
e reiniciar a veiculação do tráfego.
O próximo recurso que apresento é a
nossa integração de Auto Scaling.
Falei algumas vezes que uso o Auto Scaling
nos meus ambientes de teste e produção.
O Auto Scaling é um serviço da
AWS que ajuda você a ampliar
ou reduzir seu grupo de servidores.
Você pode reduzir o número
de servidores para um,
como estou fazendo no ambiente de teste,
ou pode passar a usar milhares
no ambiente de produção.
Certamente, ao ampliar seu ambiente
e adicionar novas instâncias
ao seu grupo de implementação,
convém verificar se elas dispõem da
versão mais recente da aplicação.
Não é recomendável começar a
veicular tráfego de clientes
com uma versão mais antiga do aplicativo
reaproveitada na sua AMI, talvez.
O CodeDeploy consegue se conectar
ao ciclo de vida do Auto Scaling
e usar uma instância antes
de ela ser adicionada.
O CodeDeploy implementa a versão mais recente

Spanish: 
Al cancelar el registro de ELB
se sacará esa instancia
del balanceador de carga y
al registrarla con ELB
se volverá a incluir en el balanceador de
carga para empezar a servir tráfico de nuevo.
Ahora les voy a hablar de la función
de integración de Auto Scaling.
He mencionado varias veces
que uso Auto Scaling
en mis entornos de prueba y producción.
Auto Scaling es un servicio AWS
para aumentar o reducir
la flota de servidores.
Pueden reducirla a uno,
tal y como estoy haciendo
en mi entorno de prueba,
o aumentarla en mil más
en su entorno de producción.
Evidentemente, cuando aumente su entorno
y añada nuevas instancias
a su grupo de implementación,
debe asegurarse de tener
la última versión de la aplicación.
No conviene servir tráfico a los clientes
con una versión antigua
de la aplicación previamente
integrada en su AMI.
CodeDeploy es capaz de vincularse
con el ciclo de vida de Auto Scaling
y captar esa instancia antes de que se añada.
CodeDeploy implementará la última versión

Chinese: 
从 ELB 取消注册，可从负载均衡器
取出实例，然后向 ELB 注册，
可将实例放回负载均衡器，
并再次开始处理流量。
我想讨论的下一个功能是 Auto Scaling 集成。
我曾提到过几次，我正在将 Auto Scaling
用于我的测试和生产环境。
Auto Scaling 是一项 AWS 服务，可帮助你扩展或缩减
你的服务队列。
你可以将其缩减到只剩一个，
就像我在测试环境中所做的那样，
也可以在生产环境中将其扩展到数千个。
很明显，当你扩展你的环境
并向部署组添加新实例时，
你需要确保它们具有最新的应用程序版本。
你不希望使用你可能已
包含到 AMI 中的应用程序的旧版本
开始处理客户流量。
实际上，CodeDeploy 能够进入 Auto Scaling 生命周期
并在该实例被添加前将其捕获。

English: 
of your application that's configured,
and then it's going to add it to
the load balancer.
So, you don't need to worry as you're
scaling up your fleet
that your customers aren't getting
the latest version
of your application with all its
great features.
The final feature that I want to
talk about is health tracking.
Rob mentioned this a little bit,
and we want to make sure with CodeDeploy
that we're going to catch any deployment problems
before they're able to get out to
the entire fleet.
So, we know that problems happen,
bugs get out into production,
but we want to be protected from
that getting out into your entire fleet
and having a complete outage of your website
if for some reason a bad version gets out.
So, what's going to happen is let's say
we have a new version of our application,
and for some reason that causes the web server
not to give successful responses.
Maybe we accidently deleted the HTML file
and now it's giving 404s.
We want to make sure that that definitely
does not get out
to the rest of the fleet.

Portuguese: 
do seu aplicativo que ainda funcione,
adicionando-a ao load balancer.
Dessa forma, ao ampliar seu
número de servidores, não se
preocupe se os clientes estão
acessando a versão mais recente
do seu aplicativo, com todos os
recursos incríveis que só ela oferece.
O último recurso que apresento é
o acompanhamento de integridade.
Novamente, o Rob falou um pouco sobre isso.
Com o CodeDeploy, queremos garantir
a identificação dos
problemas de implementação
antes que eles se espalhem
por todos os servidores.
Sabemos que problemas ocorrem, que
às vezes bugs vão para a produção,
mas é importante se proteger de
um erro em todos os servidores
e de um problema mais sério no seu website
caso uma versão inadequada seja publicada.
Digamos que temos
uma nova versão do aplicativo
que, por algum motivo,
impede o servidor da Web
de enviar as respostas adequadas.
É possível que o arquivo
HTML tenha sido excluído,
o que está gerando erros 404s.
É importante garantir que
esse erro não se replique
no restante dos servidores.

Spanish: 
de su aplicación antes de que se configure,
y luego la añadirá al balanceador de carga.
Así que al aumentar su flota,
no debe preocuparse
de que sus clientes
no reciban la última versión
de su aplicación
con todas sus estupendas funciones.
Por último, les quiero hablar
de la función de seguimiento de estado.
Rob la mencionó por encima,
y con CodeDeploy queremos asegurarnos
de que vamos a detectar
cualquier problema de implementación
antes de que pase a toda la flota.
Sabemos que puede haber problemas,
hay errores que se cuelan en producción,
pero queremos evitar
que lleguen a toda la flota
y que se interrumpa su sitio web si,
por la razón que sea, sale una mala versión.
Lo que va a ocurrir es, digamos que tenemos
una nueva versión de nuestra aplicación,
y por algún motivo eso provoca
que el servidor web
no dé respuestas positivas.
Quizá hemos eliminado por
error el archivo HTML
y ahora sale el error 404.
Hay que asegurarse de que esto no llegue
al resto de la flota.

Chinese: 
CodeDeploy 将部署已配置的应用程序的最新版本，
然后将其添加到负载均衡器。
因此，你在扩展队列时不必担心
客户未获得具有
其所有出色功能的最新版本的应用程序。
我想讨论的最后一个功能是运行状况跟踪。
Rob 略微谈到过这个功能，我们希望通过 CodeDeploy 确保
我们将在任何部署问题
在整个队列中出现前发现它们。
我们知道出现了问题，生产环境中出现了错误，
但我们希望在出于某服务原因使用了错误的版本时
受到保护，以免问题和错误
进入整个队列，从而导致网站完全中断。
即将发生的情况是，假设
我们有应用程序的新版本，
并且出于某个原因
导致 Web 服务器不能提供成功响应。
我们可能意外删除了 HTML 文件，
现在它正在显示 404 代码。
我们希望确保队列的其余部分
绝对不会出现这种情况。

Chinese: 
因此，无论你定义为成功的
应用程序的测试脚本是什么，基于该验证服务脚本，
此时 CodeDeploy 将停止部署。
此时，你可以选择部署一次新的修复，
并对部署组外的应用程序进行一次新的修订，
也可以选择回滚到应用程序的
已知良好版本，你知道该版本
将从 Web 服务器进行成功响应，
然后放置回负载均衡器。
那么，实际上我获得了失败的设置。
在这种情况下，我在 CodeDeploy 中有一个九个实例的队列，
我对其进行了配置，确保九个实例中
至少有八个实例正常运行。
这意味着，如果一个实例失败，
就会终止部署并使部署失败。
在这里，我可以看到，这个步骤确实失败了。

Spanish: 
CodeDeploy, en función de ese script
de servicio y comprobación,
sea como sea el script de prueba que se
defina para funcionar en su aplicación,
va a detener la implementación en ese punto.
En ese momento existe la opción
de implementar una corrección
y que el grupo de implementación
revise la aplicación,
o volver a una versión antigua
que funcione bien
de la aplicación, que sabemos que tendrá
buena respuesta del servidor web,
y devolverla al balanceador de carga.
En realidad la configuración va a dar error.
En este caso, tengo una flota
de nueve instancias en CodeDeploy,
y lo tengo configurado para que compruebe
que, como mínimo,
ocho de cada nueve instancias
funcionan bien.
Lo cual significa que
si hay un solo error,
la implementación se detendrá y será fallida.
Aquí veo el paso donde se produjo el error.

Portuguese: 
Assim, com base no script de serviço válido,
o CodeDeploy interromperá a
implementação nesse ponto,
seja lá qual script de teste tenha
sido definido para o seu aplicativo.
Nesse ponto, você pode
implementar uma nova correção
e fazer uma nova revisão do
aplicativo o grupo de implementação,
ou voltar a usar uma versão
antiga do seu aplicativo
que receberá uma resposta adequada
do servidor da Web
e devolvê-la para o load balancer.
Aqui, tenho uma falha de configuração.
Nesse caso, tenho um grupo de nove instâncias
no CodeDeploy e as configurei de modo que
pelo menos oito têm a integridade garantida.
Isso quer dizer que se
houver uma única falha,
a implementação será
interrompida e terá uma falha.
Aqui vejo a etapa que falhou.

English: 
So, CodeDeploy, based on that validate
service script,
whatever test script that you define
to be success for your application,
it's actually going to stop the deployment
at that point.
At that point you have the option
to either deploy a new fix
and do a new revision of your application
out to your deployment group,
or you can chose to roll back to
a good known version
of your application where you know
that it's going to do a
successful response from the web server
and put that back in the load balancer.
So, I actually have a failure set up.
In this case, in CodeDeploy I have
a fleet of nine instances,
and I have it configured to make
sure that I have a minimum
of eight out of nine instances that
are healthy.
So, what that means is there's a
single failure,
it's going to stop that deployment
and fail that deployment.
So, here I can see the step that did fail.

English: 
I can drill directly into the logs
that actually failed.
So, CodeDeploy is going to declare failure
if any of your scripts that you define
in the AppSpec file
give an error response.
So, in this case it was validate
service gave an error response.
I don't have to SSH into that instance,
grep through all these logs,
I can actually see the last little
bit of that script running
directly in the CodeDeploy console
so I can figure out what happened there.
So, at this point, let's go back
and check on the production deployment.
So, everything looks good, we have
success across the board.
We can go and refresh our production website.
We have the new version of the application running,
and then we can look at the dashboard
and see that across the board
we now have the new version of the
application running.
So, now that we've gone through the
release process

Spanish: 
Puedo consultar los registros y ver qué pasó.
CodeDeploy avisará de un error
si alguno de los scripts definidos
en el archivo AppSpec
da una respuesta de error.
En este caso fue mi servicio de validación
el que dio una respuesta de error.
No hace falta usar SSH en esa instancia,
ni usar grep en todos los registros,
se ve hasta el más mínimo detalle
del script ejecutándose
en la consola de CodeDeploy,
así que se puede ver lo que ha pasado.
Llegados a este punto, vamos a
comprobar la implementación de producción.
Parece que todo está bien,
en general todo ha salido bien.
Podemos actualizar nuestro
sitio web de producción.
La nueva versión de la
aplicación se está ejecutando.
Al consultar el panel
podemos comprobar que en todas partes
se está ejecutando la nueva
versión de la aplicación.
Ahora que ya hemos revisado
el proceso de lanzamiento

Chinese: 
我可以直接深入讨论实际失败的日志。
因此，如果你在 AppSpec 文件中
定义的任何脚本提供错误响应，
CodeDeploy 将宣布失败。
在此示例中，提供了错误响应的是验证服务。
我无需通过 SSH 进入该实例，利用 grep 搜索所有这些日志，
我实际可以看到直接在 CodeDeploy 控制台中
运行的脚本的最后一小部分，
因此我可以了解发生的情况。
现在，让我们回过头来看看生产部署。
一切正常，从整体上看我们成功了。
我们可以继续并刷新生产网站。
我们正在运行应用程序的新版本，
然后我们可以查看控制面板，从整体上看，
我们现在正在运行应用程序的新版本。
现在，我们完成了我为网站设置的发布过程，

Portuguese: 
Consigo acessar diretamente os
logs que apresentaram falha.
O CodeDeploy acusará a falha
se os scripts definidos no arquivo AppSpec
derem uma resposta de erro.
Nese caso, foi meu serviço de validação
que deu uma resposta de erro.
Não preciso criar chaves SSH para essa
instância nem explorar todos os logs.
Basta ver o último trecho
do script em execução
diretamente no console do CodeDeploy
para entender o que ocorreu.
Nesse ponto, vamos voltar e verificar
a implementação da produção.
Está tudo certo, temos céu de brigadeiro.
Podemos atualizar nosso website de produção.
A nova versão do aplicativo está em execução.
Se olharmos para o painel, veremos
que a nova versão do aplicativo
está em execução em todas as etapas.
Agora que você concluiu
o processo de liberação

Spanish: 
establecido para mi sitio web,
les voy a mostrar el proceso
de lanzamiento del servicio web Go,
la API de la calculadora.
Pero como les decía antes,
esto es un poco más complicado.
Debo seguir un paso de creación
para compilar el código Go
y tener elementos que implementar;
luego quiero añadir
algunas pruebas automatizadas
para comprobar que no se cuelan
errores en producción.
Para el servicio web de la calculadora,
tengo un repositorio GitHub
muy similar al sitio web.
Ya está empaquetado para CodeDeploy.
Tenemos el archivo AppSpec
y los scripts preparados
para la instalación.
Solo tengo un archivo de lenguaje Go
para definir mi servicio web,
y ya he creado una aplicación
en CodeDeploy
para este servicio web.
Igual que en mi sitio web,
tengo un entorno de prueba
y un entorno de producción.

Portuguese: 
que eu configurei para o website,
quero explorar o processo
de liberação do serviço Go,
a API da calculadora.
Como disse anteriormente, esse
processo é um pouco mais complicado.
Preciso concluir uma etapa de
criação e compilar o código Go
para ter artefatos de implementação.
Também quero adicionar
mais testes automatizados
para garantir que não
haverá bugs na produção.
Como serviço da calculadora,
usarei o repositório do GitHub
que é bem parecido com o website.
Ele já vem com o pacote
criado para o CodeDeploy.
Temos um arquivo AppSpec
e outros arquivos de scripts
prontos para essa instalação.
Tenho um único arquivo da linguagem Go
para definir o serviço da Web.
Já criei um aplicativo no CodeDeploy
para esse serviço da Web.
Como no meu website, tenho
um ambiente de teste
e um ambiente de produção.

English: 
that I've set up for my website,
I want to take you through the release
process for the Go web service,
the calculator API.
So, as I said before, this is a little
bit more complicated.
I have a build step that I need to
do to compile that Go code
in order to have artifacts to deploy,
and then I also want to add a few
more automated tests
to make sure that no bugs get out
to production.
So, for the calculator web service
I have a GitHub repository
very similar to the website.
It's already packaged for CodeDeploy.
We have an AppSpec file
and we have scripts files ready to
install this.
I just have a single Go language file
that's going to define my web service,
and then I've already created an
application in CodeDeploy
for this web service.
So, just like on my website, I have
a test environment
and a production environment.

Chinese: 
我想引导你
完成 Go Web 服务，也就是计算器 API 的
发布过程。
正如我之前提到的，这有点复杂。
我需要执行一个构建步骤来编译该 Go 代码，
以便获得要部署的项目，
然后我还想添加几个更为自动化的测试，
以确保错误不会进入生产环境。
对于计算器 Web 服务，我有一个与网站很相似的
GitHub 存储库。
它已为 CodeDeploy 进行了打包。
我们有一个 AppSpec 文件，
还有一些准备好安装此存储库的脚本文件。
我只有一个 Go 语言文件，
该文件将定义我的 Web 服务，
然后我已在 CodeDeploy 中针对此 Web 服务
创建了一个应用程序。
就像在我的网站上一样，我有一个测试环境
和一个生产环境。

English: 
And you can see some of the revisions
that have been flowing through.
I mentioned that I need a build step,
I don't want my engineers to have
to build this on their desktops
and copy the artifacts somewhere,
I want to make this an automated process.
I have Jenkins set up on an EC2 instance -
this is a very popular build server.
And to integrate it with CodePipeline,
I have the CodePipeline plugin installed
in Jenkins.
So, what that's going to do is CodePipeline's
going to notify Jenkins
where there's new source that's available
to compile,
and then it's going to notify CodePipeline
when the build is done
and they are artifacts ready to move
on to the next step of deploy.
And then I just have a simple build
my Go code.
So, now that I have the build step
and I have the deploy step set up,
I want to link all of these together
in an automated release process.

Portuguese: 
É possível ver algumas revisões
que passaram durante o processo.
Eu havia mencionado que preciso
de uma etapa de criação.
Não quero que meus engenheiros
precisem criar tudo nos computadores
e copiem os artefatos para outro lugar.
Quero automatizar o processo.
Configurei Jenkins em uma instância do EC2.
É um servidor bastante usado.
Para integrá-lo ao CodePipeline,
instalei o plug-in do
CodePipeline no Jenkins.
O CodePipeline's notificará o Jenkins
quando houver um novo arquivo
disponível para compilação.
O CodePipeline receberá uma
notificação quando a criação terminar
e houver artefatos prontos para a
próxima etapa da implementação.
Agora tenho um código Go bem simples.
Agora que concluí a etapa de criação e
está tudo pronto para a implementação,
quero agrupar tudo em um processo
de liberação automatizado.

Spanish: 
Aquí pueden ver algunas
de las revisiones que se han aplicado.
He mencionado que necesito
un paso de creación,
no me interesa que los ingenieros
tengan que crearlo en sus equipos
y copiar los elementos en otro lugar,
me interesa que sea un proceso automatizado.
He configurado Jenkins en una instancia EC2,
es un servidor de creación muy conocido.
Y para integrarlo en CodePipeline,
he instalado el complemento
de CodePipeline en Jenkins.
Eso permitirá que CodePipeline
notifique a Jenkins
dónde hay un origen nuevo para compilar,
y luego notificará a CodePipeline
cuando haya terminado la creación
y haya elementos listos para
el siguiente paso de la implementación.
Tendré una creación sencilla con mi código Go.
Ahora que ya tengo configurado el paso
de creación y el de implementación,
voy a enlazarlos
en un proceso de lanzamiento automatizado.

Chinese: 
你会看到已通过的一些修订。
我提到过，我需要一个构建步骤，
我希望我的工程师无需在其桌面上构建这个
项目和在其他位置复制项目，
我希望确保这是一个自动化的过程。
我在一个 EC2 实例上设置了 Jenkins，
它是非常流行的构建服务器。
为了将其与 CodePipeline 集成，
我在 Jenkins 中安装了 CodePipeline 插件。
这样做的目的是，当有可编译的新源时，
CodePipeline 将通知 Jenkins，
然后 Jenkins 将在构建完成且它们准备好项目
以便移动到部署的下一个步骤时通知 CodePipeline。
随后，我将获得一个简单的构建我的 Go 代码。
现在我已具有构建步骤，并且设置了部署步骤，
我希望将所有这些链接在一起，形成一个自动化发布过程。

English: 
So, let's jump over to CodePipeline
- that's not CodePipline -
there we go. This is a really simple pipeline
that I've created with the pipeline
wizard in the CodePipeline console.
You can see I have a source step
that's going
to pull directly from GitHub.
Anytime that there's a new change,
CodeDeploy is going to automatically
pull that new change
for my repository and move it into
the build step.
So, in the build stage I have the
Jenkins server configured.
What that's going to do is, using
the CodePipeline plugin,
build my Go code, get my deploy artifacts ready,
and then it's going to hand it off
automatically to the beta stage,
which is where I have my test production
environment
set up with CodeDeploy.
So, with a developer pushing a single
change into my repository,
it's going to flow through the entire process

Chinese: 
让我们跳转到 CodePipeline，而不是 CodePipline，
开始吧。这真的是我在 CodePipeline 控制台中
使用管道向导创建的一个简单管道。
你会看到我有一个即将直接
从 GitHub 拉取的源步骤。
只要有新的更改，
CodeDeploy 就会自动针对我的存储库
拉取该新的更改并将其移动到构建步骤。
在构建阶段，我配置了 Jenkins 服务器。
要执行的操作时，使用 CodePipeline 插件，
构建我的 Go 代码，准备好我的部署项目，
然后系统会将其自动传递到测试阶段，
我将在测试阶段使用 CodeDeploy
设置我的生产环境。
如果开发人员将一个更改推送到我的存储库，
那么它会通过整个过程

Portuguese: 
Então, vamos voltar para o CodePipeline.
Pronto. Este é um
planejamento bastante simples
que criei com o ajudante do
console do CodePipeline.
Veja que a etapa de
código-fonte fará a extração
diretamente do GitHub.
Sempre que houver uma alteração,
o CodeDeploy a moverá automaticamente
para o meu repositório, avançando
para a etapa de criação.
Na etapa de criação, o servidor
Jenkins está configurado.
Com o uso do plug-in CodePipeline,
o código Go será criado e os artefatos
da implementação estarão prontos.
Em seguida, eles serão automaticamente
enviados para a etapa Beta,
onde tenho o ambiente de produção de teste
configurado com o CodeDeploy.
Quando um desenvolvedor salva uma
única alteração no meu repositório,
ela passará por todo o processo

Spanish: 
Pasemos ahora a CodePipeline
(eso no era CodePipline).
Venga, vamos.
Esta es una canalización muy sencilla
que he creado con el asistente de
canalización en la consola de CodePipeline.
Tengo un paso de código
fuente que se extraerá
directamente los datos de GitHub.
Cuando haya un cambio nuevo,
CodeDeploy lo va a extraer
para mi repositorio y lo va a enviar
al paso de creación.
En la fase de creación tengo el servidor
de Jenkins configurado.
Eso permitirá que,
con el complemento de CodePipeline,
cree mi código Go, prepare
mis elementos de implementación,
y proceda automáticamente a la fase beta,
que es donde tengo configurado el entorno
de producción de pruebas con CodeDeploy.
Si un desarrollador confirma
un cambio en mi repositorio,
pasará por todo el proceso

Spanish: 
hasta la implementación de prueba.
Verán que no tengo aquí
mi implementación de producción
y no tengo ninguna prueba,
aún no me siento muy cómoda
con implementar directa y
automáticamente a producción,
porque no tengo pruebas automatizadas.
No creo que Rob compruebe siempre
los cambios activos.
Vayamos a la canalización para
editar y añadir algunas pruebas.
Esta es la vista de edición
en la consola de CodePipeline.
Aquí podrán editar libremente
todo su proceso de lanzamiento,
así como gestionarlo y modelarlo.
Pueden añadir cambios nuevos y
pasos nuevos en cada fase.
Ahora vamos a editar la fase beta y
añadir una nueva acción.
Vamos a añadir una prueba,
y quiero añadir una prueba
de API para comprobar
que el comportamiento de cada API
para el sitio web de
calculadora sea correcto.
En la lista desplegable
de proveedor de pruebas

Portuguese: 
até chegar na implementação do teste.
Veja que não tenho a
implementação de produção aqui
and e também não tenho nenhum teste.
Prefiro não implementar direta
e automaticamente na produção,
pois não tenho testes automatizados.
Não devo confiar que o Rob sempre
fará a verificação de uma alteração.
Então, vamos acessar o planejamento
e editar e adicionar testes.
Essa é a visualização de edição
do console do CodePipeline.
É aqui que você edita todo o seu
processo de liberação com liberdade,
além de gerenciar e simulá-lo aqui.
É possível adicionar novas alterações e
até mesmo novas etapas em cada fase.
Vamos editar a etapa Beta e
adicionar uma nova ação.
Adicionaremos um teste,
e quero que seja um teste de API
para garantir que as APIs da calculadora
estão funcionando adequadamente.
No meu suspenso dos testes, é possível

English: 
right into test deployment.
Now, you'll notice that I don't have
my production deployment here
and I don't have any test, I'm not
very comfortable yet
deploying directly, automatically,
into production
because I don't have any automated tests.
I don't quite trust Rob to always
check in a working change.
So, let's go into the pipeline and
edit and add some tests.
This is the edit view in the CodePipeline console.
This is where you can freely edit
your entire release process,
manage, and model your release process here.
You can add new changes and you can
add new steps into each stage.
So, let's edit the beta stage and
add a new action.
We're going to add test,
and I want to add an API test to make sure
that the behavior of each of those APIs
for the calculator website is correct.
In a test provider dropdown, you can see

Chinese: 
直接进入测试部署。
现在，你将发现，我在这里没有进行生产部署，
也没有进行任何测试，我感觉不太舒服，
但仍然直接、自动部署到生产环境中，
因为我没有进行任何自动化测试。
我并不十分相信 Rob 会始终签入工作更改。
因此，让我们进入管道并编辑和添加一些测试。
这是 CodePipeline 控制台中的编辑视图。
你可以在这里自由地编辑整个发布过程，
管理发布过程并为其建模。
你可以添加新的更改，也可以将新的步骤添加到每个阶段。
让我们来编辑测试阶段并添加一项新操作。
我们即将添加测试，
我希望添加一个 API 测试，以确保
所有这些 API 对计算器网站
的行为是正确的。
在测试提供商下拉列表中，

Spanish: 
pueden ver un par de fantásticos
sistemas integrados de socios.
Es mucho más fácil usar hoy
una de estas herramientas
para sus aplicaciones, para empezar
a usarlas con CodePipeline.
Voy a elegir Runscope
para hacer una prueba de API.
Haré clic en conectar.
Eso me va a llevar a Runscope,
donde tengo configurada una prueba
para crear la integración
y añadir la acción.
Eso es lo que hay que hacer para añadir
esta prueba de API automatizada
a mi canalización.
Vamos a entrar y añadir una prueba de carga.
Quiero asegurarme de que
cuando llegue a producción,
los cambios funcionen bien
en la carga máxima de producción.
Vamos a elegir BlazeMeter y añadir
esa acción: conectar.
Esto me llevará directamente a BlazeMeter.

Portuguese: 
ver algumas integrações dos nossos parceiros.
Facilita bastante se você usar
uma das ferramentas existentes
com o seu aplicativo, para
usá-la com o CodePipeline.
Escolherei o Runscope, pois
quero fazer um teste de API.
Clico em "Conectar". Isso me leva
diretamente para o Runscope.
Como já tenho um teste
configurado, crio a integração
e adiciono a ação.
E isso é tudo que preciso fazer para
adicionar esse teste de API automatizado
ao meu planejamento.
Agora vamos adicionar um teste de carga.
Quero ter certeza de que quando
chegar o momento da produção,
as alterações funcionarão adequadamente
com a carga maior da produção.
Vamos escolher o BlazeMeter,
adicionar essa ação e conectar.
Isso me levará diretamente para o BlazeMeter.

English: 
just a couple of our great partner
integrations.
It makes it really easy if you're
using one of these existing tools
for your applications today, to start
using it with CodePipeline.
So, I'm going to choose Runscope,
I want to do an API test.
I'll click connect. That's going
to take me right to Runscope
where I already have a test set up,
create that integration,
and add the action.
And that's all that it takes to add
this automated API test
into my pipeline.
Let's also go in and add a load test.
I want to make sure that once it
gets into production
any change is going to perform properly
in the higher load of production.
So, let's choose BlazeMeter, add
that action - connect.
That's going to take me right into
BlazeMeter.

Chinese: 
你只能看到几个较大的合作伙伴集成。
如果你现在正在将这些现有工具之一
用于你的应用程序，那么开始将其用于 CodePipeline 将非常轻松。
我将选择 Runscope，我想执行一次 API 测试。
我会单击“connect”。此步骤将带我直接进入 Runscope，
我已在此设置测试、创建集成
并添加操作。
这是将此自动化 API 测试添加到我的管道中
所需的全部步骤。
下面我们来添加一个负载测试。
我希望确保进入生产后，
任何更改均能在更大的生产负载下正确执行。
我们选择 BlazeMeter，添加“connect”操作。
这会直接带我进入 BlazeMeter。

Portuguese: 
Como já tenho um teste de carga
configurado no BlazeMeter,
basta adicionar essa ação.
Veja que adicionei essas duas
ações lado a lado nessa etapa.
Isso é recomendável porque significa
que elas serão executadas em paralelo.
Adoro executar testes em paralelo,
pois isso significa que vou detectar
todos os problemas que ocorrerem
por causa de uma alteração no
fluxo do meu planejamento.
Quanto às alterações aprovadas,
quero enviá-las para a produção
e para os clientes mais rapidamente.
Como fiz alguns testes, sei que vou detectar
os maiores erros antes da etapa de produção.
Então, vamos adicionar a etapa de produção.
E dessa vez, adicionaremos a implementação
e escolheremos o CodeDeploy.
Eu já tenho aquele aplicativo
que mostrei no serviço Go.
Dessa vez, trataremos do
grupo de implementação para produção.

Spanish: 
Ya tengo configurada una prueba
de carga con BlazeMeter,
ahora añadiré la acción.
Verán que he añadido estas dos acciones
paralelamente en esta fase.
Las añado una junto a otra
porque así se ejecutarán paralelamente.
Me encanta hacer pruebas en paralelo,
porque así detectaré cualquier problema
con el cambio a medida que avance
por la canalización,
pero, los cambios que salgan bien
los llevaré más rápidamente a producción
y también a mis clientes.
Ahora que ya tengo algunas pruebas, confío
en que se detectarán errores importantes
antes de que lleguen a producción.
Ahora vamos a añadir la fase de producción.
Esta vez añadiremos la implementación
y elegiremos CodeDeploy.
Ya tengo la aplicación que les he mostrado
para el servicio web Go,
y esta vez lo haremos
con el grupo de implementación de producción.

English: 
I already have a load test set up
with BlazeMeter
and we'll add that action.
You'll notice that I added these
two actions side by side in this stage.
What I like to do is add these side by side
because that means they're going
to run in parallel.
So, I love doing tests in parallel,
it means that I'm going to catch
any problems that are happen
with the change that's flowing through
the pipeline,
but I'm going to - for any successful change
I'm going to get that out to production faster
and into the hands of my customers.
So, now that I have a couple of tests,
I feel pretty confident
that that's going to catch any major errors
before they get into productions.
So, let's add the production stage.
And this time we'll add deploy and
choose CodeDeploy.
I already have that application that
I showed you
for the Go web service, and then
this time we'll go
for the production deployment group.

Chinese: 
我已使用 BlazeMeter 设置负载测试，
我们将添加该操作。
你将发现，在此阶段我同时添加了这两个操作。
我想做的是同时添加这两个操作，
因为这意味着它们将同时运行。
我喜欢并行测试，
这意味着我将发现
通过管道的更改中发生的任何问题，
对于任何成功的更改，
我将使其更快进入生产，
并到达客户手中。
现在，我已有一些测试，我坚信，
这些测试将在任何主要错误
进入生产之前发现它们。
下面我们添加生产阶段。
这一次，我将添加部署并选择 CodeDeploy。
我已为 Go Web 服务准备了我向你展示过的
应用程序，这次我将选择
生产部署组。

English: 
So, at this point I have modeled
out my entire release process.
I want to show you what it looks like
when we're trying to catch some of the errors
that Rob has added in.
I'm really picking on Rob today.
I have a baked web service that has
a failure in it.
So, it looks just like the one we
just created
but it has a failure.
One of the great things about the
CodePipeline console is
that you can actually link directly
to that failure
and drill in and see what's going on.
So, we can scroll down to the failure,
and we're not getting the behavior
we expected for divide by zero.
So, at this point, what you can do is
you can link directly into that GitHub repo,
direct link there, go in, fix the
change, push that through,
and then that will go from source to build,
we'll get artifacts deployed into test,
hopefully it will pass the API test this time,

Spanish: 
Hasta ahora he modelado
todo mi proceso de lanzamiento.
Ahora quiero mostrarles cómo
detectar los errores
que ha añadido Rob.
Hoy la tengo con Rob.
Vemos un servicio web integrado
con un error.
Se parece al que acabamos de crear
pero tiene un error.
Una de las cosas buenas
de la consola de CodePipeline
es que puedes enlazar directamente
con el error,
profundizar en él y ver qué ocurre.
Al desplazarnos hasta el error
vemos que el comportamiento
no es el esperado en la división por cero.
A estas alturas pueden enlazar
directamente a ese repositorio de GitHub,
entrar, corregir el cambio y transferirlo,
lo cual pasará del origen a la versión,
los elementos se implementarán en la prueba
y, esperemos, pasarán la
prueba de API esta vez,

Portuguese: 
A essa altura, já fiz a simulação de
todo o meu processo de liberação.
Quero mostrar como fazemos
para corrigir os erros
que o Rob adicionou.
Estou pegando no pé dele, não estou?
Achei um serviço da Web com falha.
Ele se parece bastante com
aquele que acabamos de criar,
mas tem uma falha.
Uma das melhores coisas sobre
o console do CodePipeline
é que você pode criar um
link direto para a falha
e acessar para entender o que aconteceu.
Role a tela para baixo até encontrar a falha.
Não recebemos o comportamento
esperado para divisão por zero.
Nesse momento, você pode criar
um link direto para o repositório do GitHub,
entrar, corrigir a alteração e enviá-la.
Ela passará de código-fonte para a criação.
Temos os artefatos implementados no teste,
espero que a alteração seja
aprovada no teste da API.

Chinese: 
现在我已展示整个发布过程。
我想向你展示如何
尝试发现 Rob 加入的一些错误。
今天，我要找找 Rob 的麻烦。
我准备了一个有错误的 Web 服务。
它看起来和我们刚刚创建的那个一样，
但它有错误。
CodePipeline 控制台的一项出色功能是，
可让你直接链接到该错误
并深入了解发生的情况。
因此，我们可以向下滚动到该错误，
我们不希望得到被零除的预期行为。
此时，你可以这样做，
直接链接到 GitHub 存储库，
进入存储库，修复更改，设法完成，
然后从源进入构建，
我们将获得部署到测试的项目，
希望这次它能通过 API 测试，

Spanish: 
para después pasar directamente a producción.
Hasta ahora les he mostrado CodeDeploy
y CodePipeline,
ahora les mostraré cómo mover
esos repositorios en CodeCommit.
Vamos a añadir un sencillo
sitio web de calculadora,
copiamos la URL.
Ya tengo este repositorio en mi escritorio
así que lo voy a añadir como un nuevo remoto,
y envío todo.
Ahora que mi repositorio está en CodeCommit,
puedo profundizar en el repositorio.
Esta función nueva la lanzamos el lunes,

Portuguese: 
Em seguida, enviamos diretamente
para a produção depois de tudo isso.
Agora que mostrei o CodeDeploy
e o CodePipeline para vocês,
quero mostrar como mover os
repositórios no CodeCommit.
Vamos adicionar um website simples
de calculadora e copiar o URL.
Como já tenho esse repositório
na minha área de trabalho,
vou adicioná-lo como um novo remoto,
com tudo dentro dele.
Agora que esse repositório foi movido
para o CodeCommit, posso acessá-lo.
Esse novo recurso foi lançado
na segunda-feira passada,

English: 
and then get straight into production
after that.
So, now I've showed you CodeDeploy
and CodePipeline,
I want to show you how we can move
these repositories in CodeCommit.
Let's add simple calculator website,
copy the URL.
I have this repository on my desktop already
so I'm just going to add that as
a new remote,
push everything up.
So, now that my repository is now
moved into CodeCommit,
I can drill into the repository.
This is a new feature that we just
launched on Monday,

Chinese: 
然后直接进入生产。
现在，我已向你展示 CodeDeploy 和 CodePipeline，
我想向你展示如何在 CodeCommit 中移动这些存储库。
让我们来添加简单的计算器网站，
复制 URL。
我已将此存储库保存在我的桌面，
因此我只需将它添加为新的远程项目，
就可以推送所有内容。
现在，我的存储库已移动到 CodeCommit 中，
我可以深入了解存储库。
这是一项我们在星期一刚刚推出的新功能，

Portuguese: 
veja o código no console.
Estou vendo todos os meus códigos
no console do CodeCommit.
Para finalizar, mostrei algumas
integrações dos nossos parceiros.
Vimos o GitHub, o Runscope e o BlazeMeter.
Essa é a lista completa
das nossas integrações.
Eles oferecem ótimas soluções end-to-end.
Como alguns deles estão aqui hoje,
vocês têm a oportunidade de ver
como essas integrações podem ajudar
no desenvolvimento da sua nuvem.
Visite o quiosque do AWS
DevOps no stand do AWS,
para receber seu passaporte de parceiros.
Se você conseguir o carimbo de três
parceiros nesse evento no seu passaporte,
traga-o de volta ao quiosque do DevOps
para receber créditos do AWS como brinde.
Também quero informar sobre as sessões
relacionadas a esse assunto
que teremos nesse evento.

English: 
the code browsing in the console,
and I can actually see all of my
code right in the CodeCommit console.
So, to wrap up, I showed you a couple
of our partner integrations.
We looked at GitHub, and Runscope,
and BlazeMeter.
This is our full list of partner
integrations.
They have some great end to end solutions,
and some of them are here today,
so you have the opportunity to really see
how they could benefit your cloud
development.
If you go to the AWS DevOps kiosk
in the AWS booth,
you can pick up a partner passport.
If you get three partners who are
here at reInvent to stamp them,
bring that back to the DevOps kiosk,
and you'll get a little gift of some
AWS credits.
I also want to give a little bit of a plug
for some of the related sessions
that are here at reInvent.

Chinese: 
可用于在控制台中浏览代码，
我可以直接在 CodeCommit 控制台中查看所有代码。
总结一下，我向你展示了我们的一些合作伙伴集成。
我们了解了 GitHub、Runscope 和 BlazeMeter。
这是我们的合作伙伴集成的完整列表。
这些合作伙伴有一些出色的端到端解决方案，
而且他们中有一些人今天来到了现场，
你将有机会真正了解
他们如何让你的云开发获益。
如果你进入 AWS 展台中的 AWS DevOps 网亭，
就可以领取合作伙伴护照。
如果有三个在 reInvent 现场的合作伙伴为你的护照盖章，
请将护照带回 DevOps 网亭，
你将获得一些 AWS 积分。
我还想为 reInvent 现场的
一些相关会议打个小广告。

Spanish: 
la exploración de código en la consola.
Puedo ver todo el código
directamente en la consola de CodeCommit.
Les he mostrado algunos de nuestros
sistemas integrados de socios.
Hemos visto GitHub Runscope y BlazeMeter.
Esta es la lista completa
de sistemas integrados de socios.
Hay soluciones de extremo
a extremo estupendas,
algunas de ellas aquí hoy
para que puedan ver
cómo les pueden ayudar
en su desarrollo de la nube.
En el punto de información
de AWS DevOps en la zona de AWS
podrán conseguir un pase de socio.
Con el sello de tres socios
que estén aquí en reInvent,
en el punto de información de DevOps
les darán créditos de AWS de regalo.
También me gustaría recomendarles
algunas de las sesiones relacionadas
aquí en reInvent.

Portuguese: 
Logo após essa apresentação, conheça
mais detalhes do CodeDeploy
e saiba mais sobre a automação
das implementações de software.
Repito o convite: visite-nos
no quiosque do DevOps.
É uma grande oportundiade de saber
como nossos parceiros podem ajudar você.
O Rob, eu e alguns parceiros estamos
disponíveis para responder perguntas.
Estaremos no hall à frente
para quem quiser fazer perguntas.
Não se esqueçam de preencher
nossas avaliações.

Spanish: 
Después de esta charla
podrán conocer más sobre CodeDeploy
y sobre cómo automatizar sus
implementaciones de software.
Visítennos en el punto de
información de DevOps.
Es una gran oportunidad para ver
cómo les pueden ayudar nuestros socios.
Rob y yo, y nuestros socios,
responderemos a sus preguntas.
Pueden hacernos preguntas aquí
mismo o fuera en el pasillo,
si tienen cualquier duda.
Y no duden en rellenar las valoraciones.

Chinese: 
紧接着本场谈话，你可以深入了解 CodeDeploy，
并详细了解如何实现软件部署的自动化。
正如我所说，你可以在 DevOps 网亭与我们联系。
你可以获得不错的机会来了解
我们的合作伙伴如何使你获益。
Rob 和我，以及我们的一些合作伙伴将在这里回答问题。
如果你有任何问题，我们就在前台和大厅
接受咨询。
当然，也请填写你的评估。

English: 
Right after this talk you can dive
deeper into CodeDeploy
and learn more about automating your
software deployments.
Like I said, please check us out
at the DevOps kiosk.
You have the great opportunity to see
how our partners can benefit you.
Rob and I and some of our partners
are here to answer questions.
We'll be taking questions up here
in the front and out in the hall
if you have any questions.
And definitely please fill out your
evaluations.
Thank you.
