1
00:00:00,040 --> 00:00:05,040
Oi pessoal, bem vindos a nossa 
exploração de hoje aqui no the 

2
00:00:05,040 --> 00:00:08,600
deep Dive. 
Vamos analisar juntos umas 

3
00:00:08,600 --> 00:00:13,400
práticas bem bem modernas. 
Sabe que estão mudando o jeito 

4
00:00:13,400 --> 00:00:17,600
de fazer software deployment 
contínuo e entrega contínua. 

5
00:00:17,960 --> 00:00:21,440
A gente está usando como base o 
livro engenharia de software 

6
00:00:21,440 --> 00:00:26,240
Moderna, do Marco Túlio Valente.
Olha, quem já passou por 

7
00:00:26,240 --> 00:00:30,120
lançamento de software talvez 
lembre daquela tensão, né? 

8
00:00:30,280 --> 00:00:33,640
Aquelas noites sem dormir, o 
medo de quebrar algo em 

9
00:00:33,640 --> 00:00:37,280
produção. 
O objetivo aqui é justamente 

10
00:00:37,280 --> 00:00:41,720
entender como essas práticas 
contínuas é tentam mudar isso. 

11
00:00:42,320 --> 00:00:46,080
Vamos desvendar o deploma de 
contínuo, A Entrega contínua. 

12
00:00:46,240 --> 00:00:50,280
Vê as diferenças porque falam 
tanto delas e como funcionam na 

13
00:00:50,280 --> 00:00:52,440
prática, segundo a nossa fonte 
aqui. 

14
00:00:53,160 --> 00:00:56,720
Muitas equipes já usam 
integração contínua, o CI. 

15
00:00:57,080 --> 00:01:00,600
O código é integrado direto no 
repositório principal, né? 

16
00:01:00,880 --> 00:01:04,120
Mas assim, só integrar não 
garante que o software tá pronto

17
00:01:04,120 --> 00:01:07,360
para o usuário, certo? 
Às vezes é algo completo que 

18
00:01:07,360 --> 00:01:10,680
ainda falta a polir. 
É aí que o próximo passo fica 

19
00:01:10,680 --> 00:01:13,360
importante. 
O que rola depois que o código 

20
00:01:13,360 --> 00:01:16,600
tá integrado e os testes básicos
passaram. 

21
00:01:16,720 --> 00:01:18,080
Exato. 
É. 

22
00:01:18,640 --> 00:01:22,320
É nesse ponto que entra o 
diploma entre contínuo o CD. 

23
00:01:22,760 --> 00:01:26,360
Ele pega essa base da integração
contínua, onde o código já é 

24
00:01:26,360 --> 00:01:30,680
verificado direto, né? 
E leva a automação pra um outro 

25
00:01:30,680 --> 00:01:35,640
nível. 
A filosofia é bem simples na 

26
00:01:35,640 --> 00:01:39,280
teoria, mas olha poderosa na 
prática. 

27
00:01:39,760 --> 00:01:43,320
Todo o comitê aprovado no brent 
principal, geralmente o master 

28
00:01:43,320 --> 00:01:45,760
ou o man. 
E que passa em toda esteira de 

29
00:01:45,760 --> 00:01:48,640
testes, vai automaticamente para
a produção. 

30
00:01:48,640 --> 00:01:52,600
Automaticamente, tipo, sem 
ninguém apertar um botão de vai.

31
00:01:52,600 --> 00:01:55,920
Exatamente. 
E essa é a grande virada, sabe? 

32
00:01:56,160 --> 00:01:58,840
Não tem uma pessoa ali 
decidindo, Ah, esse pedaço de 

33
00:01:58,840 --> 00:02:01,160
código pode ir. 
Se ele passou por todo o 

34
00:02:01,160 --> 00:02:04,440
processo automatizado de 
validação, que tem que ser bem 

35
00:02:04,440 --> 00:02:08,120
completo, bem rigoroso, ele vai 
para a produção e a gente tá 

36
00:02:08,120 --> 00:02:11,960
falando de um processo que pode 
levar horas ou às vezes, sei lá,

37
00:02:11,960 --> 00:02:15,080
minutos, dependendo. 
Da complexidade da 

