Você está na página 1de 21

DevOps para entrega de produtos enxutos

Taina Caetano, Paulo Caroli, eRafael Magrin


Esse livro est venda em http://leanpub.com/devopsmvp
Essa verso foi publicada em 2015-12-22

This is a Leanpub book. Leanpub empowers authors and publishers with the Lean Publishing
process. Lean Publishing is the act of publishing an in-progress ebook using lightweight tools and
many iterations to get reader feedback, pivot until you have the right book and build traction once
you do.
2015 Taina Caetano, Paulo Caroli, eRafael Magrin

Contedo
Introduo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

Pensamentos Iniciais . . . . . . . . . .
Resultado da Concepo . . . . . . .
Atividades Iniciais . . . . . . . . . .
Desenvolvimento Iterativo . . . . .
Composio da Equipe . . . . . . .
Prticas de Kanban/Scrum . . . . . .
Prototipao Rpida . . . . . . . . .
MVP, features e histrias do usurio

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.

2
2
3
7
8
8
8
8

Princpios Tcnicos . . . . . . . . . . . . .
Preparar Ambiente de Desenvolvimento
Integrao Contnua . . . . . . . . . . .
Entrega Contnua . . . . . . . . . . . .
Infraestrutura como Cdigo . . . . . . .
Arquitetura Mnima Vivel (MVA) . . .
Micro-servios de Domnio . . . . . . .
Automao . . . . . . . . . . . . . . . .
Trunk nico . . . . . . . . . . . . . . .
Compartimentalizao . . . . . . . . . .
Feature Toggles . . . . . . . . . . . . .

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

12
12
12
12
12
13
14
14
14
14
15

MVP em Produo . . . . . . .
Deploy . . . . . . . . . . .
Decouple Deploy e Release
Acompanhamento . . . . .
Monitorao . . . . . . . .
Hypex . . . . . . . . . . .

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

16
16
16
16
16
16

Prxima Fase: MVP 2 em Construo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .


Kanban . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

17
17

Concluso . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

18

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.
.
.

.
.
.
.
.
.

.
.
.
.
.
.

Introduo
DevOps para produtos enxutos formado por uma srie de prticas e tcnicas que ns utilizamos
na fase de execuo de projetos. Aps a realizao da fase de concepo, a equipe possuir em mos
uma srie de requisitos descrevendo o que deve ser o produto.
Em Direto ao Ponto, onde proposta a tcnica da Inception Enxuta, o resultado o Canvas MVP,
o qual o ponto central do modelo de governana. Ele auxilia na organizao e visualizao das
funcionalidades e da sequncia de liberao de entrega incremental do produto mnimo vivel, o
MVP. Mais do que isso, o canvas organiza e planeja entregas do produto alm do primeiro MVP.
Aqui, discutiremos os passos subsequentes concepo, de tal forma que o leitor saia equipado para
planejar, direcionar e executar o desenvolvimento do produto.
https://leanpub.com/diretoaoponto
http://www.caroli.org/o-canvas-mvp/

Pensamentos Iniciais
Resultado da Concepo
Na concepo do projeto, a equipe trabalhou junta para entender os objetivos do produto, os
principais usurios, e o escopo funcional de alto nvel. Alm disto, a equipe sai da concepo
com o sequenciador de features em mos, o qual organiza e planeja entregas do produto alm do
primeiro MVP. Tipicamente, times utilizando o sequenciador de features iro deslumbrar e evoluo
do produto via uma sequncia de MVPs. E isso auxilia, e muito, na criao de produtos, baseados
nesta forma enxuta de trabalho.

MVP e suas features

Embora uma ferramenta eficiente para descrever e alinhar visualmente o mapa de evoluo do
produto, o sequenciador de features por si s no resultar em entregas de sucesso.
Independente de excelentes planos, se a equipe no estiver muito coesa e trabalhando efetivamente
como um time, a execuo do plano fica comprometida.
Para tanto, sugerimos fortemente que o time envolvido na concepo do produto seja o mesmo time
envolvido na implementao, caracterizando assim o time do produto.
2

Pensamentos Iniciais