38
00:02:15,080 --> 00:02:18,600
infraestrutura, a velocidade com
que uma mudança chega no usuário

39
00:02:18,600 --> 00:02:20,880
final é nossa, diminui 
drasticamente. 

40
00:02:20,880 --> 00:02:23,400
O material detalha um pouco esse
fluxo, né? 

41
00:02:23,400 --> 00:02:26,600
Como seria tipo um ciclo normal 
nesse modelo? 

42
00:02:26,720 --> 00:02:28,880
Sim, sim. 
O fluxo é bem claro. 

43
00:02:29,240 --> 00:02:33,400
Começa com o desenvolvedor ali 
na máquina dele, podando 

44
00:02:33,400 --> 00:02:37,320
testando localmente normal. 
Aí ele faz o comit para o 

45
00:02:37,320 --> 00:02:41,920
repositório central. 
Nisso, o servidor de CICD entra 

46
00:02:41,920 --> 00:02:44,680
em ação. 
Primeiro, ele compila roda os 

47
00:02:44,680 --> 00:02:47,720
testes mais rápidos, os 
unitários, para garantir que a 

48
00:02:47,720 --> 00:02:51,160
lógica daquele pedacinho está 
OK, isso a cada comit. 

49
00:02:51,520 --> 00:02:56,640
Ok, até aí parece bastante com 
OCI que a gente já conhece, onde

50
00:02:56,640 --> 00:02:59,960
que o deployment contínuo se 
diferencia mesmo? 

51
00:02:59,960 --> 00:03:04,600
A diferença crucial vem logo 
depois, de tempos em tempos, 

52
00:03:04,600 --> 00:03:08,080
talvez algumas vezes por dia, o 
servidor pega os comities 

53
00:03:08,080 --> 00:03:11,600
recentes que passaram nessa 
primeira fase e ainda não foram 

54
00:03:11,600 --> 00:03:14,800
para a produção. 
E aí ele dispara uma bateria de 

55
00:03:14,800 --> 00:03:18,480
testes bem mais parruda, 
digamos, testes de integração 

56
00:03:18,600 --> 00:03:20,360
pra ver se as partes conversam, 
né? 

57
00:03:20,760 --> 00:03:24,720
Testes de interface simulando o 
usuário, teste de performance 

58
00:03:24,760 --> 00:03:28,920
pra ver se não ficou lento, 
segurança, enfim, uma suíte 

59
00:03:28,920 --> 00:03:31,960
completa para garantir a 
qualidade e a estabilidade do 

60
00:03:31,960 --> 00:03:34,400
todo. 
E se tudo der certo, se passar 

61
00:03:34,400 --> 00:03:37,680
em tudo? 
Se e somente se todos esses 

62
00:03:37,680 --> 00:03:40,960
testes automatizados passarem 
sem falha nenhuma. 

63
00:03:41,280 --> 00:03:44,760
Aí sim, esses comits são 
automaticamente deploiados em 

64
00:03:44,760 --> 00:03:47,840
produção. 
O código novo entra no ar e os 

65
00:03:47,840 --> 00:03:51,640
usuários começam a usar a nova 
versão quase que imediatamente, 

66
00:03:51,880 --> 00:03:56,160
sem aquele evento de lançamento.
É uma esteira mesmo, do comit 

67
00:03:56,160 --> 00:03:59,960
até a produção. 
Nossa, isso soa muito eficiente,

68
00:03:59,960 --> 00:04:02,640
mas confesso que dá um frio na 
barriga. 

69
00:04:02,640 --> 00:04:05,280
Liberar código assim direto pra 
produção? 

70
00:04:05,440 --> 00:04:08,600
Como que isso não vira um caos 
de bug chegando pro usuário? 

71
00:04:09,000 --> 00:04:11,040
É, essa é a preocupação natural,
né? 

72
00:04:11,400 --> 00:04:13,760
E a resposta está na robustez do
processo. 

73
00:04:13,760 --> 00:04:18,160
Todo OCID não funciona sem uma 
cultura de testes assim muito 

74
00:04:18,160 --> 00:04:21,480
forte e uma automação que seja 
confiável de verdade. 

75
00:04:21,959 --> 00:04:25,040
A confiança para liberar 
automático vem dessa garantia 

76
00:04:25,040 --> 00:04:27,720
que a suíte de testes dá se algo
quebrar. 

77
00:04:27,720 --> 00:04:31,200
A ideia é que os testes peguem 
antes e se mesmo assim passar 

78
00:04:31,200 --> 00:04:33,200
alguma coisa. 
Como as atualizações são 

79
00:04:33,200 --> 00:04:35,800
pequenas e frequentes, 
geralmente é bem mais fácil 

80
00:04:35,800 --> 00:04:38,640
achar o problema e corrigir, 
fazer um roubeck ou um fixo 

81
00:04:38,640 --> 00:04:40,680
rapidinho. 
Do que naqueles lançamentos 

82
00:04:40,680 --> 00:04:42,400
gigantes. 
Entendi. 

83
00:04:42,400 --> 00:04:44,720
Faz sentido? 
E quais são os grandes 

84
00:04:44,720 --> 00:04:48,440
benefícios que a fonte destaca 
para justificar essa mudança 

85
00:04:48,440 --> 00:04:50,640
toda? 
Imagino que a velocidade seja o 

86
00:04:50,640 --> 00:04:53,880
principal a. 
Velocidade ou a redução no tempo

87
00:04:53,880 --> 00:04:57,240
de ciclo, né? 
O tal do lead time, esse é com 

88
00:04:57,240 --> 00:04:59,800
certeza, um dos mais óbvios e de
maior impacto. 

89
00:05:00,360 --> 00:05:05,920
Pensa no modelo antigo, várias 
funcionalidades F1F 2F 3. 

90
00:05:06,400 --> 00:05:10,000
Precisam ficar prontas, ser 
testadas juntas para formar um 

91
00:05:10,000 --> 00:05:13,640
pacotão de release que sai, sei 
lá, a cada mês. 

92
00:05:13,640 --> 00:05:18,160
Trimestre concedi assim que AF 
um tá pronta e passou nos 

93
00:05:18,160 --> 00:05:22,360
testes, pum vai pra produção 
logo depois da f 2 vai e assim 

94
00:05:22,360 --> 00:05:25,440
por diante. 
O resultado é um fluxo contínuo 

95
00:05:25,440 --> 00:05:29,000
de pequenas entregas, sabe, em 
vez daqueles blocos enormes e 

96
00:05:29,000 --> 00:05:31,320
espaçados. 
Isso parece que muda 

97
00:05:31,320 --> 00:05:34,520
completamente a dinâmica dos 
lançamentos mesmo. 

98
00:05:34,520 --> 00:05:37,040
Totalmente. 
E isso leva a outro benefício 

99
00:05:37,040 --> 00:05:40,680
chave, transformar os releases 
em não eventos. 

100
00:05:41,280 --> 00:05:45,200
Acaba aquela tensão do dia d 
sabe aquela mobilização, o 

101
00:05:45,200 --> 00:05:49,520
estresse, isso some. 
Como as liberações são pequenas,

102
00:05:49,520 --> 00:05:53,400
frequentes, automáticas, elas 
viram parte da rotina. 

103
00:05:54,080 --> 00:05:57,160
Se uma funcionalidadezinha não 
fica pronta para aquele ciclo, 

104
00:05:57,400 --> 00:06:00,520
não É o Fim do mundo, ela entra 
no próximo, talvez no dia 

105
00:06:00,520 --> 00:06:03,040
seguinte. 
A pressão na equipe diminui 

106
00:06:03,040 --> 00:06:04,960
muito. 
E o impacto disso nos 

107
00:06:04,960 --> 00:06:07,320
desenvolvedores? 
O livro fala algo sobre 

108
00:06:07,320 --> 00:06:10,200
motivação, né? 
Fala sim e é um ponto super 

109
00:06:10,200 --> 00:06:13,280
relevante. 
No modelo de ciclos longos, o 

110
00:06:13,280 --> 00:06:16,560
desenvolvedor pode trabalhar 
meses em algo sem ter a menor 