Uma equipe de produto formada por um grupo cross-funcional multidisciplinar de pessoas que
so coletivamente responsveis para a entrega e manuteno de um produto. Normalmente, a
equipe do produto desempenha um papel crucial dentro da organizao: a equipe responsvel
pela implementao da estratgia, evoluo, definio das funcionalidades, criao e manuteno
do produto.

Atividades Iniciais
Antes da equipe colocar a mo na massa e comear a implementao do produto, recomendamos
uma checagem para os seguintes fatores. Alguns so logsticos, outros envolvem trabalho individual
e em equipe para que estejam prontos:

Uma mesa onde todos podero se sentar juntos;


Computadores e monitores;
Licenas para os softwares necessrios;
Software de desenvolvimento instalado.
Um quadro visual demonstrando as tarefas do time;
Acesso ao sistema de controle de verso de cdigo todos os membros do time;
Deciso sobre as tecnologias utilizadas para o MVP 1.
Pipeline bsico de entrega contnua funcionando.

Disponibilizar um quadro visual descrevendo as tarefas do time importante para dar visibilidade,
tanto para stakeholders externos quanto para os prprios membros do time se manterem alinhados
com relao ao que deve ser feito. As prprias tarefas deste momento inicial podem (e devem!) ser
descritas no quadro, com responsveis associados elas conforme elas so executadas.
Outro fator que deve ser garantido antes do incio do desenvolvimento do produto a definio das
tecnologias que sero utilizadas. No necessrio, neste momento, definir toda uma arquitetura
e tentar antecipar todos os problemas que podem vir a acontecer durante o desenvolvimento.
Entretanto, uma direo inicial se faz necessria para que o time comece.

A Sprint Zero
Para times usando a metodologia Scrum, comum o termo sprint Zero. Apesar de no comearmos
a contar do zero (contamos 1, 2, 3), times Scrum comumente se referem a primeira sprint como
Sprint Zero, sendo essa a Sprint dedicada a atividades de set-up, as as quais no contemplam tarefas
diretamente relacionadas a criao de features do produto.
Independente de utilizar Scrum ou outra metodologia para a gerenciamento e acompanhamento
da criaao do produto, sugerimos utilizar este conceito de dedicar um tempo inicial (uma ou duas
semanas) para realizar as tarefas iniciais preparatrias para o ambiente de trabalho.

Pensamentos Iniciais

Comece logo
A sesso tarefas de set-up compartilha uma sequencia de atividades para levantar as tarefas para
o mnimo necesrio de set-up para comear o trabalho. O nmero de tarefas levantadas vai variar
de time para time. O perigo de levantar muitas tarefas, que levaria muito tempo at comear o
trabalho nas features do MVP, gerando, assim, ansiedade para todos que esperam o primeiro MVP.
Portanto, consideramos a combinao da ideia de Sprint Zero com a tarefas de set-up, e com isso,
deixar claro a todos que o time no vai trabalhar em features do MVP neste curto perodo inicial
(uma ou duas semanas). E, da mesma forma que o time pede por esse perodo inicial para set-up, ele
se compromete a trabalhar efetivamente nas features do MVP aps esse Sprint Zero.
Ou seja, depois do zero, o time vai comear a contar; sejam semanas ou sprints (para quem utilizar
Scrum). E assim que comear a contar, estar trabalhando efetivamente nas to esperadas features
do MVP.

Tarefas de set-up
Para dar incio a criao do produto precisamos de definies bsicas sobre o ambiente de trabalho
e sobre as normas de interao entre as pessoas. Para tanto, precisamos buscar o alinhamento e
definio das mesmas.
Na mesma linha de pensamento que utilizamos para a definio de MVP, precisamos definir o
mnimo necessrio em relao ao ferramental e ao ambiente de trabalho para que possamos comear
a construir o produto. Reunindo todos membros do time em uma sala, realizamos um workshop de
durao mdia de duas horas, onde so realizadas a seguinte sequncia com trs atividades: Moscou,
Votao Mais / Menos e Quem/O que/Quando, atividades detalhadas em Fun Retrospectives.
Atividade: Moscou
A atividade Moscou auxilia na conversa de alinhamento sobre o que essencial para comearmos,
em relao ao que pode vir depois.
Passo a passo da atividade
1. Divida o canvas em trs sesses: precisa ter (Must Have), deveria ter (Should Have) e poderia
ter (Could Have). O nome da atividade Moscou pois lembra, em Ingls, MustShouldCould,
ou, cortando algumas letras, MuShCou.
2. Selecione trs cores de post-it explique a categoria de cada cor. Por exemplo: amarelo para
comunicao, verde para pipeline de entrega contnua, e rosa para ambiente de desenvolvimento.
3. Distribua post-its coloridos e canetas a todos participantes.
http://www.funretrospectives.com