111
00:06:16,560 --> 00:06:21,160
ideia se aquilo vai ser útil, se
o usuário vai gostar, concedir o

112
00:06:21,160 --> 00:06:25,760
feedback é quase na hora, você 
faz algo pequeno e em horas ou 

113
00:06:25,760 --> 00:06:28,200
dias. 
Já consegue ver por métricas, 

114
00:06:28,200 --> 00:06:32,120
logs ou até feedback direto como
os usuários estão usando aquilo?

115
00:06:32,520 --> 00:06:35,640
Saber que seu trabalho está 
gerando impacto rápido e ter 

116
00:06:35,640 --> 00:06:38,840
essa resposta é um fator de 
motivação muito forte. 

117
00:06:38,880 --> 00:06:42,520
Além da motivação, essa 
capacidade de lançar rápido 

118
00:06:42,520 --> 00:06:45,840
também deve abrir portas pra 
experimentar mais, imagino. 

119
00:06:45,880 --> 00:06:50,120
Exatamente, o cidi ajuda demais 
na experimentação e no 

120
00:06:50,120 --> 00:06:52,760
aprendizado rápido. 
As equipes podem lançar uma 

121
00:06:52,760 --> 00:06:56,320
ideia nova, talvez para um grupo
pequeno de usuários, no começo 

122
00:06:56,440 --> 00:06:59,000
usando o featur flags, por 
exemplo, muito rápido. 

123
00:06:59,360 --> 00:07:02,880
Aí coletam dados reais de uso, 
analisam o impacto e decidem, 

124
00:07:02,880 --> 00:07:06,680
com base em evidência, se vale 
continuar, ajustar ou até 

125
00:07:06,680 --> 00:07:10,040
descartar a ideia sem ter 
perdido meses de trabalho. 

126
00:07:10,160 --> 00:07:14,000
É aquele ciclo de construir, 
medir, aprender. 

127
00:07:14,280 --> 00:07:18,000
Só que bem mais ágil. 
Então, olhando o quadro geral, o

128
00:07:18,000 --> 00:07:22,240
diploma de contínuo parece ser 
bom mais que só automação, é uma

129
00:07:22,240 --> 00:07:26,440
mudança mais profunda, né? 
Sem dúvida alguma o cid meio que

130
00:07:26,440 --> 00:07:30,600
força ou talvez exija uma 
mudança cultural grande. 

131
00:07:31,200 --> 00:07:34,520
Ele obriga ex equipes a pensar 
em entregas pequenas 

132
00:07:34,600 --> 00:07:38,360
incrementais, a priorizar a 
qualidade automatizada, a 

133
00:07:38,360 --> 00:07:41,040
colaborar mais de perto. 
Deve teste. 

134
00:07:41,040 --> 00:07:45,360
Ops, o coração do devots, né? 
E assumir uma responsabilidade 

135
00:07:45,360 --> 00:07:48,400
conjunta pela produção passa se 
a valorizar. 

136
00:07:48,400 --> 00:07:51,960
O feedback contínuo e a 
capacidade de se adaptar rápido.

137
00:07:52,520 --> 00:07:56,960
Não é só ferramenta, é mindset. 
É processo colaborativo. 

138
00:07:57,280 --> 00:08:00,000
O material até traz o exemplo do
Facebook para ilustrar isso. 

139
00:08:00,000 --> 00:08:02,760
É uma prática. 
Os números que ele cita são 

140
00:08:03,160 --> 00:08:06,240
impressionantes. 
Sim, o estudo citado na fonte é 

141
00:08:06,240 --> 00:08:08,960
de cair o queixo. 
Na época, falava que cada 

142
00:08:08,960 --> 00:08:12,520
desenvolvedor no Facebook. 
Colocava em produção em média, 

143
00:08:12,520 --> 00:08:18,200
3.5 atualizações por semana e 
cada uma tinha em média umas 92 

144
00:08:18,200 --> 00:08:21,840
linhas de código mudadas. 
São milhares de deploys rolando 

145
00:08:21,840 --> 00:08:26,280
toda semana de forma bem 
descentralizada. 3 atualizações 

146
00:08:26,280 --> 00:08:30,360
e meia por desenvolvedor por 
semana isso é quase um deploy 

147
00:08:30,360 --> 00:08:34,400
por dia útil para cada um. 
Como eles conseguem gerenciar 

148
00:08:34,400 --> 00:08:36,360
isso tudo e manter a 
estabilidade? 

149
00:08:36,360 --> 00:08:37,520
Meu Deus? 
É. 

150
00:08:37,640 --> 00:08:41,000
Analisando esse exemplo, fica 
claro que, além da automação e 

151
00:08:41,000 --> 00:08:44,320
dos testes, tem uma habilidade 
que os desenvolvedores precisam 

152
00:08:44,320 --> 00:08:47,440
ter, que é saber quebrar o 
trabalho em partes muito 

153
00:08:47,440 --> 00:08:50,280
pequenas. 
Mesmo uma funcionalidade grande 

154
00:08:50,280 --> 00:08:54,400
e complexa precisa ser fatiada 
em incrementos minúsculos coisas

155
00:08:54,400 --> 00:08:57,280
que possam ser feitas, testadas 
de forma completa e 

156
00:08:57,280 --> 00:09:00,760
automatizada, integradas e 
liberadas sozinhas em questão de

157
00:09:00,760 --> 00:09:04,160
horas ou poucos dias. 
Sem essa disciplina de fatiar 

158
00:09:04,160 --> 00:09:08,120
fino o fluxo rápido do CDI 
simplesmente não funciona. 

159
00:09:08,640 --> 00:09:11,760
É uma mudança na forma de pensar
o desenvolvimento, OK? 

160
00:09:12,240 --> 00:09:15,640
A imagem do deploy mente 
continho tá ficando mais clara, 

161
00:09:16,120 --> 00:09:21,200
automação total até a produção, 
ciclos super rápidos, feedback 

162
00:09:21,200 --> 00:09:25,480
constante parece ideal pra 
sistemas web, onde a atualização

163
00:09:25,480 --> 00:09:29,160
é meio invisível pro usuário. 
Mas o próprio livro faz uma 

164
00:09:29,160 --> 00:09:32,120
ressalva importante, né? 
Ele disse que isso não serve 

165
00:09:32,120 --> 00:09:35,840
para todo mundo. 
Correto, o CD puro, esse com o 

166
00:09:35,840 --> 00:09:38,280
deploy automático e frequente 
para o usuário final. 

167
00:09:38,520 --> 00:09:40,640
Eles barrem em alguns tipos de 
sistema. 

168
00:09:40,960 --> 00:09:44,800
A fonte cita exemplos bem 
claros, software desktop, tipo 

169
00:09:44,800 --> 00:09:48,560
IDs, navegadores, Aplicativos 
móveis que você baixa da 

170
00:09:48,560 --> 00:09:51,240
lojinha. 
E software embarcado que roda 

171
00:09:51,240 --> 00:09:54,840
direto no hardware tipo firmware
da impressora do carro. 

172
00:09:54,840 --> 00:09:58,360
E por que OCD não seria bom 
nesses casos, qual o problema? 

173
00:09:58,400 --> 00:10:00,920
O problema está mais na 
experiência do usuário e na 

174
00:10:00,920 --> 00:10:04,880
logística mesmo da atualização. 
Imagina receber notificação todo

175
00:10:04,880 --> 00:10:08,280
dia para atualizar seu navegador
ou o app da rede social no 

176
00:10:08,280 --> 00:10:10,560
celular ou o driver da 
impressora? 

177
00:10:10,840 --> 00:10:14,040
Seria muito chato, né? 
O processo de instalar nesses 

178
00:10:14,040 --> 00:10:17,040
sistemas não é invisível. 
Como carregar uma página web? 

179
00:10:17,440 --> 00:10:20,760
Geralmente precisa de uma ação 
do usuário, interrompe o que ele

180
00:10:20,760 --> 00:10:24,080
está fazendo, gasta internet, às
vezes tem que reiniciar. 

181
00:10:24,520 --> 00:10:27,680
Fazer isso na frequência 
altíssima do CDI seria 

182
00:10:27,680 --> 00:10:30,880
impraticável e irritar demais os
usuários. 