Pensamentos Iniciais

4. Pea que cada participante escreva no post it (usando a cor de acordo com a categorizao
adequada) o que ele acredita ser importante para o time.
5. Pea aos participantes que coloque os posts no canvas comum de acordo com o seu entendimento em relao ao que precisa, deveria, ou poderia ser feito.
As duas atividades a seguir complementam a atividade Moscou para buscar o alinhamento do time
para o iniciar a criao do produto. Sugerimos fortemente descartar os posts da sesso de poderia ter.
Relembramos que o objetivo principal buscar o mnimo de alinhamento para dar incio a criao
do produto. Portanto, o time deve focar sua ateno para a sesso deveria ter, ou, em outras palavras,
o que essencial para comearmos a trabalhar efetivamente.
Atividade Votao Mais / Menos
Esta atividade permite aos participantes serem mais claros sobre concordncias e discordncias sobre
os itens levantados. tipicamente usada para focar a conversa nos itens que mais interessam ao
grupo.
Passo a passo da atividade
1. Instrua os participantes sobre as regras de votao:
Cada participante tem direito a votar 5 + e 3 (cada voto ser representado por uma
marca de + ou no post-it.
Os participantes podem colocar mais de um voto em um carto.
(+) representa sua concordncia com uma anotao e voc quer falar sobre ela.
() representa sua discordncia com a anotao e voc quer falar sobre ela.
Por favor, vote nos itens que voc quer discutir. Os itens com mais votos sero selecionados primeiro.

Pensamentos Iniciais

Votao Mais Menos

Atividade: Quem/O que/Quando


A atividade Quem/O que/Quando ajuda a definir comprometimento e aes de acompanhamento
para os itens levantados. A partir desta atividade, os prximos passos ou itens de ao estaro
claramente definidos e visveis para o time.
Passo a passo da atividade
1. Crie uma estrutura de tabela que tenha como ttulos de coluna QUEM / O QUE / QUANDO.
2. Pea para os participantes selecionarem (da atividade anterior) ou escreverem um passo
concreto com o qual possam se comprometer. Estes deve ser tanto (1) passos que eles deve
seguir; ou (2) passos nos quais acreditam bastante.
3. Cada passo concreto selecionado formar uma linha na tabela Quem/O que/Quando. Pea
para os participantes para:
Colocar o post-it com o passo na coluna O QUE;
Escrever seus nomes na coluna QUEM;
Definir QUANDO o item estar feito.

Pensamentos Iniciais

Quem/O que/Quando nas colunas da tabela

Ao focar a discusso no formato Quem/O qu/Quando, voc pode conectar pessoas a aes claras
que elas definiram e com as quais se comprometeram. Ela permite aos participantes serem claros em
relao a seu comprometimento e responsabilidades, tornando visvel para todo o grupo QUEM vai
fazer O QUE e QUANDO.
Esta atividade inspirada na matriz Quem/O que/Quando no livro Gamer Storming.

Desenvolvimento Iterativo
Acabou a semana da inception enxuta, e agora o time tem o entendimento sobre o MVP e est
alinhado sobre qual so as primeiras features a serem criadas.
As features e o MVP esto em alto nvel, mostrando claramente o que tem ser feito, entretanto sem
os detalhes sobre como isso vai ser feito. O time agora precisa aprofundar nos detalhes de como
sero criadas essas features.
Para tanto o time deve utilizar de algumas dentre vrias tcnicas que auxiliam nesse entendimento
mais detalhado. Histrias do usurio, prototipao rpida, desenvolvimento baseado em comportamento (BDD) e testes de aceitao so exemplos de algumas das tcnicas para ajudar com o
detalhamento das features.
Usando algumas dessas tcnicas o time estar aprofundando sobre a forma com a qual as features
sero criadas. Entretanto, aprofundar no complicar! Fique muito atento para no estar adiciohttp://gamestorming.com/

Pensamentos Iniciais

nando alguma tcnica de detalhamento que estar complicando e distanciando o entendimento em


relao as features e o MVP.
Ao primeiro sinal de que algum est trabalhando em algo que no est vinculado ao MVP, pare e
reavalie. Provavelmente estamos complicando algo desnecessariamente.
Mantenha sempre o canvas MVP prximo ao time. Sempre que algum explicar alguma tarefa ou
algo que esteja fazendo, aponte para o canvas MVP. Pergunte como tal tarefa est relacionada com
o MVP.
Uma boa resposta ajuda todos a entenderem como tal tarefa est aprofundando sobre o que est
sendo feito para o MVP. Uma resposta confusa pode ser um bom indicador de um complicador.
Cuidado, aprofundar no complicar!

Composio da Equipe
.

Prticas de Kanban/Scrum
.

Prototipao Rpida
.

MVP, features e histrias do usurio


O canvas MVP retrata a relao entre o MVP e as features. As features e o MVP esto em alto nvel,
mostrando claramente o que tem ser feito, entretanto sem os detalhes sobre como isso vai ser feito.
O time agora precisa aprofundar nos detalhes de como sero criadas essas features.
As features so tipicamente descritas em um nvel mais elevado do que as histrias do usurio.
Portanto, antes de comear a trabalhar em uma feature, a mesma deve ser analisada e detalhada em
suas respectivas histrias de usurio.
Feature a descrio de uma ao ou interao de um usurio com o produto. Por exemplo: imprimir
nota fiscal, consultar extrato detalhado, e convidar amigos do facebook. A descrio de uma feature
deve ser o mais simples possvel. O usurio est tentando fazer uma coisa. O produto dever ter uma
feature para isso. Que feature essa?
Exemplo de Funcionalidade: Consultar partidas sem geolocation
Tipicamente, as equipes de desenvolvimento trabalham com histrias de usurios. Portanto, voc
deve detalhar um pouco mais, e realizar o mapeamento de features para histrias.

Pensamentos Iniciais

Histria de usurio
Histria de usurio um formato textual para a descrio concisa de um requisito que busca
responder a trs indagaes bsicas: quem? o que? e por que? Tipicamente uma funcionalidade
de alto nvel (feature) desmembrada em algumas histrias do usurio.
Como um PERFIL DO USURIO / PERSONA
Eu quero FUNCIONALIDADE ESPECFICA DO PRODUTO
Para que VALOR DO NEGCIO
O acrononimo INVEST [ref] ajuda a escrever boas histrias. Esta histria Independente?
Negocivel, tem Valor para o negcio (Valuable, em ingles)?, Estimvel?, Small (em ingles, ou de
tamanho relativamente pequeno)? Testvel?
Outro acrononimo que auxilia o 3Cs [ref]. Em ingles, os trs Cs so: card, conversation, and
confirmation. Histrias de usurios tm trs aspectos crticos . O carto da histria deve seguir
um modelo simples ( como um Eu quero .. para que ). A partir deste modelo simples (card),
teremos conversas colaborativas (conversations) para melhor entender e detalhar a histria, at que,
quando pronta, recebemos a confirmao (confirmation), geralmente pelo dono do produto (do ingles
Product Owner, ou PO).

Critrio de aceite
Critrio de aceite um formato textual que descreve como testar uma funcionalidade. Tipicamente
uma histria do usurio ter alguns critrios de aceite.
Dado que CENRIO INICIAL
Quando AO REALIZADA
Ento ESTADO ESPERADO
Os critrios de aceite (ACs) definem os limites para uma histria de usurio. A partir deles todaos
envolvidos iro saber se a histria est completa, e devemos buscar a confirmao do PO sobre a
mesma.

Tarefas
muito comum quebrar uma histria em pedaos ainda menores sobre o trabalho que deve ser
feito. Essas so as tarefas. Ao listar as tarefas necessrias para construir uma histria, a equipe
de desenvolvimento entra em detalhes tcnicos de como os pedaos menores da histrias sero
implementados. Diferente das histrias, as tarefas no seguem um formato textual definido. Essas
so mais diretas, com uma linguagem bem tcnida, da equipe de desenvolvimento para a equipe de
desenvolvimento.

Pensamentos Iniciais

10

Uma tarefa identifica algo que precisa ser feito, geralmente, algo necessrio para alguma histria.
Como tal, a tarefa no ser necessariamente independente, ou demostrar o valor de negcio.
A maioria das tarefas tendem a ser para programadores, descritas com termos utilizdos pelos
mesmos. Alguns exemplos de tarefas: alterar campos da tabela ABC, criar dados de teste para XYZ,
automatizar os scripts de BLAH, e assim por diante.

Um exemplo
Segue abaixo um exemplo de feature que foi dividida em trs histrias, com alguns critrios de aceite
e tarefas.
Funcionalidade: Consultar partidas sem geolocation
Histria 1
Como um peladeiro no-cadastrado
Eu quero consultar partidas prximas a um endereo informado
Para que eu encontre um jogo prximo ao meu local atual
Histria 2
Como um peladeiro cadastrado
Eu quero consultar partidas prximo ao meu trabalho
Para que eu encontre um jogo prximo ao meu trabalho
Histria 3
Como um peladeiro cadastrado
Eu quero consultar partidas prximo a minha residncia
Para que eu encontre um jogo prximo a minha residncia
Critrios de aceite da histria 2 (exemplo 1)
Dado que existe uma partida a menos de 10 kilometros do meu trabalho
Quando procuro por uma partida prxima ao meu trabalho
Ento encontro tal partida
Critrios de aceite da histria 2 (exemplo 2)
Dado que no existe nenhuma partida a menos de 10 kilometro do meu trabalho
Quando procuro por uma partida prxima ao meu trabalho
Ento no encontro nenhuma partida

Pensamentos Iniciais

11

Tarefas da Histria 2

criar UI para mostrar partidas prximas ao local de trabalho (com dados hardcoded)
criar lgica no backend para busca por proximidade (hardcoded 10 km)
alterar parametro hardcoded para campo de configurao
criar dados de teste para buscar partida nas proximidades do trabalho
alterar DB para incluir endereo de trabalho

O canvas MVP retrata a relao entre MVP e funcionalidades. Mas, tipicamente, as equipes Scrum
trabalham com histrias de usurios. Portanto, voc deve detalhar um pouco mais, e realizar o
mapeamento de funcionalidades para histrias.
As funcionalidades so tipicamente descritas em um nvel mais elevado do que as histrias do usurio. Portanto, antes da reunio de planejamento da sprint, o prximo conjunto de funcionalidades
deve ter sido analisado e detalhado em suas respectivas histrias de usurio.
Segue abaixo um exemplo de funcionalidade que foi dividida em trs histrias.
Funcionalidade: Consultar partidas sem geolocation
Histrias 1: Como um peladeiro no-cadastrado Eu quero consultar partidas prximas a um
endereo informado Para que eu encontre um jogo prximo ao meu local atual
Histria 2: Como um peladeiro cadastrado Eu quero consultar partidas prximo ao meu trabalho
Para que eu encontre um jogo prximo ao meu trabalho
Histria 3: Como um peladeiro cadastrado Eu quero consultar partidas prximo a minha residncia
Para que eu encontre um jogo prximo a minha residncia

Princpios Tcnicos
Preparar Ambiente de Desenvolvimento
.

Integrao Contnua
.

Entrega Contnua
A entrega contnua est cada vez mais se consagrando como a prtica que guiar times maduros para
o futuro. Atualmente, a mesma equipe que adotou testes automatizados e configurou um servidor
de integrao contnua para aumentar a qualidade do produto final busca automatizar desde testes
at a implantao do sistema, garantindo o mximo de qualidade e previsibilidade nas tarefas da
equipe, principalmente nas mais crticas.
Desde que as prticas de XP ref xp foram compartilhadas, desenvolvedores de software buscam
melhorar a qualidade do seu trabalho atravs de tcnicas como testes automatizados e desenvolvimento orientado a testes (TDD). Em um segundo momento, essas equipes caminham para a
integrao contnua, sendo que cada pedao de cdigo passa por todos os testes para garantir que
problemas sejam detectados o mais rpido possvel, fornecendo uma viso centralizada de qualidade
e possibilitando que os problemas sejam expostos para toda a equipe.
Uma caracterstica chave da entrega contnua que ela precisa do envolvimento de toda a
equipe. Adotar testes melhora a qualidade do produto final, o que uma tarefa primordial dos
desenvolvedores. Nesse sentido, a entrega contnua procura tirar as dificuldades tcnicas do caminho
e fazer com que a equipe de negcios (stakeholders, clientes etc.) possa decidir quando entregar. E
quem melhor do que ela para tomar tal deciso?

Infraestrutura como Cdigo


O conceito chave aqui que possvel modelar a infraestrutura como se fosse cdigo, de modo que
sua abstrao, design, implementao e deploy ocorra da mesma maneira que utilizamos quando
http://martinfowler.com/books/continuousDelivery.html

12

Princpios Tcnicos

13

desenvolvendo aplicaes. Assim, trabalha-se com esse cdigo utilizando as mesmas ferramentas e
prticas que so utilizadas em projetos modernos de software.
O cdigo que modela, builda e gerencia a infraestrutura submetido ao sistema de controle de
verso juntamente com o cdigo da aplicao, tornado o setup controlado e repetvel. A mudana de
pensamento que a infraestrutura deve ser redeployavel a partir do cdigo; um cdigo que deve ser
desenvolvido utilizando as metodologias j estabelecidas em anos em que a indstria amadureceu.

Arquitetura Mnima Vivel (MVA)


O MVP permite que a equipe de possa entregar um produto nas mos de usurios rapidamente, um
baixo custo. Quanto mais cedo o produto for utilizado, mais se pode aprender com os usurios para
melhor-lo. A melhor maneira de aprender e evoluir ouvir de usurios que utilizam o software,
no de pessoas olhando para uma folha de papel em branco tentando visualizar como um sistema
deve funcionar.
Um dos desafios que a abordagem MVP apresenta de que ela pode levar falta de uma arquitetura.
Quando construindo um produto do zero, a pressa para entreg-lo pode vir ao custo de uma
arquitetura sustentvel. Deve haver balano entre velocidade de entrega e qualidade. necessria
uma arquitetura mnima vivel (MVA).
Ento, como definimos qual o MVA? Recomendamos realizar perguntas como estas:
Quantos usurios utilizaro o sistema no lanamento inicial? Nos primeiros 6 meses? Dentro
de um ano?
Os usurios iniciais sero internos, externos, ou ambos?
Quantas transaes por segundo esperamos no lanamento? Nos primeiros 6 meses? Dentro
de um ano?
Como os usurios comearo a utilizar o sistema?
Qual o nvel de segurana e auditabilidade exigido no lanamento? Dentro de 6 meses? Dentro
de um ano?
H diversas outras perguntas para guiar a discusso. Estas perguntas ajudam a equipe a definir os
requisitos bsicos para lanar no mercado. Embora no entre no mrito de definir uma arquitetura
completa e perfeita para o produto final, isto diferente de ignorar a definio de uma boa
arquitetura. O foco no quanto de investimento necessrio para lanar e, em seguida, definir
um plano para evoluir a arquitetura conforme o nmero de usurios aumenta e requisitos so
adicionados.
Tentar construir o sistema perfeito raramente a abordagem correta. Vamos dizer que a resposta do
dono do produto para estas perguntas sejam as seguintes:
http://www.kavistechnology.com/blog/minimal-viable-architecture/

Princpios Tcnicos

14

Haver apenas cinco usurios internos nos primeiros trs meses. Seis meses a partir de agora
os nossos dois primeiros clientes externos estaro usando os sistemas em modo piloto. Um ano
a partir de agora lanaremos o sistema para todos os clientes.
No lanamento haver uma quantidade trivial de transaes. Daqui a seis meses o trfego ser
moderado. No prximo ano, o trfego ser extremo.
Inicialmente, adicionaremos usurios ao sistema atravs de uma interface. No futuro, os
clientes tero gesto de ID self-service. Espero que isto acontea em um ano a partir de agora.
Ns s precisamos de segurana mnima para a primeira verso. Para o piloto, precisamos de
segurana e audit completos.
Com base nessas respostas, muita discusso e definio pode ser adiada para aps o lanamento da
primeira verso. Por que gastar tempo na estratgia de cache agora, quando no vemos a necessidade
no horizonte de um ano? Ns podemos colocar fora diversas tarefas de gerenciamento de ID para
mais tarde tambm. Deve-se evitar discusses imediatas sobre requisitos que s viro no futuro, de
forma que seja implementado apenas o estritamente necessrio da melhor forma possvel. por isso
que o MVA to importante.
Esta abordagem depende da disciplina e confiana entre o dono do produto e da equipe de
desenvolvimento, para garantir que ambas obtenham os resultados desejados: o produto entregue
rapidamente com um sistema bem arquitetado e com pouca dvida tcnica.

Atividade: Definindo Arquitetura


.

Micro-servios de Domnio
.

Automao
.

Trunk nico
.

Compartimentalizao
.

Princpios Tcnicos

15

Feature Toggles
Com a utilizao de Trunk Based Development (TBD) surge a dvida de como fazer para que
funcionalidades em desenvolvimento no impeam que o Trunk esteja sempre pronto para ir para
produo. A soluo mais utilizadas com este objetivo a utilizao de feature toggles.
As feature toggles funcionam como um interruptor que permite manter uma funcionalidade
desligada em produo at que todo o desenvolvimento da funcionalidade esteja concludo.
A maneira mais simples de se implementar uma feature toggle colocar uma propriedade no arquivo
de configurao da aplicao descrevendo o estado da toggle, ativado ou desativado, e colocar um
condicional no cdigo para verificar se a funcionalidade est ativa antes de executar esta.
imagem com exemplo do arquivo de configurao e do cdigo
Existem outras maneiras mais complexas de implementar toggles para permitir mais flexibilidade
na maneira de ativar/desativar estas. Por exemplo, possvel criar mecanismos para que somente
parte dos usurios tenha a funcionalidade ativada, permitindo fazer A/B ou canary release.
Um grande benefcio da utilizao de toggles que permite separar o processo de deploy de uma
funcionalidade e o processo de release desta, ou seja, o cdigo da funcionalidade pode estar pronto
em produo, mas invisvel aos usurios. Isto muito til quando voc tem que desenvolver uma
funcionalidade que tem uma data especfica para ser ativada, por exemplo, como funcionalidades
relacionadas a novas legislaes, ou quando voc quer submeter uma aplicao mobile ao processo
de aprovao da apple store ou google play, mas quando o back-end ainda est em desenvolvimento.
Como qualquer tcnica, toggles tambm adicionam complexidade adicional no seu processo de
desenvolvimento. Por isso muito importante remover o cdigo referente a uma toggle assim que
este no for mais necessrio e tentar manter o menor nmero possvel de toggles no cdigo.
Tipos de feature toggles:
Toggles de desenvolvimento: tem vida curta e so utilizadas para esconder o cdigo em desenvolvimento;
Toggles de operaes: so utilizadas para permitir que algumas funcionalidades no crticas ou
ainda experimentais sejam desligadas em produo em momentos crticos. Por exemplo, desligar
a funcionalidade de recomendaes em dias de grandes promoes, para diminuir o tempo de
carregamento da pgina em um site de e-commerce;
Toggles de negcios: so utilizadas pelo negcio para fazer experimentaes como, por exemplo, A/B
testing.

MVP em Produo
.

Deploy
.

Decouple Deploy e Release


.

Acompanhamento
.

Monitorao
.

Hypex
.

16

Prxima Fase: MVP 2 em Construo


.

Kanban
.

17

Concluso
.

18