183
00:10:31,000 --> 00:10:33,880
Faz todo sentido. 
Ninguém quer ser interrompido 

184
00:10:33,880 --> 00:10:37,000
toda hora. 
Então qual a alternativa para 

185
00:10:37,000 --> 00:10:39,200
esses softwares que querem 
agilidade? 

186
00:10:39,200 --> 00:10:42,160
O feedback rápido? 
Mas não podem usar o deplemento 

187
00:10:42,160 --> 00:10:45,160
continuo puro. 
É aí que entra A Entrega, 

188
00:10:45,160 --> 00:10:49,200
continua ou continius delivery? 
Veja que, sutil a diferença no 

189
00:10:49,200 --> 00:10:52,920
nome, o livro descreve como uma 
versão mais fraca ou uma 

190
00:10:52,920 --> 00:10:56,200
adaptação do diploma de 
continuo, pensada justamente 

191
00:10:56,200 --> 00:10:59,040
para esses cenários. 
A ideia é manter a maior parte 

192
00:10:59,040 --> 00:11:02,520
dos ganhos de agilidade interna,
mas ter mais controle sobre 

193
00:11:02,520 --> 00:11:04,840
quando a versão nova chega para 
o usuário. 

194
00:11:05,440 --> 00:11:09,520
E como funciona essa adaptação? 
Qual a diferença chave entre 

195
00:11:09,520 --> 00:11:12,600
diploma de contínuo e entrega 
contínua? 

196
00:11:12,640 --> 00:11:16,280
A diferença fundamental está ali
no último passo, o deploy para a

197
00:11:16,280 --> 00:11:18,480
produção. 
Na entrega contínua. 

198
00:11:18,600 --> 00:11:21,760
A equipe de desenvolvimento 
trabalha com a mesma mentalidade

199
00:11:21,760 --> 00:11:25,240
do CD, ou seja, cada comit que 
passa em todos os testes poderia

200
00:11:25,240 --> 00:11:27,720
ir para a produção. 
O software está tecnicamente 

201
00:11:27,720 --> 00:11:30,600
pronto, está testado, empacotado
validado. 

202
00:11:30,800 --> 00:11:33,720
A automação vai até o ponto de 
gerar o pacote pronto para 

203
00:11:33,720 --> 00:11:35,680
liberar. 
Mas ele não é liberado 

204
00:11:35,680 --> 00:11:37,600
automaticamente, então? 
Exato. 

205
00:11:38,000 --> 00:11:41,400
Na entrega contínua, a decisão 
final de quando liberar essa 

206
00:11:41,400 --> 00:11:43,560
versão que tá pronta para os 
usuários finais? 

207
00:11:43,800 --> 00:11:48,080
Essa decisão é manual, é 
deliberada, tem um portão final 

208
00:11:48,080 --> 00:11:50,200
ali. 
Geralmente uma pessoa, um 

209
00:11:50,200 --> 00:11:53,480
comitê, tipo gerente de 
produtos, gerente de release ou 

210
00:11:53,480 --> 00:11:56,760
até uma decisão de negócio 
mesmo, aperta o botão de deploy.

211
00:11:57,200 --> 00:12:00,000
E essa decisão pode se basear em
várias coisas além da parte 

212
00:12:00,000 --> 00:12:02,640
técnica. 
Campanha de marketing, janela de

213
00:12:02,640 --> 00:12:05,920
mercado, feedback de beta 
testers, coordenação com outras 

214
00:12:05,920 --> 00:12:08,760
coisas. 
Ah, então a automação prepara 

215
00:12:08,760 --> 00:12:12,080
tudo, deixando a porta de saída,
mas alguém tem que ir lá e abrir

216
00:12:12,080 --> 00:12:14,320
a porta manualmente. 
É uma boa analogia? 

217
00:12:14,320 --> 00:12:17,000
Sim. 
A fonte até sugere uma distinção

218
00:12:17,000 --> 00:12:20,680
útil nos termos, deployment é o 
ato de liberar para o usuário 

219
00:12:20,680 --> 00:12:24,400
usar delivery. 
Entrega é preparar e validar 

220
00:12:24,400 --> 00:12:27,000
para estar pronto para o 
deployment no deployment 

221
00:12:27,000 --> 00:12:30,240
contínuo CD. 
Tanto delivery quanto deployment

222
00:12:30,240 --> 00:12:34,640
são contínuos e automáticos na 
entrega contínua, que às vezes 

223
00:12:34,640 --> 00:12:37,160
também chamam de CDO, que 
confunde um pouco. 

224
00:12:37,360 --> 00:12:39,680
Mas aqui a gente tá falando de 
contínuos delivery. 

225
00:12:40,040 --> 00:12:42,840
O delivery é contínuo e 
frequente, muitas vezes 

226
00:12:42,840 --> 00:12:46,600
automatizado, mas o deplamento 
final é controlado manual e 

227
00:12:46,600 --> 00:12:50,080
acontece numa cadência menor, 
definida pelo negócio ou pela 

228
00:12:50,080 --> 00:12:52,640
estratégia. 
Essa distinção ajuda muito a 

229
00:12:52,640 --> 00:12:56,400
clarear as coisas, né? 
Basicamente, A Entrega contínua 

230
00:12:56,400 --> 00:12:59,840
mantém a agilidade interna, 
qualidade garantida pelos 

231
00:12:59,840 --> 00:13:04,160
testes, mas desacopla o ritmo de
desenvolvimento do ritmo de 

232
00:13:04,160 --> 00:13:06,240
lançamento para o usuário. 
Perfeito? 

233
00:13:06,240 --> 00:13:09,840
É isso mesmo, você tem a maior 
parte dos benefícios internos, 

234
00:13:10,080 --> 00:13:13,880
código sempre testável, 
integração constante, menos 

235
00:13:13,880 --> 00:13:18,080
risco de merge, feedback rápido 
interno, mas mantém o controle 

236
00:13:18,080 --> 00:13:19,960
do time da exposição para o 
cliente final. 

237
00:13:20,400 --> 00:13:22,240
E isso é essencial para certos 
produtos. 

238
00:13:22,240 --> 00:13:25,600
E a fonte traz exemplos de como 
isso funciona no mundo real para

239
00:13:25,600 --> 00:13:28,840
sistemas que não são web. 
Traz sim, e eles mostram bem 

240
00:13:28,840 --> 00:13:32,000
essa cadência mais controlada. 
O Google Chrome, por exemplo. 

241
00:13:32,200 --> 00:13:35,560
Com certeza eles usam práticas 
contínuas internamente, mas as 

242
00:13:35,560 --> 00:13:38,800
versões estáveis para o público 
saem a cada 6 semanas, mais ou 

243
00:13:38,800 --> 00:13:41,680
menos. 
A IDE eclipse, que é um software

244
00:13:41,680 --> 00:13:45,160
desktop super complexo, antes 
tinha um release gigante por 

245
00:13:45,160 --> 00:13:47,200
ano. 
A fonte menciona que a partir de

246
00:13:47,200 --> 00:13:51,120
2019, eles mudaram para um ciclo
de 13 semanas para entregar 

247
00:13:51,120 --> 00:13:54,560
valor mais rápido e até o app 
Android do Facebook, que não dá 

248
00:13:54,560 --> 00:13:57,840
para atualizar tão na surdina 
quanto a web, encurtou o ciclo 

249
00:13:57,840 --> 00:14:02,240
de 8 semanas para só uma semana.
Analisando esses exemplos, fica 

250
00:14:02,240 --> 00:14:07,000
claro que, mesmo fora da web, a 
pressão por ciclos mais curtos é

251
00:14:07,000 --> 00:14:10,600
gigante. 
Exatamente, a tendência é geral.

252
00:14:11,040 --> 00:14:14,080
E o que é fascinante é que as 
motivações para essas mudanças 

253
00:14:14,080 --> 00:14:17,520
no Chrome, no eclipse, no 
Facebook, para Android são as 

254
00:14:17,520 --> 00:14:21,600
mesmas do depoamento contínuo na
web, entregar valor mais rápido,

255
00:14:21,680 --> 00:14:24,840
pegar feedback mais cedo para 
guiar o futuro, manter as 

256
00:14:24,840 --> 00:14:27,680
equipes engajadas com entregas 
frequentes e, claro, ser 

257
00:14:27,680 --> 00:14:30,040
competitivo no mercado que muda 
toda hora. 

258
00:14:30,520 --> 00:14:33,120
A diferença não tá no porquê, 
mas no como. 

259
00:14:33,480 --> 00:14:37,000
Eles adaptam a prática, né? 
Usam A Entrega contínua para se 

260
00:14:37,000 --> 00:14:39,440
encaixar nas restrições do 
produto e do público. 

261
00:14:39,600 --> 00:14:42,240
Achando um equilíbrio entre a 
agilidade interna e a 

262
00:14:42,240 --> 00:14:45,640
conveniência para usuário? 
Muito bom então pra gente 

263
00:14:45,640 --> 00:14:47,440
amarrar tudo que a gente 
conversou aqui. 

264
00:14:47,440 --> 00:14:52,200
Com base no material, temos o 
diploment contínuo, onde a 

265
00:14:52,200 --> 00:14:56,840
automação leva o código do deve 
até o usuário final, rápido e 

266
00:14:56,840 --> 00:15:01,440
frequente, ótimo pra web. 
E A Entrega contínua? 

267
00:15:01,560 --> 00:15:04,920
Que automação prepara o software
para ser lançado a qualquer 

268
00:15:04,920 --> 00:15:09,520
hora, mas a liberação final é 
manual, menos frequente, mais 

269
00:15:09,520 --> 00:15:12,560
adequada para desktop, mobile, 
embarcados. 

270
00:15:12,560 --> 00:15:15,720
É uma ótima síntese. 
As 2 abordagens têm o mesmo 

271
00:15:15,720 --> 00:15:19,080
objetivo central, mais 
velocidade e confiabilidade na 

272
00:15:19,080 --> 00:15:23,080
entrega de software usando 
automação, testes rigorosos, 

273
00:15:23,120 --> 00:15:26,200
ciclos curtos. 
A escolha entre 1 e outra 

274
00:15:26,360 --> 00:15:29,520
depende muito do contexto do 
produto e do quanto o usuário 

275
00:15:29,520 --> 00:15:31,800
final tolera atualizações 
frequentes, né? 

276
00:15:31,840 --> 00:15:35,880
E fica bem claro que adotar 
qualquer uma delas não é só 

277
00:15:35,880 --> 00:15:38,920
instalar ferramenta, mas sim 
abraçar uma filosofia de 

278
00:15:38,920 --> 00:15:42,720
trabalho diferente. 
Definitivamente, como a gente 

279
00:15:42,720 --> 00:15:47,320
falou, essas práticas puxam ou 
até exigem uma transformação 

280
00:15:47,320 --> 00:15:50,040
cultural. 
Elas quebram Barreiras entre 

281
00:15:50,040 --> 00:15:53,400
equipes, promovem 
responsabilidade compartilhada. 

282
00:15:53,800 --> 00:15:58,240
Colocam a qualidade automatizada
no centro e, no fim das contas, 

283
00:15:58,400 --> 00:16:01,640
capacitam as organizações a 
responderem muito mais rápido às

284
00:16:01,640 --> 00:16:04,480
mudanças. 
As oportunidades no mundo onde 

285
00:16:04,480 --> 00:16:08,600
tudo muda o tempo todo, essa 
agilidade e adaptação que OCDEA 

286
00:16:08,600 --> 00:16:11,880
entrega continua trazem, são 
cada vez mais vitais. 

287
00:16:12,000 --> 00:16:15,800
Excelente, foi uma análise 
muito, muito esclarecedora 

288
00:16:15,800 --> 00:16:18,280
desses conceitos que são chave 
na engenharia de software 

289
00:16:18,280 --> 00:16:21,080
Moderna. 
Obrigada por acompanhar a gente 

290
00:16:21,080 --> 00:16:24,120
nessa exploração focada no 
deploimento contínuo e na 

291
00:16:24,120 --> 00:16:27,160
entrega contínua usando os 
insights de engenharia de 

292
00:16:27,160 --> 00:16:30,040
software Moderna até o próximo 
episódio.