Eriksen Costa

Criando uma cultura de Engenharia

Thu, 05 May 2022 06:45:00 -0300

Cultura é sempre um assunto muito debatido. Peter Drucker dizia que “a cultura come estratégia no café da manhã”. Quando alinhada com estratégia e liderança, uma cultura forte leva a resultados organizacionais positivos.

Ashley Goodall e Marcus Buckingham dizem, em seu livro Nine Lies About Work, que cultura importa porque contribui com a identidade, com os processos e com a visão da organização. Além disso, a cultura é a resposta que as pessoas dão quando são perguntadas sobre “como é trabalhar aí?”. Dizem, ainda, que a cultura define o quão duro as pessoas trabalharão e por quanto tempo ficarão em sua empresa.

Cultura importa. Porém, cultura também pode ser um assunto complicado e confuso. Por isso, muitas vezes a cultura é relegada ao RH e tratada de forma secundária pelo negócio. Mas há como fazer um processo gerenciado de definição de cultura e dá menos trabalho do que você imagina.

Antes de falar sobre como definir uma cultura organizacional, é preciso entender o que é cultura.

O que é cultura?

Cultura possui algumas definições, entre elas:

É o sistema de conhecimento de um grupo relativamente grande de pessoas
É o comportamento cultivado, é a totalidade do que uma pessoa aprendeu, da experiência acumulada ao qual é socialmente transmitida – ou, mais brevemente – comportamento através de aprendizado social
É a forma de vida de um grupo de pessoas – os comportamentos, as crenças, os valores e símbolos que elas aceitam (geralmente sem pensar sobre eles) e que são passados adiante por comunicação e imitação de uma geração para outra
É comunicação simbólica. Alguns desses símbolos incluem as habilidades, atitudes, conhecimentos, valores e motivações de um grupo. Os significados dos símbolos são aprendidos e deliberadamente perpetuados em uma sociedade através de suas instituições

Como deu para perceber, cultura é sempre um fenômeno coletivo. E a cultura define o jogo social: as normas culturais definem o que é aceito ou não dentro de um grupo, além de orientá-lo em direção a um propósito compartilhado.

Essa é a primeira dica para gerenciar o processo de definição de cultura. Valores, direção, crenças, comportamentos são palavras-chave que traduzem bem para conceitos de gestão estratégica como visão, missão e valores. Também vale a pena falar em princípios.

Visão, missão, valores e princípios

Qualquer pessoa líder já se deparou com os desafios de definição de objetivos ou foram questionadas por clareza de propósito. Na gestão estratégica, as ferramentas para isso são a visão, a missão e os valores. Eu particularmente gosto das definições disponíveis no livro Product Roadmaps Relaunched:

A visão é o resultado que você busca no longo-prazo. A visão nos diz para onde queremos ir
A missão é a intenção que você tem agora. É o seu propósito, é o que te guia em direção a sua visão
Valores são crenças e ideais que governam o comportamento. Se a visão nos diz para onde queremos ir, os valores nos ajudam a corrigir o rumo para a visão

Na N26 Brasil, decidimos também definir um conjunto de princípios para a cultura de Engenharia. Princípios são ideias ou regras básicas que explicam ou controlam como algo deve funcionar.

Visão, missão, valores e princípios. Parece que já temos alguns bons elementos para começar a trabalhar, certo?

Defina de forma colaborativa

Se a cultura é um conjunto de crenças e mitos compartilhados, nada melhor que defini-la colaborativamente. A minha sugestão é estruturar um workshop com atividades bem definidas. Técnicas de gestão estratégica de produto e de facilitação de cerimônias ágeis são bem úteis para isso. Identifique, pelo menos, a visão e os valores.

Na N26 Brasil, fizemos esse processo em julho de 2021, quando o time de Engenharia inteiro era composto por apenas cinco pessoas. Precisávamos definir uma estratégia para a área e, para isso, precisávamos entender que tipo de cultura gostaríamos de cultivar. Com os elementos culturais definidos, ficou mais fácil criar uma visão de roadmap. Hoje, toda nossa estratégia técnica está alinhada com nossa cultura.

Caso esteja curioso sobre como executar um workshop desses, consulte o playbook que criei: ele contém um passo a passo semelhante ao que fizemos na N26 Brasil.

Documente, compartilhe, integre e reconheça

O mercado estremeceu quando a Netflix divulgou o seu famoso slide de cultura. Você deve fazer o mesmo. Definir a cultura é o primeiro passo. Após sua definição, crie um documento e deixe-o facilmente acessível para todas as pessoas da sua empresa. Para deixar o documento mais útil, forneça pequenas descrições sobre cada um dos elementos identificados da sua cultura: eles serão úteis para validar comportamentos e fornecer exemplos para as pessoas.

Porém, documento compartilhado não é a mesma coisa que conhecimento compartilhado. Apresente a cultura para todas as pessoas contratadas. Use cada oportunidade de interação para repetir os elementos da cultura: das All Hands às Daily Meetings, explore os elementos da sua cultura para que ela seja, de fato, compartilhada e assimilada por todas as pessoas.

Na N26 Brasil, a cultura é apresentada para todas as pessoas nas sessões de onboarding. Além disso, a leitura do documento de cultura é estimulada no plano 30-60-90 que estabelecemos para todas as pessoas das disciplinas de Engenharia.

Por fim, integre os elementos da sua cultura no seu processo de recrutamento e use os bons exemplos do dia a dia para reconhecer a contribuição das pessoas com o fortalecimento dela. Não existe uma receita pronta, a construção da sua cultura dependerá muito do cuidado e atenção dado à ela.

Valores da Engenharia da N26 Brasil

Destaco, a seguir, alguns dos valores de nossa cultura:

Profissionalismo: somos confiáveis e definimos altos padrões de conduta e execução. Nos importamos com o trabalho, com as pessoas e com nossos clientes e usuários
Pragmatismo: somos pragmáticos. Sabemos dosar quando chegamos em uma solução boa o suficiente, evitando over-engineering e cargo cult programming
Humildade: ninguém sabe de tudo. Toda dúvida é uma oportunidade para aprender. Senioridade não é um passe livre para comportamento desrespeitoso
Colaboração: os objetivos da N26 Brasil, das unidades e dos times são mais importantes que os objetivos individuais. O trabalho em time triunfa sobre o individual
Diversidade: vivemos em uma sociedade miscigenada e de cultura diversificada. Atender à pluralidade da sociedade só será possível com um time igualmente plural

A cultura de Engenharia da N26 Brasil é uma cultura em formação. No momento em que escrevo esse texto, 64% do time tem menos de 6 meses de empresa. O mesmo cresceu 400% entre setembro de 2021 e janeiro de 2022. Mesmo assim, é possível ver os valores definidos por aquele pequeno grupo de pessoas em ação nas entrevistas, no onboarding, nos OKRs, no roadmap, na priorização de tarefas e na comunicação entre as pessoas.

Viva a cultura e seja seu maior exemplo

Qualquer pessoa exercendo liderança (seja ela posicional ou não) deve ser o maior exemplo da cultura organizacional. Como bem destacado pelo David Anderson, o potencial de uma organização sempre será limitado pela maturidade da sua liderança:

A maturidade de uma organização sempre será limitada pela maturidade de sua liderança. Resultados de negócios e aspirações sempre serão limitadas pela cultura e pelos valores.

Uma liderança madura sempre irá trabalhar para criar um senso de alinhamento, unidade e de propósito compartilhado. Uma liderança madura gerencia a cultura e a identidade. Uma liderança imatura é egoísta, narcisista e manipulativa. Uma liderança madura trabalha na cultura e identidade da organização.

O trabalho de criar uma cultura é árduo e requer muita repetição e consistência. Definir valores e princípios e não vivê-los como pessoa em liderança é o primeiro passo para criar cinismo na equipe.

O mesmo vale para momentos de medidas drásticas, em que certos elementos da cultura são desafiados: deixe claro para todas as pessoas quais são as circunstâncias e porque certas concessões são necessárias. A consistência se pagará neste momento.

Já parou para pensar na sua cultura hoje?

Agradecimentos

Não poderia deixar de agradecer a todas as pessoas que fazem parte do time de Tecnologia da N26 Brasil (Data, Design, Engenharia e Produto), por terem comprado o desafio de mudar a nossa relação com o dinheiro. Em especial, muito obrigado aos participantes do workshop de julho de 2021: Antonio Spinelli, Diógenes Medeiros, Henrique Sloty e Thiago Costa.

Três destaques do 2017 State of DevOps Report

Wed, 05 Jul 2017 07:30:00 -0300

A capa do 2017 State of DevOps Report.

Foi publicado mês passado o 2017 State of DevOps Report, um estudo publicado anualmente pela Puppet e DORA (DevOps Research & Assessment). Este estudo é uma leitura obrigatória para todo mundo, seja qual for a sua maturidade na adoção do DevOps.

Os números são surpreendentes por si só. DevOps funciona e times de alto desempenho, comparados com times de baixo desempenho:

Fazem mais deploys e mais rapidamente
- Frequência de deploys 46 vezes maior
- Templo de ciclo de commit para deploy 440 vezes mais rápido
Falham menos e se recuperam mais rapidamente
- Tempo médio para recuperação de interrupção 96 vezes mais rápido
- Taxa de falhas 5 vezes menor
Automatizam mais
- A gestão de configuração é 33% mais automatizada
- Os testes são 27% mais automatizados
- Os deploys são 30% mais automatizados
- O processo de aprovação de mudança é 27% mais automatizado
Tem 2 vezes mais chances de alcançar os objetivos

E agora, os meus três destaques.

Modelo de maturidade e melhoria contínua

Meu primeiro destaque não é sobre os números ou sobra uma descoberta chave. É sobre o modelo de maturidade do estudo. Eles classificam times de baixa, média e alta performance usando uma abordagem orientada por dados. A classificação é um resultado da análise anual da performance da TI, o que previne que times e organizações caiam numa “armadilha de sucesso”: após alcançar o nível de performance desejado, a melhoria contínua para, já que o objetivo era estático.

Este modelo de maturidade é um alvo em movimento, não um objetivo estático, e está realmente alinhado com o princípio da melhoria contínua do Lean. Times de alta performance e organizações inovadoras sabem que essa é a chave para a excelência.

Arquitetura

O segundo destaque vai para à arquitetura. Do estudo:

Em times de alta performance, a arquitetura do sistema é projetada para que times de entrega possam testar, fazer deploy e mudar seus sistemas sem depender de outros times para trabalho adicional, por recursos, aprovações e de vai-e-vem de comunicação. Portanto, nós descrevemos tanto a arquitetura quanto os times como sendo frouxamente acoplados.

E continua:

Abordagens arquiteturais que permitem esta estratégia incluem o uso de contextos delimitados (bounded contexts) e APIs como uma forma de desacoplar grandes domínios, resultando em unidades menores e mais frouxamente acopladas. A arquitetura também deve permitir o uso de dublês de testes e virtualização para permitir os testes dos serviços ou dos componentes de forma isolada. Arquiteturas orientadas a serviço presumem estas facilidades, como qualquer arquitetura que é realmente de microserviços deve presumir.

Não é surpresa que os Contextos Delimitados (Bounded Contexts) do Domain-Driven Design (DDD) seja citado como uma abordagem arquitetural que suporta esses times de alta performance. Para mim, DDD deveria ser parte da sua caixa de ferramentas na sua adoção DevOps¹.

DDD também suporta naturalmente uma arquitetura microserviços. Sam Newman diz, em seu livro Building Microservices (ele também é um revisor desse estudo), que Contexto Delimitado é uma forma de modelar microserviços com alta coesão e baixo acoplamento.

A cobertura de Contexto Delimitado do Sam Newman é muito superficial. Eu recomendo a leitura de um dos livros do Vaughn Vernon para um tratamento correto do assunto.

Liderança

As características da liderança transformacional estão altamente correlacionadas com a performance da TI. De fato, nós observamos diferenças significativas nas características da liderança entre times de TI de baixa, média e alta performance. Times de alta performance reportaram terem líderes com os comportamentos mais fortes entre todas as dimensões: visão, comunicação inspiracional, estímulo intelectual, liderança de apoio e reconhecimento pessoal. Em contraste, times de baixa performance reportaram os menores níveis nessas características de liderança. As diferenças que encontramos foram estatisticamente significante em todos os níveis.

Você não pode subestimar como uma liderança ruim pode minar a performance de um time. Eu tenho o princípio de que todo mundo quer fazer um bom trabalho, mas gerenciar pessoas é difícil. E desenvolvimento de software é um esforço tecno-humano, e sem a parte humana, você não tem a parte tecnológica.

O que eu ouço das pessoas são as mesmas estórias de terror de sempre: gerentes que usam Ágil como sinônimo de uma corrida perpétua para jogar código em produção, sem se preocupar com qualidade, sem dar tempo para permitir melhoria contínua e uma completa alienação dos times de desenvolvimento, que são apenas macaquinhos codificadores. Pessoas infelizes, código ruim e ciclo de entrega lento.

As últimas quatro dimensões podem ser mapeadas diretamente para os três elementos da motivação do Daniel Pink. Se você não está preparado para trabalhar com a motivação das pessoas ou você não liga para o assunto, faça um favor a todos: peça demissão.

Conclusões

O estudo é de uma leitura simples e rápida, cheia de insights. DevOps, que começou como um movimento cultural, é agora algo maior, amplamente divulgado e que está movendo-se no caminho do hype cycle. O estudo nos lembra pra focar nos resultados e enfatiza as práticas técnicas.

Eu também gostei do design gráfico do estudo, ao qual mostra uma interessante diversidade de gênero, cor e etnias. Parece intencional e é incrível! O infográfico vale o download também.

E, finalmente, eu discuti sobre esse estudo com o Fernando Ike no podcast Na Estrada DevOps (episódio 007), confira!

Referências

Brown et al, 2017. The 2017 State of DevOps Report (infográfico)
Pink, 2009. Drive: The Surprising Truth About What Motivates Us
Vernon, 2016. Domain-Driven Design Distilled (minha resenha)
Wikipedia. Hype cycle

Eu poderia criar o termo DDDevOps, mas para o bem geral, não o farei. ↩

Design bom é informado e cuidadoso

Tue, 13 Jun 2017 13:30:00 -0300

Na última semana, tive a oportunidade de conversar com diversas pessoas e times de diferentes empresas. E alguns temas comuns vieram a tona, como problemas de motivação, qualidade de código, escolhas questionáveis de arquitetura e ciclos de entrega lentos.

Fiquei refletindo sobre esses problemas e um elemento em comum me pareceu claro entre eles: a falta de design, ou melhor, design ruim. Para discutir o que é um design bom ou ruim, vamos à uma definição:

Bom design é design que é informado por informação específica: que tipo de clima você tem, que tipo de leis de construção você tem, que tipo de comportamento social você tem e qual você gostaria de promover. Então, tudo que você faz é feito para um propósito específico. Eu acredito que bom design é cuidadoso, design ruim é descuidado (Ingels, 2015)

Como dá para notar, Bjarke Ingels não trabalha com software: ele fala sobre clima, burocracia e comportamento social. Ingels é um arquiteto, mas ele tem um bom ponto: design bom é informado e cuidadoso.

Uma transformação parcial

Na minha apresentação de introdução a Domain-Driven Design, eu começo discutindo sobre como design foi deixado de lado mesmo com a transformação Ágil que ocorreu nos últimos 16 anos. Sandro Mancuso discute em seu livro, The Software Crafstman, sobre como essa transformação foi parcial:

As transformações Ágeis focaram principalmente no processo: no empoderamento de pessoas, na redução da burocracia e do desperdício, na priorização, na visibilidade do trabalho em progresso, e na melhoria do fluxo de informação. Esses eram problemas reais e importantes que precisavam ser resolvidos (…). Entretanto, os princípios por trás do (Manifesto) Ágil foram esquecidos. Processo se tornou mais importante que excelência técnica. Excelência técnica, que é assumida em cada metodologia Ágil, é normalmente ignorada por gerentes e por coaches despreparados. (Mancuso, 2014)

Essa transformação parcial se manifesta nos problemas que mencionei no início desse texto além dos proverbiais “tentamos, mas não funcionou” e “isso nunca iria funcionar aqui”. Não há como metodologias e processos que dependem de ciclos de feedbacks terem sucesso sem excelência técnica, e, portanto, sem a qualificação dos profissionais que compõe o time. E temos o seguinte (triste) fato:

Muitos projetos Ágeis estão agora, regularmente e iterativamente, produzindo código ruim. (Mancuso, 2014)

Design em toda parte

O design que se manifesta em código é fruto de uma intersecção entre o design da organização e o design do time. A questão de design, então, passa ao largo de ser um problema de um indivíduo no time.

Vale destacar que na maior parte do tempo, quando eu falo sobre desenvolvimento de software, estou falando em uma empreitada humano-tecnológica que é feita em time. A maioria dos softwares são desenvolvidos por times.

Por trás das metodologias Ágeis, do Lean/Kanban e do DevOps, sempre se encontra princípios ou objetivos para a criação de times altamente funcionais. Do Manifesto Ágil (Beck et al, 2001), temos os princípios 8 e 11, por exemplo:

Os processos ágeis promovem desenvolvimento sustentável. Os patrocinadores, desenvolvedores e usuários devem ser capazes de manter um ritmo constante indefinidamente
As melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis

Do Lean (Liker, 2003), temos os princípios 9 e 10:

Cresça líderes que entendam o trabalho completamente, vivam a filosofia e a ensine aos outros
Desenvolva pessoas e times excepcionais que sigam a filosofia da sua empresa

E do DevOps (Debois et al, 2016), dos Princípios de Aprendizado e Experimentação Contínuos, temos:

Habilite uma cultura de aprendizado organizacional e uma cultura de segurança
Institucionalize a melhoria do trabalho diário
Líderes reforçam uma cultura de aprendizado

Então, a atividade de desenvolvimento profissional de software ocorre em times, dentro de organizações. E o design da organização e do time influenciam no design de código. O doutor Melvin Conway tem umas palavras sobre esse fenômeno, que ficaram tão famosas que foram promovidas ao que é, hoje, conhecida como lei de Conway.

A lei de Conway

Qualquer organização que projeta um sistema (definido amplamente) irá produzir um design ao qual sua estrutura é uma cópia da estrutura de comunicação da organização (Conway, 1968)

A lei de Conway é uma observação sociológica que pode ser observada em diferentes tipos de organização de time. O famoso time de duas pizzas (T2P)¹ da Amazon, por exemplo, limita o tamanho dos times para um máximo de 5-10 pessoas. Essa restrição tem efeitos importantes (Debois et al, 2016):

O time tem um claro entendimento do sistema ao qual está trabalhando
Limita a taxa de crescimento do produto ou serviço sendo trabalhado
Descentraliza o poder e possibilita autonomia
Promove uma cultura sem medo, já que o escopo menor de trabalho limita as consequências das falhas

Da mesma forma, me parece que os Squads do Spotify (Kniberg, 2012) contribuem para alcançar esses mesmos efeitos.

A diferença é que a Amazon é uma organização com orientação ao mercado, otimizada para responder rapidamente às necessidades dos clientes e composta por times multidisciplinares em uma hierarquia plana. Já o Spotify é uma organização com orientação em matriz, que combina os elementos de organizações com orientação funcional (otimizadas para expertise, divisão de trabalho e redução de custo) e ao mercado.

O ponto mais importante que essas diferenças mostram é a escolha consciente do design da organização. Se design bom é informado, adotar uma organização de time como o T2P da Amazon ou o Squads do Spotify requer o entendimento não apenas da estrutura dos times como também das interdependências entre eles e dos impactos dessas novas dinâmicas na organização.

Esse design, feito de forma cuidadosa, ditará como o trabalho será feito e os resultados alcançados (Debois et al, 2016).

Times, indivíduos e código

O design dos times é resultado direto do design da organização. Times com orientação ao mercado são, em um extremo, totalmente responsáveis não apenas pelo desenvolvimento do software, como também pelos testes, pela segurança, implantação e por suportar seu serviço em produção. São times DevOps (Debois et al, 2016).

Já o time Scrum clássico é também multidisciplinar, composto pelo Dono do Produto (Product Owner), pelo Scrum Master e pelo Time de Desenvolvimento. No entanto, o objetivo desse time é de entregar um incremento de produto, este potencialmente lançável (Schwaber, 2013). A responsabilidade desse time é limitada ao desenvolvimento do software.

A definição da estrutura dos times vai dizer muito sobre as interações entre eles e sobre seus potenciais conflitos. Geralmente, os desenvolvedores tem muita participação nessa definição sobre como trabalhar. No entanto, parecem não ter noção da sua influência não apenas na organização como também na sociedade no geral: o mundo depende cada vez mais de software.

Desenvolvedores são, em geral, indivíduos altamente motivados e curiosos. Mas essa mesma curiosidade parece levar a uma mentalidade extremamente orientada à tecnologia. Não é incomum ver times tentando resolver problemas com tecnologia ao invés de fazer design cuidadoso. O modelo do software vira então uma Grande Bola de Lama (Foote; Yoder, 1999), com pouco a quase nenhum conhecimento do negócio codificado de forma expressiva.

É aqui que nós, como indivíduos, temos o dever de agirmos como profissionais. Ser profissional exige disciplina. As organizações ainda não nos entendem. O Uncle Bob (Martin, 2016) dá uma boa explicação sobre como ser profissional:

Em particular, o negócio não entende as nossas disciplinas (…), não entende Programação em Par, Desenvolvimento Guiado por Testes, Refatoração, Design Simples. Essas são disciplinas técnicas e não estão no expertise do negócio.

E não deveriam estar. Elas pertencem a nós, é parte do nosso expertise técnico. Então o negócio não pode aprová-las ou endossá-las. Você não pode chegar no negócio e dizer “Tudo bem se eu fizer testes?”. (…) Quando você faz isso, você está tentando se livrar do risco, você não está querendo tomar o risco, você o joga no negócio, que não pode avaliá-lo e tomá-lo. (…)

E o risco, francamente, é nosso. Nós somos os donos do risco. Nós que sabemos como as coisas precisam ser testadas, refatoradas, como que o software precisa ser feito e nós temos que tomar o risco como parte da nossa operação normal. Como profissionais. E é isso que profissionais fazem: eles tomam o risco no que eles sabem que deve ser feito.

Outra responsabilidade profissional que temos é o de entender o domínio do negócio em que trabalhamos:

(…) se os programadores não estão interessados no domínio, eles aprendem apenas o que a aplicação deve fazer, não os princípios por trás dela. Software útil pode ser desenvolvido dessa maneira, mas o projeto nunca chegará em um ponto onde novas funcionalidades poderosas surgirão como desdobramento de funcionalidades existentes (Evans, 2003)

Tanto o Uncle Bob quanto o Eric Evans expõe implicações econômicas profundas. Nosso profissionalismo pode ser a diferença entre o negócio realizar o retorno do investimento feito no desenvolvimento do software ou, ter software que é apenas custo.

Não podemos fugir das nossas responsabilidades: temos o dever, como profissionais, como indivíduos, de nunca parar de aprender e de melhorar em nosso ofício.

Design informado e cuidadoso

Uma aproximação de desenvolvimento de software que suporta design informado e cuidadoso é o Domain-Driven Design (DDD). O DDD é uma forma de desenvolver software que tem, como objetivo, implementar o melhor design de software baseado em modelos que refletem as competências da organização. DDD ajuda a desenvolver software que dá vantagem competitiva ao negócio, porque força a organização a entender no que ela deve se distinguir (Vernon, 2016).

Pra suportar as atividades de design na intersecção organização/time, o DDD possui ferramentas de design estratégico e tático. O design estratégico tem a ver com dividir o trabalho e encontrar o que é estrategicamente importante para o negócio. DDD é, resumidamente, sobre modelar uma Linguagem Ubíqua em um Contexto Delimitado (Vernon, 2016).

Essas ferramentas são os pilares do DDD. Times que adotam DDD conversam em uma Linguagem Ubíqua, que, além de falada tanto por desenvolvedores quanto por especialistas de domínio, é implementada no código do software (por isso é ubíqua). Para limitar e definir claramente o vocabulário dessa Linguagem, são usados os Contextos, que são barreiras semânticas. Dentro de um Contexto, cada termo tem um significado específico, entendido por todos os membros do time.

Os Contextos são o reconhecimento que o domínio do negócio é, além de grande e complexo, melhor gerenciado ao dividí-lo. A recomendação de manifestar cada Contexto como um time, um repositório e um banco de dados próprios (Vernon, 2016) alinha perfeitamente com a organização em times de produto, além de ser um caminho natural para uma arquitetura em Microserviços (Newman, 2014).

O modelo resultante do design estratégico é informado: o time adquiriu as informações do negócio para dividir o domínio em sub-domínios, encontrando seus Contextos e modelando a Linguagem Ubíqua.

Já o design tático é um catálogo de padrões que ajudam a implementar o modelo em código, com o objetivo de tornar o software um reflexo explícito do modelo. Se meu código é uma representação explícita do modelo que foi criado pelo esforço conjunto de desenvolvedores e especialistas de domínio, esse código documenta e centraliza o conhecimento do negócio. É design cuidadoso.

Melhoria contínua na raiz do design

Organizações e relações entre times são sistemas complexos. Desenvolvimento de software é uma atividade difícil. Dado esses desafios, traçarmos estratégias para executar essas atividades de design (organizacional, time e código) afim de transformarmos a organização.

Porém, uma transformação organizacional depende de pessoas. São elas que aprendem e mudam a organização (Soares, 2017). Em organizações de software, é muito comum haver uma sobrecarga de atividades transformacionais, com a adoção de múltiplos processos ocorrendo em paralelo.

Além de aumentar o risco de falhas na adoção e entendimento dos processos, essa sobrecarga causa problemas de moral no time. A cada nova falha, o time se sente mais desmotivado, por que, mesmo com suas melhores intenções e esforços, o novo processo não funcionou. Uma espessa névoa de indiferença e ressentimento toma conta do lugar.

Definir a criação de times totalmente DevOps como objetivo é um ótimo ponto de partida. DevOps, como conjunto de práticas, tem entre seus princípios a visualização do fluxo. A mentalidade Lean e o Método Kanban estão integrados no DevOps (Debois et al, 2016) e como já citado, a criação de uma cultura de melhoria contínua.

O Método Kanban é projetado para minimizar o impacto inicial das mudanças e para reduzir a resistência de adoção de mudança. Adotar o Kanban deve mudar a cultura da sua organização e ajudá-la a amadurecer. Se a adoção for feita corretamente, a organização irá se transformar em uma que adota mudança rapidamente e se torna boa em implementar mudanças e melhorias de processos. (Anderson, 2010)

Então não importa a estratégia, minimizar o impacto inicial e reduzir a resistência às mudanças é primordial para a implantação de uma cultura de melhoria contínua.

Design é inevitável

Questionamentos se design é necessário ou acessível perdem o ponto: design é inevitável. A alternativa para bom design é design ruim, e não a ausência de design. Douglas Martin. (Vernon, 2016)

Sendo design inevitável, cabe a nós definir o design da organização, dos times e do código. Na ausência de alternativa, melhor fazer design informado e cuidadoso. O que estamos esperando para começar?

Referências

Ingels, 2015. Bjarke Ingels: Good design is careful, bad design is careless (vídeo)
Mancuso, 2014. The Software Craftsman: Professionalism, Pragmatism, Pride
Beck et al, 2001. Princípios por trás do Manifesto Ágil
Liker, 2003. The Toyota Way: 14 Management Principles from the World’s Greatest Manufacturer
Debois et al, 2016. The DevOps Handbook: How to Create World-Class Agility, Reliability, and Security in Technology Organizations
Conway, 1968. How Do Committees Invent?
Kniberg; Ivarsson, 2012. Scaling Agile @ Spotify
Schwaber; Sutherland, 2013. The Scrum Guide
Martin, 2016. The Future of Programming (vídeo)
Foote; Yoder, 1999. Big Ball of Mud
Evans, 2003. Domain-Driven Design: Tackling Complexity in the Heart of Software
Vernon, 2016. Domain-Driven Design Distilled (minha resenha)
Newman, 2015. Building Microservices: Designing Fine-Grained Systems
Soares, 2017. Barriers to organizational learning
Anderson, 2010. Kanban: Successful Evolutionary Change for Your Technology Business

A ideia é que o time deve ter um tamanho que possibilite ser alimentado por duas pizzas. Acredito, pelo menos por enquanto, que não é um plano da Amazon de aumentar a procura por pizzas ao abrir o apetite de leitores desavisados. ↩

Mapeando seu conhecimento de domínio

Mon, 07 Nov 2016 08:30:00 -0200

Nós construímos software para ajudar as pessoas - os usuários e os clientes - a alcançarem seus objetivos. Esta é a única maneira da sua organização conseguir o que almeja: faturamento para empresas ou um impacto mensurável para organizações sem fins lucrativos.

Para construir qualidade em software, empregamos uma variedade de práticas como Desenvolvimento Orientado a Testes (Test-Driven Development, TDD) e Integração Contínua (Continuous Integration). Essas práticas são ótimas para diminuir o número de defeitos no código mas, sozinhas, não garantem que o software desenvolvido contenha os conceitos do domínio do negócio tampouco que ajude as pessoas de forma efetiva a alcançarem seus objetivos. É muito fácil desenvolver o software errado.

É por isso que as metodologias Ágeis incluem práticas que melhoram a comunicação e a colaboração. Por exemplo, o Scrum tem eventos como o Daily Scrum, o Planejamento da Sprint (Sprint Planning) e a Retrospectiva da Sprint (Sprint Retrospective). O Extreme Programming tem o Time Coeso (Whole Team) e as Metáforas de Sistema (System Metaphor). Ambas as metodologias fazem uso do Desenvolvimento Iterativo, não apenas para entregar software funcional frequentemente, como também para provar a hipótese de valor do software entregue. Estas práticas são baseadas nos princípios do Manifesto Ágil de redução do risco de desenvolver o software errado.

Entregar software funcional que deixa as pessoas felizes não significa que o time está criando entendimento compartilhado como tampouco significa que o design do software tem os conceitos do domínio onde opera. E aqui vai uma crítica aos meus camaradas desenvolvedores, uma que escuto frequentemente: na correria para desenvolver uma funcionalidade solicitada, nós evitamos as conversas que ajudam a criar entendimento compartilhado do negócio em favor de discussões técnicas.

A crítica é benéfica porque mostra que as pessoas de negócio estão interessadas em criar este entendimento compartilhado, que elas estão incorporando os princípios do Manifesto Ágil. Mas estamos pulando direto para a implementação, perdendo uma oportunidade de aprender o domínio e de modelar o software com os conhecimentos do domínio. Eric Evans (2003) vai além:

(…) se os programadores não estão interessados no domínio, eles aprendem apenas o que a aplicação deve fazer, não os princípios por trás dela. Software útil pode ser desenvolvido dessa maneira, mas o projeto nunca chegará em um ponto onde novas funcionalidades poderosas surgirão como corolárias de funcionalidades existentes (Evans, 2003)

Como motivar os desenvolvedores a se interessarem mais sobre o domínio do negócio? O Mapeamento de Estórias de Usuário pode ajudar.

Um mapa incipiente do Wikidu

Mapeamento de Estórias de Usuário

O Mapeamento de Estórias de Usuário (User Story Mapping) é um padrão descoberto por Jeff Patton que ajuda times a entenderem um produto ou funcionalidade completa, com o objetivo de construir um produto melhor:

Mapear estórias nos mantém focados nos usuários e na sua experiência, resultando em melhores conversas e, ultimamente, em um produto melhor. (Patton, 2014)

A excepcional documentação que Patton criou joga uma luz em como as estórias¹ tem sido mal usadas, fazendo com que times caíssem em uma ou mais armadilhas, aos quais destaco duas:

O backlog plano: estórias permitem que times foquem em construir pequenas coisas, perdendo a visão do horizonte maior. Frequentemente resulta em produtos Frankenstein, onde o produto parece ter sido montado com partes que não se encaixam
Forma ao invés de substância: quando há foco apenas em escrever estórias ao invés de criar entendimento compartilhado

Eu incluo uma introdução rápida para explicar melhor como o padrão ajuda a motivar todos na criação de entendimento compartilhado. Você precisará de notas adesivas (post-its), canetas e uma mesa ou parede (ou um quadro branco).

A coluna backlog não mostra a visão desse produto

Introdução

Configure um timebox (10 minutos no máximo), e peça que as pessoas escrevam, em silêncio, as tarefas que os usuários farão na sua aplicação. Essas tarefas de usuário são coisas como “Solicitar uma corrida”, “Avaliar o livro”, “Adicionar produto ao carrinho”. Uma vez que todo mundo terminou, peça às pessoas que leiam cada nota e a coloquem em cima da mesa. Se houver tarefas duplicadas, elimine-as. Em resumo, os passos são: pense, escreva, explique e posicione.

Você descobrirá algumas coisas interessantes durante o processo:

A maioria das notas serão de frases verbais curtas
As pessoas irão organizar as tarefas intuitivamente num fluxo ordenado, com as tarefas que devem ocorrer primeiro no lado esquerdo com as conseguintes após elas
Algumas notas irão conter tarefas que acontecem ao mesmo tempo que outras tarefas. Essas são sub-tarefas. Numa aplicação de software, podem ser passos adicionais e/ou opcionais que o usuário dará

Agora que você identificou as tarefas do usuário, é hora de organizar seu mapa. Intuitivamente, parte desse trabalho já foi feito: tarefas que devem acontecer primeiro foram colocadas no lado esquerdo, com tarefas posteriores seguindo-as. Empilhe as sub-tarefas abaixo das tarefas principais.

Para validar se este fluxo está consistente, comece a contar a estória do seu mapa: aponte para a primeira tarefa dizendo “Primeiro o usuário faz isso” e, então, aponte para a próxima dizendo “e então ele faz isto” até a última tarefa.

Este é o “fluxo narrativo” como definido por Patton. Re-ordene a posição das tarefas se a narrativa parecer sem sentido. Você sempre irá encontrar ausência de detalhes porque o mapa o ajuda a ver o horizonte do produto, o todo. Preenche os detalhes que faltam enquanto completa o mapa.

Prove a consistência do seu mapa contando a estória dele

O próximo passo é o de destilar o mapa. Dê um passo para trás e preste atenção no fluxo narrativo. Você encontrará grupos de tarefas que são muito próximas. As tarefas de um usuário de e-commerce, “Adicionar ao carrinho”, “Estimar frete” e “Fazer checkout” poderiam ser agrupadas em uma atividade “Fazer pedido”. Em uma rede social, “Procurar por nome”, “Visitar o perfil da pessoa” e “Adicionar contato” poderiam ser agrupados em atividades como “Conectar” ou “Fazer amizade”.

Escreva o nome da atividade em uma nota e a coloque acima do grupo de tarefas correspondente. Valide se o fluxo narrativo ainda está consistente, lendo as atividades da mesma forma que você leu as tarefas. As atividades formam a coluna vertebral do mapa.

A coluna vertebral do mapa é formada pelas suas atividades

Adicionado contexto ao mapa

Uma mapa pode ter mais que tarefas e atividades de usuários. Você pode adicionar mais informações importantes ao mapa, ajudando a criar entendimento compartilhado:

Oportunidades e hipóteses. Por quê construí-lo? Que tipo de problema resolve?
Princípios do produto. Exemplos: divertido, fácil, acessível (isto deveria ser um princípio de qualquer produto!), amigável, rápido
Clientes e usuários. Quem são os usuários? Quais os diferentes papéis desses usuários? Por quê eles irão usar o produto? O que nós achamos deles? Quais tipos nós iremos priorizar agora?
Detalhes, opções, dúvidas. Mais detalhes sobre as tarefas e atividades podem ser adicionadas assim como alternativas. Notas com dúvidas podem ser adicionadas caso alguém não tenha certeza sobre como irá funcionar. Observações sobre como outros serviços - competidores ou não - resolveram o problema podem ser colocados no mapa.

Você pode usar notas adesivas de diferentes cores e colocar esta informação onde for mais útil para fins de contextualização.

Enriqueça sua conversa adicionando mais contexto no seu mapa

Criar entendimento compartilhado é a chave

O que realmente importa durante a criação do mapa é o entendimento compartilhado criado atráves de melhores conversas. Esta era a ideia do Kent Beck quando introduziu o conceito de estórias: para trocar o foco de documentos compartilhados por entendimento compartilhado.

Apenas escrever estórias como documentos compartilhados não ajuda a criar entendimento compartilhado porque quando alguém lê uma estória, pode interpretá-la de forma diferente do autor da estória. A única forma possível é externalizando nossas ideias. A estória escrita se torna então um meio, e não um fim.

Como isso pode motivar desenvolvedores que só pensam em tecnologia?

Como desenvolvedor, eu sei muitos dos motivos que fazem com que desenvolvedores fiquem menos preocupados com o negócio. Uma delas é a ausência de visão de produto, a falta de um horizonte. Roadmaps são constantemente criados para prover esse horizonte mas não são visuais o suficiente ou atualizados para comunicar claramente em que ponto da jornada o time está. E o backlog plano pode dar a impressão que o único trabalho dos desenvolvedores é o de processar novas estórias.

Isto os aliena dos objetivos de negócio, perdendo então o interesse sobre o domínio. E como desenvolvedores gostam de construir coisas, é fácil focar a atenção no lado tecnológico e resolver problemas de domínio com tecnologia (Evans, 2003).

Como ferramenta visual, um mapa pode claramente radiar informação sobre este horizonte. Pode ser usado para priorizar estórias a serem trabalhadas (Patton explica técnicas de priorização em seu livro). É um roadmap vivo. Os desenvolvedores podem entender o quê e o porquê do que estão trabalhando e como isso se encaixa no horizonte.

Pedir ajuda aos desenvolvedores para criar o mapa (acho que o primeiro mapa deve ser criado com a colaboração do time inteiro) pode ajudar não apenas com diferentes pontos de vista como também com ideias interessantes e valiosas (desenvolvedores tendem a ser early adopters de todo tipo de tecnologia, de aplicativos à wearables). Quando eles começarem a perguntar o porquê/o quê/como, não estarão apenas ajudando a criar entendimento compartilhado, como também exibindo disposição para aprender sobre o negócio.

Criar o mapa pode ajudar também a criar relacionamentos fortes entre os membros do time e a desenvolver valores como respeito e coragem. Se o time for além e tentar entender melhor os usuários/clientes e criar personas², podem criar empatia pelos usuários nos desenvolvedores. Relacionamentos mais fortes entre os membros do time, mais consciência sobre os objetivos do negócio e mais empatia pelos usuários pode fazer emergir um dos três elementos da motivação: propósito (Pink, 2009). Propósito é o anseio de fazer o que fazemos por algo maior que nós mesmos. Pessoas que encontram o propósito no seu trabalho alcançam o último nível do jogo da motivação.

Mapeie para ajudar na sua adoção de DDD e para produzir uma Linguagem Ubíqua

O livro Domain-Driven Design (DDD) de Evans introduziu uma nova abordagem de desenvolvimento de software que baseia a implementação do design em um modelo do domínio. Pode ajudar a alcançar um nível onde o design é exatamente como o software funciona (Vernon, 2013), por meio de ferramentas estratégicas e táticas que ajudam a projetar software de alta qualidade e que satisfaz os objetivos do negócio (core business).

Como abordagem, DDD não é sobre tecnologia:

DDD é sobre discussões, escutar, entender, descobrir, valores de negócio, tudo no esforço de centralizar o conhecimento. Se você for capaz de entender o negócio sobre o qual a sua empresa opera, você pode no mínimo participar no processo de descoberta de modelagem de software para produzir uma Linguagem Ubíquia (Ubiquitous Language) (Vernon, 2013)

Para construir um modelo de domínio e efetivamente adotar DDD, é necessário processar conhecimento³. “Centralizar o conhecimento” é um sinônimo de “criar entendimento compartilhado”. Evans diz que modeladores de domínio são processadores de conhecimento e enfatiza que isto é uma atividade de time (e um requisito para a prática de DDD):

Processamento de conhecimento não é uma atividade solitária. Um time de desenvolvedores e especialistas no domínio colaboram, tipicamente liderados por desenvolvedores. Juntos eles obtêm informações e a processam em um formato útil. A matéria prima vem das mentes dos especialistas no domínio, dos usuários de sistemas existentes, da experiência prévia do time técnico com o sistema legado ou de outro projeto no mesmo domínio. Vem na forma de documentos escritos para o projeto ou usados no negócio, e de muitas e muitas conversas. Primeiras versões ou protótipos retroalimentam o time e mudam interpretações. (Evans, 2003)

Desse processamento de conhecimento, o time (desenvolvedores e especialistas no domíno) devem desenvolver uma Línguagem Ubíqua, que é uma linguagem compartilhada. O vocabulário dessa linguagem é centrado em como o negócio em si pensa e opera (Vernon, 2013) . Esta linguagem previne desendentimento entre as pessoas de negócio e os desenvolvedores ao remover a necessidade de traduções entre conceitos de negócio e as abstrações usadas no design do software.

A Linguagem Ubíqua é um dos pilares do DDD ao lado dos Contextos Delimitados (Bounded Context) (Vernon, 2013) . Seu vocabulário inclue nome de classes e operações proeminentes, sendo o principal portador dos aspectos do design que não aparecem no código (Evans, 2003).

É aqui que o Mapeamento de Estórias pode ajudar na sua adoção de DDD. É uma técnica incrível para começar o processamento de conhecimento e produzir o glossário inicial da Linguagem Ubíqua. Faça esse esforço de forma colaborativa: irá ajudar a formar o seu time e irá motivá-los a terem as conversas necessárias.

Mapeie para avaliar a complexidade do seu domínio

No Implementing Domain-Driven Design, Vernon apresenta um scorecard⁴ para ajudar times a determinarem se vale a pena adotar DDD em um projeto. Se você tiver uma pontuação maior ou igual a sete, considere a adoção de DDD.

Se o seu projeto	Pontos	Considerações de apoio
Se sua aplicação é completamente centrada em dados e qualifica-se para uma solução CRUD pura, onde cada operação é basicamente uma simples consulta no banco de dados para Criar, Ler, Atualizar ou Apagar, você não precisa de DDD. Seu time precisa apenas colocar uma cara bonita em cima de um editor de tabelas de banco de dados. Em outras palavras, você pode confiar nos seus usuários inserindo dados diretamente em uma tabela, atualizá-los, e de vez em quando apagá-los, você pode nem precisar de uma interface. Isto não é realista, mas conceituamente relevante. Você poderia até usar uma simples ferramenta de desenvolvimento de banco de dados para criar uma solução, não gaste o tempo e dinheiro da sua empresa com DDD.	0	Isto parece simples, mas geralmente não é fácil determinar o simples versus o complexo. Não é como se cada aplicação que não é um CRUD puro merecesse o tempo e esforço de adotar DDD. Então talvez pudéssemos ter outras métricas úteis para delinear o que é complexo e o que não é…
Se o seu sistema requer apenas 30 ou menos operações de negócio, provavelmente é muito simples. Isto significaria que sua aplicação teria não mais que 30 estórias de usuário or fluxos de caso de uso, cada um desses fluxos tendo lógica mínima de negócio. Se você puder rapidamente e facilmente desenvolver tal aplicação usando Ruby on Rails ou Groovy and Grails e não sentir a dor da falta de poder e controle sobre complexidade e mudança, seu sistema provavelmente não precisa de DDD.	1	Pra ser claro, eu estou falando de 25-30 métodos de negócio únicos, não 25-30 interfaces completas de serviços, cada qual com múltiplos métodos. O último pode ser complexo
Vamos dizer que em algum lugar no intervalo de 30 a 40 estórias de usuário ou fluxos de caso de uso poderia indicar complexidade. Seu sistema pode estar entrando no território do DDD.	2	Atenção: frequentemente complexidade não é reconhecida cedo o suficiente. Nós desenvolvedores de software somos, de fato, bons em subestimar complexidade e esforço. Apenas porque possamos querer codificar uma aplicação usando Ruby ou Grails não significa que devemos. No longo prazo, isto pode mais atrapalhar que ajudar
Mesmo que a aplicação não vá ser complexa agora, a complexidade irá aumentar? Você pode não saber com certeza até que os usuários reais comecem a usá-la, mas há um passo em Considerações de apoio que pode ajudar a descobrir a situação real. Tenha cuidado. Se há alguma dica de que a aplicação tem até mesmo complexidade moderada - esta é uma boa hora pra ser paranóico - pode ser um indicador suficiente que irá ser realmente mais do que moderadamente complexa. Considere DDD.	3	Aqui vale a pena revisar os cenários de uso mais complexos com especialistas no domínio e ver onde isto leva. Os especialistas de domínio… (1) já pediram funcionalidades mais complexas? Se sim, é um indicador suficiente que a aplicação já é ou em breve se tornará muito complexa para usar uma abordagem CRUD. (2) estão tão entediados com as funcionalidades que dificilmente suportam discutí-las? Provavelmente não é complexo.
As funcionalidades da aplicação irão mudar frequentemente ao longo dos anos, e você não pode antecipar que tipos de mudanças serão simples	4	DDD pode ajudar você a gerenciar a complexidade da refatoração do seu modelo ao longo do tempo.
Você não entende o Domínio porque ele é novo. Tão longe quanto você e seu time sabe, ninguém fez isto antes. Isto provavelmente significa que é complexo, ou ao menos merece a diligência devida com escrutínio analítico para determinar o nível de complexidade	5	Você precisará trabalhar com especialistas no domínio e experimentar com modelos para conseguir fazer certo. Você provavelmente pontuou em ou ou mais dos itens anteriores, então use DDD.

Após concluir o seu mapa, você verá o horizonte do produto que você quer construir. Você se lembra das tarefas de usuário? Elas são as estórias que o seu time precisará desenvolver. Cada uma pode ter n sub-tarefas ou fluxos alternativos. Conte-as e você saberá se o você pontuou no segundo ou terceiro caso. Outros indicadores de complexidade são a densidade visual do mapa e a quantidade de papéis de usuário (e a forma como eles influenciam as tarefas).

Obviamente o mapa sozinho pode não ser suficiente para avaliar a complexidade do seu projeto. Por exemplo, muitas startups exploram oportunidade de negócio que se encaixam no último caso. E quando uma startup depende de uma aplicação de software para o seu negócio, você deve esperar que suas funcionalidades irão mudar ao longo do tempo para melhor suportar seu crescimento e sua continuidade. Use o mapa como uma matéria-prima para sua avaliação.

Conclusões

Mapeamento de Estórias de Usuário é um padrão simples mas intuitivo que resgata a ideia original das estórias do Kent Beck: de ter uma boa conversa para o bem do entendimento compartilhado. Como uma tarefa colaborativa, ajuda na formação e motivação do time.

Alguns praticantes ágeis podem temer que o mapeamento de estórias seja muito planejamento. Não é para ser. Construa o primeiro mapa para descobrir a narrativa e então o use para priorizar as estórias a serem desenvolvidas. Quando estiverem próximas a serem priorizadas para serem desenvolvidas, inicie o processamento de conhecimento para identificar o que você precisa aprender.

Mantenha-o como um documento vivo e o atualize cada vez que você descobrir algo novo. Atualize o fluxo narrativo enquanto você valida a sua hipótese de valor. Use o mapa como seu backlog, sem perder a visão de horizonte!

Curiosamente, alguns desenvolvedores acostumados a desenvolvimento Ágil temem que DDD podem levá-los a fazer design prematuro. Minha crença pessoal é que esta impressão é causada pela ênfase nas conversas e nos diagramas encontrada na literatura. Você precisa discutir porque precisa aprender os princípios do negócio por trás da estória. Os diagramas são apenas abstrações, eles não necessariamente refletem o design futuro: muito será deixado para ser descoberto e é aqui que TDD brilha.

Por último mas não menos importante, Mapeamento de Estórias pode ser valioso na sua avaliação da adoção de DDD. Se seu projeto é complexo e você adotar a abordagem DDD para desenvolvimento de software, o mapa pode ajudar a iniciar o processamento de conhecimento e na produção inicial do glossário da Linguagem Ubíqua.

Agradecimentos

Obrigado ao Nelson Senna e Fernando Ike pela revisão e pro Vaughn Vernon pelo feedback positivo.

Referências

Eu uso o substantivo estória ao invés de estória de usuário por conveniência. Estórias são amplamente usadas em metodologias Ágeis para propósitos de planejamento. Introduzidas por Kent Beck, estórias encorajam conversas informais para a criação de conhecimento compartilhado. ↩
Uma persona é uma representação escrita de um usuário específico ao qual pode ser usada para tomar decisões sobre funcionalidade do software. Patton descreve uma forma pragmática de criar personas. ↩
Como no restante desse texto, a tradução é livre. Uma tradução literal seria triturar conhecimento (to crunch knowledge). ↩
Uma explicação completa do scorecard do DDD também está disponível no site do InformIT ↩

Palestras sobre web performance na Germinadora

Wed, 13 May 2015 09:30:00 -0300

No próximo dia 18, teremos duas palestras em São Paulo (capital) sobre web performance. A organização é da Germinadora, dentro do Papo de Primeira, uma série de eventos gratuitos voltados ao ecossistema de startups brasileiras.

Assistindo as palestras, você irá se questionar se seu site está preparado para um milhão de usuários além de aprender as novidades do HTTP/2. O interessante deste evento é que as palestras complementam-se. Na primeira, são discutidos os impactos que uma performance ruim tem na retenção e conversão de usuários e uma série de técnicas para otimização de sites enquanto a segunda mostra o caminho da adoção do protocolo HTTP/2, ao qual tem o objetivo de tornar a Internet mais rápida.

E claro, um conteúdo desses torna-se mais atraente quando sabemos que os palestrantes, Fernando Ike e Alex Soares, trabalham há anos em projetos dos maiores portais da América Latina na Exceda/Akamai. É conhecimento direto da trincheira!

A ideia do evento é do Fernando Ike, entre um café e outro enquanto discutíamos sobre tecnologia e a vida (de contêineres). Estamos para decidir a frequência das palestras, a temática e a data da próxima edição. Considere esta um ensaio para um novo evento (e sim, este é um anúncio extraoficial).

Os agradecimentos especiais vão para o Dairton Bassi (Agile Trends) e para a Barbara Bernabó e o Ibrahim Cesar (Germinadora) por facilitarem este encontro.

Espero você por lá!

Quando, onde e como

18 de maio, às 7:30 PM
Germinadora, Rua Eng. José Sá Rocha, 173, São Paulo/SP
É necessário confirmar presença através do Meetup. Na página do evento no Meetup tem uma descrição mais completa das palestras e as mini-biografias dos palestrantes
As palestras serão disponibilizadas em vídeo posteriormente

Composer: não tente, use

Wed, 24 Dec 2014 17:00:00 -0200

A nova edição do Technology Radar da ThoughtWorks listou pela primeira vez um projeto em PHP e foi o Composer. Entretanto, eles listaram o composer no quadrante Trial (tentar, experimentar), enquanto eu acredito que deveria ter sido listado no quadrante Adopt (adotar). E eu quero dizer a você o por quê.

Primeiro, é importante ressaltar que o Technology Radar não é uma lista das tecnologias aprovadas pela ThoughtWorks. É uma compilação de tecnologias baseado apenas em opiniões e experiência de técnicos seniores. É uma publicação repleta de insights ao qual recomendo a leitura.

Quando eu penso no nome “ThoughtWorks”, PHP não me vem à mente. Eu não lembro de nenhuma publicação deles mencionando a linguagem. Com isto em mente, fiquei surpreso ao ver que o Composer havia sido listado. Talvez essa falta de intimidade com o ecossistema PHP seja a razão do porque o Composer foi posicionado no quadrante Trial.

O Composer foi lançado no final de 2011. Até então, instalar dependências em projetos PHP era limitado a duas escolhas: funcionalidades de sistemas de versão de controle como o SVN externals ou submodules Git ou, se disponível, através do instalador PEAR.

Ainda naquele ano, o Symfony2 tinha sido lançado em julho, empurrando o ecossistema PHP. Uma onda de bibliotecas e ferramentas haviam sido lançadas, renovando o interesse na linguagem. Composer, lançado meses depois, era a ferramenta que precisávamos para nos beneficiar facilmente dessas novas bibliotecas e ferramentas.

Em algumas semanas, 227 pacotes estavam listados no Packagist (o principal repositório de pacotes do Composer) enquanto o repositório PEAR tinha 592 pacotes. O que foi impressionante foi o fato que esses pacotes eram para o PHP 5.3+ enquanto que no PEAR apenas 192 pacotes eram PHP 5+. O impacto talvez tenha sido mais rápido do que Jordi Boggiano (um dos desenvolvedores líderes do Composer) previu.

Hoje, 45 mil pacotes estão registrados no Packagist. Rubygems, que remonta a 2003, tem 93 mil gems. Brechas de segurança foram discutidas, corrigidas e alternativas foram propostas. Ferramentas adicionais lançadas por desenvolvedores da comunidade ajudam a garantir maior segurança. A boa documentação provê um ponto de partida seguro e sempre tem alguém ajudando você a usá-lo da forma correta.

Por último e não menos importante, milhares de organizações estão usando o Composer para gerenciar dependências. Milhões de execuções em ambientes de Integração Contínua aconteceram além de outras milhões de milhões em ambientes de desenvolvedores. Como não recomendar uma ferramenta que é a solução de-facto na caixa de ferramentas do ecossistema?

Não faça com que as pessoas riam de você num bar ao dizê-las que você não usa o Composer.

Uma imagem Docker para desenvolvimento PHP multiversão

Tue, 16 Dec 2014 11:30:00 -0200

Eu liberei uma imagem Docker voltada para desenvolvimento PHP com as últimas versões suportadas do PHP instaladas mais a última versão do PHP 5.3. O objetivo da imagem é ajudar desenvolvedores que precisam desenvolver e testar seus projetos em diferentes versões do PHP (especialmente desenvolvedores de softwares livres ou de código aberto).

Docker é uma ferramenta construída em cima das funcionalidades de virtualização de nível de sistema operacional do Linux. Permite que aplicações sejam construídas e entregues como containers (contêineres), o que pode significar que você pode usá-lo no seu deployment pipeline para gerar um container Docker como seu binário entregável (se adotar Docker tanto para desenvolvimento como para produção) ou apenas usá-lo para propósitos de desenvolvimento como uma reposição ao Vagrant, por exemplo. Eu não vou me estender nesse assunto, leia o Docker User Guide e este parágrafo irá ficar muito mais claro, acredite!

Usando a imagem Docker

Agora que você está acostumado com o Docker e o instalou, usar a imagem PHP Development será bem simples. Na data de publicação desta, as seguintes versões do PHP estão disponíveis:

5.6.3
5.5.19
5.4.35
5.3.29

Cada versão do PHP vem com as extensões Zend OPCache e Xdebug instaladas e algumas ferramentas de QA para PHP estão instaladas globalmente com o Composer. A imagem também possui o Nginx e PHP-FPM instalados. Veja a página da imagem para uma lista completa das extensões e bibliotecas instaladas.

Vamos iniciar um novo container. Primeiro, faça o download da imagem do Docker Hub:

$ docker pull eriksencosta/php-dev

Agora, vamos criar uma aplicação “Hello World” muito simples:

$ mkdir ~/hello-world; echo '<?php echo "Hello world!";' > ~/hello-world/index.php

Inicie o container:

$ docker run -p 80:80 -v ~/hello-world:/var/www/hello-world -d "eriksencosta/php-dev:latest"

Abra o endereço http://localhost/hello-world/ (se estiver usando o Boot2Docker, substitua localhost com o endereço de IP retornado pelo comando boot2docker ip) no seu navegador e se delicie com a sua incrível aplicação cumprimentando o mundo inteiro. Melhor que a ONU, dizem.

Se você acessar o endereço http://localhost/info.php, você verá a informação completa da versão do PHP em execução.

Trocando entre as versões do PHP

Para ver o valor real da imagem, você precisa trocar entre versões PHP. Pare o container atual em execução:

$ docker stop $(docker ps -l | tail -1 | awk '{print $1}')

E inicie um novo container em modo interativo:

$ docker run -t -i -p 80:80 -v ~/hello-world:/var/www/hello-world "eriksencosta/php-dev:latest" /bin/bash

Você será atribuído a um terminal no container. Para trocar entre diferentes versões do PHP, use o comando phpenv:

# phpenv versions
  5.3
  5.3.29
  5.4
  5.4.35
  5.5
  5.5.19
  5.6
* 5.6.3 (set by /opt/phpenv/version)

5.6, 5.5, 5.4 e 5.3 são apenas atalhos. O phpenv permite que você defina as versões globais (pro sistema) e locais do PHP. Para determinar globalmente:

# phpenv global 5.4
# php -v
PHP 5.4.35 (cli) (built: Dec 14 2014 00:35:12)
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.4.0, Copyright (c) 1998-2014 Zend Technologies
    with Zend OPcache v7.0.3, Copyright (c) 1999-2014, by Zend Technologies
    with Xdebug v2.2.6, Copyright (c) 2002-2014, by Derick Rethans

Para determinar uma versão local, execute:

# cd /var/www/hello-world
# phpenv local 5.3
# php -v
PHP 5.3.29 (cli) (built: Dec 14 2014 00:24:19)
Copyright (c) 1997-2014 The PHP Group
Zend Engine v2.3.0, Copyright (c) 1998-2014 Zend Technologies
    with Zend OPcache v7.0.3, Copyright (c) 1999-2014, by Zend Technologies
    with Xdebug v2.2.6, Copyright (c) 2002-2014, by Derick Rethans

Para iniciar o Nginx e o PHP-FPM, execute:

# webserver start
Starting PHP-FPM (PHP version 5.3) server.
Starting Nginx server.
Done.

Para desabilitar o Zend OPCache (é habilitado por padrão):

# opcache disable
The Zend OPCache (PHP version 5.3) was disabled.

You need to restart the webserver for the changes to take effect.
Execute: webserver restart

Um exemplo da vida real

Não há nada de errado com a nossa aplicação “Hello World” mas… ela não faz nada! Então vamos ver um exemplo melhor usando uma aplicação Silex bem simples. Esta aplicação exemplo é um issue tracker que apenas lista as issues (que estão armazenadas em um banco de dados MySQL). Faça um clone do repositório da aplicação:

$ cd ~
$ git clone git://github.com/eriksencosta/silex-docker-example.git

Nossa aplicação precisa de um banco de dados MySQL. Mas nosso container PHP não vem com um servidor MySQL. O poder do Docker está no uso de imagens leves como blocos de construção. Então, ao invés de criar uma imagem com todas as dependências da aplicação, você inicia diferentes containers Docker e os consome como recursos anexados de rede. Com isto em mente, faça o download da imagem Docker do MySQL:

$ docker pull mysql

Inicie o container MySQL:

$ docker run --name some-mysql -e MYSQL_ROOT_PASSWORD=root -d mysql

Inicie o container PHP:

$ docker run -t -i --link some-mysql:mysql -p 80:80 -v ~/silex-docker-example:/var/www/example -P "eriksencosta/php-dev:latest" /bin/bash

Execute os comandos de preparação e configuração necessários:

# cd /var/www/example
# composer install
# php app/console example:configure:environment --variable="EXAMPLE_DEBUG=true"
# php app/console example:database:create
# php app/console example:schema:create

Para verificar que tudo está funcionando, execute a suíte de testes:

# behat

Carregue as fixtures no banco de dados:

# php app/console example:fixtures:load --truncate

Configure o virtual host Nginx e inicie os servidores:

# cp dockerfiles/php-dev/default.vhost /etc/nginx/sites-available/default
# webserver start

No seu navegador, acesse http://localhost. Isso é tudo!

Concluindo

Eu limitei o escopo deste post para apresentar a você a imagem Docker e não para explicar totalmente o que é o Docker e como usá-lo mas, espero que eu tenha despertado o interesse em você.

Esta imagem Docker é voltada apenas para propósitos de desenvolvimento (não é para ser usada em produção!). A imagem é construída usando o playbook Ansible PHP Development. O Dockerfile também está no GitHub. O README da aplicação de exemplo em Silex tem um exemplo de uso extra.

Painel sobre Continuous Delivery da Electric Cloud - você está convidado!

Tue, 09 Sep 2014 09:35:00 -0300

Atualização (17 de setembro): veja a página oficial do evento.

No dia 8 de outubro, eu irei participar em um painel on-line com experts em Agile, DevOps e Continuous Delivery. O painel é organizado pela Electric Cloud, que tem feito grandes projetos de Continuous Delivery para organizações como SpaceX, Cisco, GE e E*TRADE.

No painel, eu e os demais painelistas iremos discustir como entregar melhor software continuamente, quais são os obstáculos na adoção do Agile, o que DevOps significa e como é a jornada para chegar ao Continuous Delivery - passando por Continuous Integration e automação de deployment.

A Electric Could também irá compartilhar a sua experiência implementando Continuous Delivery em grande escala, oferecendo vitórias rápidas que qualquer um pode implementar para acelerar a entrega de software. Será uma discussão espontânea de Continuous Delivery de como e em qual extensão podemos implementá-la.

Eu tenho certeza que o painel será incrível. O pessoal na Electric Cloud está organizando esse evento como artesãos: com altos padrões para a qualidade da discussão. Os painelistas incluem experts com diferentes backgrounds em diversas indústrias e de diferentes países.

Assista e junte-se a nós no painel, e preencha a rápida pesquisa sobre o estado da entrega de software - nós iremos discutir os resultados durante o painel.

Quando

8 de outubro, às 10 AM PST (2 PM no horário de Brasília, verifique o seu fuso horário)
Preencha a rápida pesquisa sobre o estado da entrega de software
Assista e junte-se a nós no painel: esse link irá começar a funcionar minutos antes do evento. Não é necessário se cadastrar. O evento irá acontecer on-line através do GoToMeeting - no seu navegador web. Verifique os requisitos de sistema do GoToMeeting (se for assistir usando um dispositivo móvel, instale o aplicativo iOS ou o aplicativo Android)

Como instalar o RabbitMQ com a última versão do Erlang no Debian

Mon, 06 May 2013 07:00:00 -0300

O RabbitMQ é uma aplicação Erlang. A linguagem evolui rapidamente e cada nova versão tem otimizações de performance. Isto é bom até que você tenta instalar o pacote DEB do RabbitMQ no seu servidor Debian-like e nota que o gerenciador de pacote instalou uma versão antiga do Erlang.

Para o Debian Squeeze, o pacote erlang-nox vem com o Erlang R14A (lançado em junho de 2010). O pacote backports vem com o Erlang R15B01 (lançado em abril de 2012). Para o Ubuntu LTS atual (Precise), erlang-nox vem com o Erlang R14B04 (lançado em outubro de 2011) enquanto que o último pacote do Raring - assim como o pacote do backports do Debian Squeeze - vem com o Erlang R15B01.

Esse post mostra como compilar a última versão do Erlang (R16B) no Debian Squeeze e como satisfazer a dependência erlang-nox do pacote DEB RabbitMQ.

Compilando o Erlang

O processo de compilação é muito simples, nós iremos basicamente seguir os passos disponíveis na documentação oficial do Erlang. Primeiro, instale algumas de suas dependências:

$ sudo aptitude install -y build-essential libssl-dev ncurses-dev m4

Explicando as dependências:

build-essential: lista de pacotes considerados essenciais para criar pacotes Debian. Alguns desses pacotes são necessários para compilar o Erlang, como o gcc e make
libssl-dev: necessários para suporte SSL
ncurses-dev: para melhor suporte no terminal
m4: necessário para compilar com suporte HiPE (High Performance Erlang)

Faça o download e compile o Erlang:

$ sudo mkdir -p /opt/src/erlang /opt/erlang
$ cd /opt/src/erlang
$ sudo curl -O http://www.erlang.org/download/otp_src_R16B.tar.gz
$ sudo tar xzvf otp_src_R16B.tar.gz
$ sudo mv otp_src_R16B r16b
$ cd r16b
$ sudo ./configure --prefix=/opt/erlang/r16b --enable-hipe --with-ssl
$ sudo make
$ sudo make install

Finalmente, crie os links simbólicos dos binários Erlang (se você não quiser usar links simbólicos, você pode executar configure com a opção --bindir=/usr/bin):

$ sudo ln -s /opt/erlang/r16b/bin/dialyzer /usr/bin
$ sudo ln -s /opt/erlang/r16b/bin/epmd /usr/bin
$ sudo ln -s /opt/erlang/r16b/bin/erl /usr/bin
$ sudo ln -s /opt/erlang/r16b/bin/erlc /usr/bin
$ sudo ln -s /opt/erlang/r16b/bin/run_erl /usr/bin
$ sudo ln -s /opt/erlang/r16b/bin/run_test /usr/bin
$ sudo ln -s /opt/erlang/r16b/bin/typer /usr/bin

Instalando o RabbitMQ

Faça o download do pacote DEB do RabbitMQ disponível no site do projeto:

$ cd /tmp && curl -O http://www.rabbitmq.com/releases/rabbitmq-server/v3.1.0/rabbitmq-server_3.1.0-1_all.deb

Como já discutimos, este pacote depende do pacote erlang-nox:

$ dpkg -I rabbitmq-server_3.1.0-1_all.deb
 Package: rabbitmq-server
 Version: 3.1.0-1
 Architecture: all
 Maintainer: RabbitMQ Team <packaging@rabbitmq.com>
 Installed-Size: 4460
 Depends: erlang-nox (>= 1:12.b.3) | esl-erlang, adduser, logrotate
 Section: net
 Priority: extra
 Homepage: http://www.rabbitmq.com/
 Description: AMQP server written in Erlang
  RabbitMQ is an implementation of AMQP, the emerging standard for high
  performance enterprise messaging. The RabbitMQ server is a robust and
  scalable implementation of an AMQP broker.

Se você tentar instalar o pacote usando o aptitude, o gerenciador de pacote irá instalar uma versão antiga do Erlang. A forma mais fácil de prevenir isso é usando o dpkg com a opção --ignore-depends:

$ sudo dpkg -i --ignore-depends=erlang-nox
(Reading database ... 42128 files and directories currently installed.)
Preparing to replace rabbitmq-server 3.1.0-1 (using rabbitmq-server_3.1.0-1_all.deb) ...
Unpacking replacement rabbitmq-server ...
Setting up rabbitmq-server (3.1.0-1) ...
Adding group `rabbitmq' (GID 107) ...
Done.
Adding system user `rabbitmq' (UID 105) ...
Adding new user `rabbitmq' (UID 105) with group `rabbitmq' ...
Not creating home directory `/var/lib/rabbitmq'.
Starting message broker: rabbitmq-server.
Processing triggers for man-db ...

Você pode verificar que o RabbitMQ está executando com o comando rabbitmqctl:

$ sudo rabbitmqctl status
Status of node rabbit@squeeze64 ...
[{pid,1776},
 {running_applications,[{rabbit,"RabbitMQ","3.1.0"},
                        {mnesia,"MNESIA  CXC 138 12","4.8"},
                        {os_mon,"CPO  CXC 138 46","2.2.11"},
                        {xmerl,"XML parser","1.3.3"},
                        {sasl,"SASL  CXC 138 11","2.3.1"},
                        {stdlib,"ERTS  CXC 138 10","1.19.1"},
                        {kernel,"ERTS  CXC 138 10","2.16.1"}]},
...

Resolvendo a dependência

O que fizemos quando instalamos o RabbitMQ foi simplesmente pedir para o dpkg ignorar a dependência durante o processo de instalação. O problema é que para o gerenciador de pacote, a dependência não foi satisfeita. Se você tentar instalar ou atualizar um pacote, o gerenciador de pacote irá sugerir a remoção do pacote rabbitmq-server por causa de sua dependência não satisfeita:

$ sudo aptitude install tree
The following NEW packages will be installed:
  tree
0 packages upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 32.4 kB of archives. After unpacking 98.3 kB will be used.
The following packages have unmet dependencies:
  rabbitmq-server: Depends: erlang-nox (>= 1:12.b.3) but it is not going to be installed. or
                            esl-erlang which is a virtual package.
The following actions will resolve these dependencies:

     Remove the following packages:
1)     rabbitmq-server

Accept this solution? [Y/n/q/?]

Se você não aceitar a solução, o aptitude irá sugerir a instalação de um monte de pacotes Erlang. Isto não é o que queremos, nós queremos ter o RabbitMQ instalado com a versão do Erlang que compilamos. Para resolver esta dependência, nós iremos criar um pacote “falso” usando equivs. Da documentação do equivs-build: “equivs-build é um programa que cria pacotes Debian aos quais podem ser usados para informar para o dpkg sobre pacotes instalados localmente e de suas dependências. Pacotes vazios que apenas requerem outros pacotes também podem ser criados com equivs. Estes podem ser usados como pacotes “perfis” aos quais apenas marcam outros pacotes para instalação”.

Antes de instalar o equivs, desinstale o RabbitMQ:

$ sudo aptitude purge -y rabbitmq-server

Então instale o equivs:

$ sudo aptitude install -y equivs

Crie um arquivo com o seguinte conteúdo:

Section: interpreters
Priority: optional
Standards-Version: 3.6.2

Package: erlang-nox
Version: 1:12.b.3
Maintainer: The Maintainer <maintainer@example.com>
Description: Dummy Erlang package.
  This package provides a dummy package for erlang-nox, a dependency of the rabbitmq-server package.

Ou apenas copie e cole os seguintes comandos:

$ erlang_nox="Section: interpreters
Priority: optional
Standards-Version: 3.6.2

Package: erlang-nox
Version: 1:12.b.3
Maintainer: The Maintainer <maintainer@example.com>
Description: Dummy Erlang package.
  This package provides a dummy package for erlang-nox, a dependency of rabbitmq-server package from RabbitMQ."
$ IFS='%'; echo $erlang_nox > erlang-nox; unset IFS

Então execute o comando equivs-build para criar o pacote DEB:

$ equivs-build erlang-nox
...
dpkg-deb: building package `erlang-nox' in `../erlang-nox_12.b.3_all.deb'.

The package has been created.
Attention, the package has been created in the current directory,
not in ".." as indicated by the message above!

Agora, instale o pacote DEB recém-criado e o pacote DEB do RabbitMQ:

$ sudo dpkg -i erlang-nox_12.b.3_all.deb rabbitmq-server_3.1.0-1_all.deb

Você pode verificar que o pacote “falso” foi instalado:

$ aptitude show erlang-nox
Package: erlang-nox
State: installed
Automatically installed: no
Version: 1:12.b.3
Priority: optional
Section: interpreters
Maintainer: The Maintainer <maintainer@example.com>
Uncompressed Size: 36.9 k
Description: Dummy Erlang package.
 This package provides a dummy package for erlang-nox, a dependency of rabbitmq-server package from RabbitMQ.

Agora você não precisa mais se preocupar com o aptitude reclamando sobre a dependência não satisfeita do pacote rabbitmq-server. Ao menos não quando for tentar instalar novos pacotes. Espere…

Marcando o pacote como mantido (held)

Tudo bem até que você tenta atualizar os pacotes do seu sistema e se depara com algo assim:

$ sudo aptitude safe-upgrade
Resolving dependencies...
The following NEW packages will be installed:
  erlang-asn1{a} erlang-base{a} erlang-corba{a} erlang-crypto{a} erlang-docbuilder{a} erlang-edoc{a} erlang-erl-docgen{a} erlang-eunit{a}
  erlang-ic{a} erlang-inets{a} erlang-inviso{a} erlang-mnesia{a} erlang-odbc{a} erlang-os-mon{a} erlang-parsetools{a} erlang-percept{a}
  erlang-public-key{a} erlang-runtime-tools{a} erlang-snmp{a} erlang-ssh{a} erlang-ssl{a} erlang-syntax-tools{a} erlang-tools{a} erlang-webtool{a}
  erlang-xmerl{a} libltdl7{a} libsctp1{a} lksctp-tools{a} odbcinst{a} odbcinst1debian2{a} unixodbc{a}
The following packages will be upgraded:
  erlang-nox
1 packages upgraded, 31 newly installed, 0 to remove and 0 not upgraded.
Need to get 20.8 MB of archives. After unpacking 36.5 MB will be used.
Do you want to continue? [Y/n/?]

Veja o arquivo erlang-nox que criamos anteriormente. Ele declara a versão como 1:12.b.3 enquanto a versão do pacote erlang-nox do Debian Squeeze é a 1:14.a-dfsg-3squeeze1. Se nós criássemos o pacote “falso” declarando uma versão mais recente, nós teríamos o mesmo problema se uma nova versão fosse lançada.

Para resolver isto, apenas marque o pacote como mantido com o aptitude:

$ sudo aptitude hold erlang-nox

aptitude show irá mostrar o pacote como instalado e mantido:

$ aptitude show erlang-nox
Package: erlang-nox
State: installed [held]
...

Agora você está livre das restrições de pacotes e usar a versão desejada do Erlang para executar não apenas o RabbitMQ mas qualquer aplicação Erlang!

Curso Desbravando o Symfony2 na PHP Conference Brasil 2012

Mon, 19 Nov 2012 06:30:00 -0200

No próximo dia 29 de novembro (quinta-feira) estarei na PHP Conference Brasil ministrando um curso sobre Symfony2. O curso tem um conteúdo básico para habilitar os alunos a desenvolverem aplicações básicas usando o framework e ter o conhecimento para descobrir as melhores bibliotecas desenvolvidas pela comunidade Symfony para tornar o trabalho de desenvolvimento mais produtivo e prazeroso.

Apesar de básico, o curso detalha bastante os conceitos do framework conforme destacados na grade:

Conhecendo o framework
- Arquitetura
- Componentes
- Bundles
- Distribuições
- Instalação
- Criando o primeiro bundle
- Criando a primeira página
Criando rotas e manipulando dados da requisição
- Definindo uma classe Controller
- Mapeamento de controllers e rotas
- Acessando dados da requisição ($_GET, $_POST, $_COOKIE)
- Acessando e gravando dados de sessão ($_SESSION)
- Redirecionamento de página
- Encaminhamento de ações
Configuração
- Os formatos XML, YAML e PHP
- Configuração global da aplicação
- Sobrescrevendo a configuração global via bundles
Formulários
- Formulários básicos
- Criando tipos de formulário customizados
- Validação
- Boas práticas para o processamento de formulários
Persistência
- Usando o ORM Doctrine2
- Mapeando uma entidade
- Recuperando e persistindo uma entidade de formulário
O container de serviços (DependencyInjection)
- Criando um serviço
- Consumindo um serviço
- Definindo dependências entre serviços

As inscrições vão até o dia 23/11 (veja valores e outras informações). Caso o curso de Symfony não lhe interesse, recomendo os cursos de MongoDB (do Jean “Suíssa” Carlo) e de Webservices RESTful (do Alex Piaz).

Criando boxes Vagrant customizados com o Veewee

Wed, 20 Jun 2012 08:50:00 -0300

Eu já falei um pouco sobre o Vagrant e sobre a filosofia DevOps. No post sobre Vagrant mostrei como usar um box Ubuntu publicamente disponível e quão fácil é usar um provisionador shell para configurar um box LAMP básico.

Então eu disse que existem boxes publicamente disponíveis mas omiti o site Vagrant boxes. Por que da omissão? Simplesmente eu não os acho tão úteis e acho que as desvantagens superam os benefícios. Pegar um box que você não sabe como foi coonfigurado por levar a sérios problemas de segurança. E se o box é apenas uma instalação básica, é quase sem real utilidade já que você precisará fazer o provisionamento da sua configuração desejada a cada vez que iniciar uma VM baseada no box.

E por que não criar um box base? Veewee ao resgate!

Veewee

O Veewee é uma ferramenta para criar boxes Vagrant e imagens KVM, VirtualBox e Fusion facilmente. Mãos a obra, vamos abrir um terminal. Você precisará ter o RubyGems instalado na sua máquina para instalar o Veewee. Leia o post sobre o Vagrant para ver como instalá-lo. Vamos instalar a última versão alpha disponível (observação: os seguintes comandos foram testados em um velho e bom MacOS X Leopard).

$ sudo gem install veewee --pre

Veewee vem com muitos templates de sistemas operations que você pode usar para criar seu box base Vagrant ou imagem de VM (e é por isso que usamos a última versão alpha já que contém templates atualizados para os principais sistemas operacionais). Você pode listar os templates disponíveis usando o seguinte comando:

$ vagrant basebox templates | sort

Existem templates para distros Linux populares (Debian, Ubuntu, CentOS, Scientific Linux), alguns sabores Unix (Solaris, FreeBSD) e até mesmo a preview release 8 do Windows. Vamos criar um box Debian. Primeiro, vamos definir o nosso box base com o nome ‘squeeze64-lamp’ usando o Debian 6.0.4 AMD64.

$ mkdir -p ~/Dev/veewee/squeeze/amd64
$ cd ~/Dev/veewee/squeeze/amd64
$ vagrant basebox define squeeze64-lamp Debian-6.0.4-amd64-netboot
[vagrant] The basebox 'squeeze64-lamp' has been succesfully created from the template 'Debian-6.0.4-amd64-netboot'
[vagrant] You can now edit the definition files stored in definitions/squeeze64-lamp or build the box with:
[vagrant] vagrant basebox build 'squeeze64-lamp'

Nós podemos ver alguns arquivos no diretório definitions/squeeze64-lamp que são usados para instalar o software necessário para um box base Vagrant:

$ ls definitions/squeeze64-lamp/
base.sh       cleanup-virtualbox.sh definition.rb      puppet.sh       vagrant.sh        zerodisk.sh
chef.sh       cleanup.sh            preseed.cfg        ruby.sh         virtualbox.sh

O principal arquivo aqui é o definition.rb. Ele tem um hash com algumas definições da VM VirtualBox (como o número de CPUs e tamanhos de memória e disco), definições de boot e do Kickstart - que são usadas para automatizar a instalação do sistema operacional - e os arquivos de pós-instalação. Vamos configurar o mesmo box LAMP do post sobre Vagrant. Faça o download ou clone o repositório Git vagrant-shell-scripts e altere os arquivos de pós-instalação em definitions.rb usando o seguinte trecho:

:postinstall_files => [
  "base.sh",
  "vagrant.sh",
  "virtualbox.sh",
  "ruby.sh",
  "puppet.sh",
  "chef.sh",
  "dotdeb.sh",
  "db-mysql.sh",
  "dev-tools.sh",
  "php5.sh",
  "php5-qa.sh",
  "php5-tools.sh",
  "drush.sh",
  "cleanup-virtualbox.sh",
  "cleanup.sh",
  "zerodisk.sh"
],

Dica: coloque seus arquivos de pós-instalação após o arquivo base.sh e antes do arquivo cleanup.sh.

Com tudo no lugar, cria seu box! Isto pode levar algum tempo já que será feito o download do Virtual Box Guest Additions e da imagem ISO do sistema operacional (mas apenas para a primeira vez).

$ vagrant basebox build squeeze64-lamp

Após criar o box, valide-o:

$ vagrant basebox validate squeeze64-lamp

Com os testes ok, exporte seu box:

$ vagrant basebox export squeeze64-lamp

Agora você tem um box base Vagrant customizado ao qual pode distribuir para o seu time de TI. Apenas adicione-o no Vagrant e comece a usá-lo!

$ vagrant box add squeeze64-lamp squeeze64-lamp.box
$ vagrant init squeeze64-lamp
$ vagrant up
$ vagrant ssh

Fuja do user space: usando Vagrant para configurar ambientes de desenvolvimento

Fri, 08 Jun 2012 06:50:00 -0300

A Brand New Day, por Thomas Hawk.

No post sobre DevOps, eu disse que o Vagrant é uma ferramenta útil que facilita a criação e configuração de ambientes virtualizados e faz com que a frase “funciona na minha máquina” seja uma desculpa do passado. Certamente o Vagrant é uma ferramenta que auxilia as equipes DevOps a assegurarem coerência nos ambientes. Mas você não precisa praticar DevOps para desfrutar dos benefícios.

Você sabe, como desenvolvedor, que é difícil manter seu ambiente de desenvolvimento atualizado quando se alterna entre diferentes projetos. Até mesmo ferramentas como rbenv e phpenv (que ajudam na coexistência de diferentes versões da mesma linguagem de programação em uma mesma máquina), ainda temos problemas quando precisamos usar versões diferentes de bancos de dados, servidores de aplicações e outros softwares que compõem a pilha de dependência dos diferentes projetos.

Então você começa a compilar diferentes versões de bancos de dados, criando scripts para iniciar/parar serviços de acordo com um projeto mas, com o passar do tempo, você termina com um ambiente tão bagunçado que a manutenção torna-se um pesadelo.

Outro problema é que você começa a sentir o user space cada vez menos responsivo com o passar do tempo. O startup da sua máquina fica mais lento, especialmente quando você tem um monte de software instalado como serviço. Se estiver usando um notebook na bateria, ela pode ser descarregada mais rapidamente.

Então você desenvolve usando Mac ou Windows. Aquele novo e impressionante projeto open source? Às vezes ele não tem (um bom) suporte. Quando se tem (usando ferramentas como MacPorts, Homebrew ou Cygwin) às vezes você ficar com uma versão mais antiga de um pacote.

Eu mesmo tive problemas como esses. Eu tenho um Mac. Nos últimos anos eu trabalhei em diversos projetos baseados em PHP e tive um monte de problemas para compilar o PHP com extensões que precisam de bibliotecas como PDFlib, ICU e libxml. Há um ano, eu decidi ajudar no desenvolvimento do framework Symfony2, especificamente no componente Locale.

O componente Locale do Symfony2 depende do ICU, uma vez que usa as classes da ext/intl do PHP. Mas Fabien Potencier e os desenvolvedores do core do Symfony haviam decidido que o framework não deveria depender de funcionalidades não-core do PHP para funcionar. Então, precisávamos desenvolver uma maneira de imitar os comportamentos das classes ext/intl em código user land. Então Igor Wiedler e eu decidimos na hora em criar os testes comparando os resultados de nossa implementação contra a implementação ext/intl.

Então eu precisava instalar algumas versões diferentes do PHP e do ICU para encontrar qual a versão mínima que iríamos nos basear para codificar nossa implementação (nós nos baseamos na versão 4.2). Eu não queria compilar todos os softwares na minha máquina (um Macbook com o velho, mas bom MacOS X Leopard). Eu estava pensando em voltar a usar alguma distro baseada em Debian como desktop.

Nada bate uma distribuição Linux (e seus vários gerenciadores de pacotes) quando se trata de usar projetos open source para desenvolvimento de software. Mas eu ainda preferia usar o Mac como ambiente desktop. Na época, eu já estava usando o VirtualBox para desenvolvimento e, então, eu descobri o Vagrant, que tornou minha vida muito mais fácil. Desde então, eu crio um ambiente virtualizado para cada projeto. Este post mostra a maneira que eu pessoalmente uso o Vagrant.

Talk is cheap. Vamos para a diversão!

Instalação e comandos básicos

Como o Vagrant cria máquinas virtuais VirtualBox, você obviamente irá precisar dele instalado (versão 4.0.x ou 4.1.x). Faça o download da versão mais recente do Vagrant, que tem instaladores para Windows e MacOS X e pacotes para Debian, RedHat e Arch Linux. Ou você pode instalá-lo usando Rubygems:

$ sudo gem install vagrant

Com o Vagrant instalado, você terá que adicionar um box. Um box é um pacote tar, que contém uma imagem de máquina virtual base. Comece adicionando um dos boxes oficiais do Vagrant:

$ vagrant box add lucid32 http://files.vagrantup.com/lucid32.box
$ vagrant box add lucid64 http://files.vagrantup.com/lucid64.box

Ao executar um dos comandos acima, o box escolhido será baixado do site do projeto Vagrant. O primeiro argumento do comando vagrant box add é o nome do box em seu ambiente Vagrant. Você vai usá-lo para especificar qual box que você deseja usar ao criar um ambiente virtualizado. Você pode listar os boxes disponíveis no seu ambiente Vagrant com o comando vagrant box list:

$ vagrant box list
lucid32
lucid64

Após terminar o download, crie o seu primeiro ambiente virtualizado usando Vagrant:

$ vagrant init lucid32
A `Vagrantfile` has been placed in this directory. You are now
ready to `vagrant up` your first virtual environment! Please read
the comments in the Vagrantfile as well as documentation on
`vagrantup.com` for more information on using Vagrant.

Vamos discutir o arquivo Vagrantfile no próximo tópico. Como a mensagem acima diz, basta executar o comando vagrant up:

$ vagrant up

Em seguida, faça o login na VM:

$ vagrant ssh
vagrant@lucid32:~$

O Vagrant automaticamente configura uma pasta VirtualBox compartilhada no caminho /vagrant para o diretório do Vagrantfile:

vagrant@lucid32:~$ ls /vagrant/
Vagrantfile

Depois que parar de usar o ambiente virtualizado, você pode suspendê-lo (pausá-lo) ou pará-lo (desligá-lo). Primeiro, faça o log off.

vagrant@lucid32:~$ exit
$ vagrant status
Current VM states:

default                  running

The VM is running. To stop this VM, you can run `vagrant halt` to
shut it down forcefully, or you can run `vagrant suspend` to simply
suspend the virtual machine. In either case, to restart it again,
simply run `vagrant up`.

Então execute o comando vagrant suspend ou vagrant halt:

$ vagrant suspend
[default] Saving VM state and suspending execution...
$ vagrant status
Current VM states:

default                  saved

To resume this VM, simply run `vagrant up`.
$ vagrant halt
[default] Discarding saved state of VM...
$ vagrant status
Current VM states:

default                  poweroff

The VM is powered off. To restart the VM, simply run `vagrant up`

O arquivo Vagrantfile

O Vagrantfile é onde todas as definições de uma VM estão. Você pode configurar qualquer definição da VM VirtualBox. Para configurar sua VM para usar 512 MB de RAM, defina o seguinte:

config.vm.customize [
  "modifyvm", :id,
  "--memory", "512",
  "--name",   "Meu primeiro box Vagrant"
]

Se você quiser usar outro box base, mude o valor de config.vm.box para o nome do box desejado:

config.vm.box = "lucid64"

Agora imagine que você está desenvolvendo uma aplicação web e que você quer deixar que seus amigos em uma mesma rede possa acessá-la. Você pode definir um IP estático para isso:

config.vm.network :hostonly, "192.168.33.11"

Como vimos antes, Vagrant automaticamente configura a VM para usar uma pasta VirtualBox compartilhada no caminho /vagrant. Enquanto as pastas compartilhadas do VirtualBox podem ser úteis, o seu desempenho degrada rapidamente enquanto o número de arquivos na pasta compartilhada aumenta. Eu recomendo usar NFS e ignorar as pastas compartilhadas completamente (você precisa definir a VM para usar um IP estático, como mostra o exemplo anterior):

# Caminho relativo
config.vm.share_folder("v-root", "/vagrant", ".", :nfs => true)

# Caminho absoluto
config.vm.share_folder("v-root", "/vagrant", "/Users/eriksencosta/Dev/my-project", :nfs => true)

Depois de alterar o seu Vagrantfile, você precisa reiniciar a VM para que as alterações entrem em vigor:

$ vagrant halt
$ vagrant up

Se estiver usando a pasta compartilhada NFS, será solicitado a você direitos de administrador, já que o Vagrant modifica o arquivo /etc/exports para configurar corretamente o servidor NFS na máquina host.

É o suporte a provisionadores que torna o Vagrant uma ferramenta muito útil. Até aqui, você viu como criar uma nova VM e alguma configuração básica, mas faltava alguma coisa. Para desenvolver uma aplicação, nós normalmente precisamos de outros softwares instalados como linguagens de programação, bancos de dados e afins. Mas o processo de instalação deve ser repetível e, mais importante, automatizado.

Vagrant suporta provisionamento usando Chef (Solo e Server), Puppet (Standalone e Server) e Shell. Seu suporte a Chef e Puppet é uma funcionalidade valiosa para aprender e testar Cookbooks Chef e Módulos Puppet. Para simplificar, vamos configurar um ambiente LAMP usando o provisionador Shell.

## Criando um ambiente LAMP usando o provisionador Shell

Vamos criar um ambiente LAMP. Nós iremos instalar o Apache, MySQL e PHP, disponíveis nos repositórios Ubuntu, algumas ferramentas de desenvolvimento genéricas (Git, Subversion), ferramentas PHP (Phing, compositor), ferramentas de QA PHP (PHPUnit, PDepend) e uma ferramenta específica para Drupal (Drush). Faça o download ou clone o repositório Git vagrant-shell-scripts. Em seguida, adicione o trecho ao seu Vagrantfile:

Vagrant::Config.run do |config|
  config.vm.provision :shell, :path => "/path/to/vagrant-shell-scripts/db-mysql.sh"
  config.vm.provision :shell, :path => "/path/to/vagrant-shell-scripts/dev-tools.sh"
  config.vm.provision :shell, :path => "/path/to/vagrant-shell-scripts/php5.sh"
  config.vm.provision :shell, :path => "/path/to/vagrant-shell-scripts/php5-qa.sh"
  config.vm.provision :shell, :path => "/path/to/vagrant-shell-scripts/php5-tools.sh"
  config.vm.provision :shell, :path => "/path/to/vagrant-shell-scripts/drush.sh"
end

Após salvar o arquivo, execute o comando vagrant up:

$ vagrant up

Vagrant irá mostrar-lhe o progresso do provisionamento. Ao concluir, você terá um ambiente totalmente configurado. Faça o login e tente executar o comando phpunit!

Nota: depois de desligar uma máquina que tem definições de provisionamento, rodar o comando vagrant up irá fazer com que o provisionamento seja executado novamente. Caso você não queira que isso ocorra, use a opção --no-provision:

$ vagrant up --no-provision

O Vagrantfile é o que torna o processo de criação de ambientes VM repetível. É a parte de infraestrutura como código do Vagrant. Adicione-o no repositório do seu projeto para compartilhá-lo com sua equipe, então cada desenvolvedor só irá precisar executar o comando vagrant up para usar o mesmo ambiente de trabalho.

E não se esqueça de ler a excelente documentação disponível no site do Vagrant!

DevOps, colocando a ponte entre desenvolvimento e operações

Thu, 24 May 2012 11:30:00 -0300

Onze anos após o Manifesto Ágil e muito mais anos de melhorias contínuas nas práticas de desenvolvimento de software resultaram em um grande impacto na nossa indústria. Práticas como Desenvolvimento Orientado a Testes (Test Driven Development, ou simplesmente, TDD) e Entrega Contínua (Continuous Delivery) permitiu que times de desenvolvedores desenvolvessem melhores softwares e de forma mais previsível. Mas ainda restava uma lacuna - entre operações e desenvolvedores - DevOps é a ponte que nos permite saltar essa lacuna.

Entra DevOps

DevOps é, de acordo com Stephen Nelson-Smith, um “movimento de pessoas que pensam que é hora de mudança para a indústria de TI - hora de parar com o desperdício de dinheiro, hora de começar a entregar software excelente e para construir sistemas que escalam e duram”.

O movimento tem raízes nos movimentos de Infraestrutura e Operações Ágeis que estavam aplicando as práticas de engenharia Ágeis para melhorar a Entrega Contínua. Estes movimentos foram uma resposta a um problema identificado, que era o fato de que as organizações que estavam desenvolvendo software com métodologias Ágeis caiam para uma metogologia waterfall (cascata) quando era hora de implantar o software desenvolvido.

Essa fronteira entre o processo waterfall é o que Andrew Shafer chama de círculo da felicidade e parede da confusão. Basicamente o time de desenvolvimento (desenvolvedores, testadores e product owners) ficam dentro deste círculo com feedbacks regulares entre as iterações e comunicação fácil. Mas a comunicação com pessoas de fora deste círculo é desastrada e isto trás uma série de problemas que afetam a entrega de valor.

Stephen também define quatro problemas que a nossa indústria de software lida hoje que o DevOps pode ajudar a eliminar ou mitigar: medo de mudanças, implantações arriscadas, “funciona no meu computador” e silo-ização¹. O medo da mudança leva a processos de gerenciamento burocráticos que faz com que qualquer mudança na aplicação (seja a introdução de uma nova funcionalidade ou uma correção de bug) leve um longo período tempo para ser concluída. Implantações arriscadas prejudicam especialmente os times de desenvolvimento e operações já que isso pode levar a implantações em horários calmos - muitas vezes na madrugada, ao qual pode queimar muita energia dos times - porque não há confiança no software a ser implantado.

Funciona no meu computador! é um cliché. Quem nunca presenciou um problema que ocorre em produção e que quando fora reportado aos desenvolvedores estes responderam: “funciona no meu computador!”? Não é incomum encontrar times de desenvolvimento usando diferentes sistemas operacionais e/ou o ambiente de dependências do software em versões diferentes do ambiente de produção. Isto pode levar a suposições enganosas baseadas nas diferentes funcionalidades disponíveis nas diferentes camadas que compõe a pilha de dependência do software - ao qual é especialmente evidente quando os desenvolvedores não conhecem a infraestrutura.

E o problema notório com times em silos diferentes é a cultura de “apontar o dedo” e a mentalidades “nós e eles”. O círculo da felicidade de Shafer é muito sobre este problema: os silos diferentes tem medo um do outro, eles colaboram e comunicam-se mal.

Mudanças culturais

DevOps é muito sobre mudança de cultura já que aplica muitas das lições aprendidas com as práticas de Desenvolvimento de Software Ágil. Uma das lições é sobre comunicação e colaboração. DevOps reduz as fronteiras entre desenvolvimento e operações ao construir um time multidisciplinar com pessoas que, como Stephen destaca, “sentem-se confortáveis com infraestrutura e configução, mas também felizes por arregaçar as mangas, escrever testes, debugar e entregar funcionalidades”.

Colocar desenvolvedores e operações juntos significa dar-lhes oportunidades para descobrirem melhores formas para entregar melhor software. Isso propaga a corrente de valor de negócio que é bem conhecida no círculo da felicidade para o time de operações, que começa a ser visto como parte da solução ao invés de apenas ser visto como responsável por manter os servidores 24x7. Isto preenche a lacuna que estava faltando nas metodologias Ágeis: faz com que operações fiquem em sincronia com o processo de desenvolvimento, alinhando os times de desenvolvimento e operações com um processo de negócio unificado.

Certamente não é fácil ir de um time de operações caixa preta para um time totalmente DevOps. É difícil encontrar pessoas com esta mentalidade multidisciplinar. Mas DevOps, como Mitchell Hashimoto diz, não é algo absoluto e sim uma escala. Você não precisa procurar ter um time onde os desenvolvedores fazem todas as operações, você precisa procurar a sua forma de fazer DevOps. É mais sobre identificar pessoas que podem ser as pontes entre desenvolvimento e operações, encorajando-as e dando-lhes autonomia para que elas o façam.

Citando Stephen novamente, DevOps “tem um tremendo impacto nos negócios. De repente o time técnico começa a tentar trabalhar como um só. Uma mentalidade de ‘todos a bordo’ emerge, com todas as pessoas técnicas sentindo-se capazes de ajudar em todas as áreas. As áreas tradicionalmente problemáticas de implantação e manutenção quando em produção tornam-se tratáveis - e os campos de batalhas chave dos desenvolvedores (‘o sysadmin construiu uma plataforma não confiável’) versus sysadmins (‘os desenvolvedores escreveram código não confiável’) começa a transformar-se em uma aproximação interdisciplinar para maximizar a confiabilidade em todas as áreas. Isto tem, claro, um efeito positivo no final - melhor confiabilidade e disponibilidade, clientes mais felizes, menor tempo de lançamento para o mercado, e mais tempo para focar a energia do time no negócio principal do que a desperdiçando em administração ou apagando incêndios” (ênfase minha).

Ferramentas

Além das mudanças culturais, DevOps é carregado de boas práticas Ágeis aplicadas na infraestrutura. Uma grande mudança é o conceito de infraestrutura em código. Com DevOps, tudo deve estar no controle de versão - da configuração de rede à configuração das aplicações. Não há DevOps sem controle de versão já que esta é a base para todas as outras práticas. Como software, a infraestrutura deve ser construída a partir do código-fonte e igualmente tratada como uma aplicação.

Construir do código-fonte significa ter serviços online a partir de um servidor “limpo” através de um processo automatizado. Os sistemas de gerenciamento de configuração são muito úteis aqui: eles colocam um sistema em um estado conhecido usando a configuração que fica disponível no controle de versão e ajudam a alcançar consistência no ambiente de TI. Ele possibilita que operações gerenciem o ciclo de vida dos servidores, provisionando novos servidores pelo objetivo de seus serviços, de forma semelhante a aplicação de templates, dando aos servidores responsabilidades como “Servidor de Banco de Dados”, “Servidor de Cache HTTP” ou “Servidor de Aplicação”.

Existem alguns sistemas de gerenciamento de configuração open source disponíveis, sendo o Puppet e o Chef os mais conhecidos. Você pode encontrar muitos casos de uso interessantes de ambos os sistemas. Tumblr (a popular plataforma de blog), por exemplo, usa Puppet para atualizar os computadores dos desenvolvedores. Travis CI (o serviço de Integração Contínua hospedado) usa Chef para construir as imagens dos workers de Integração Contínua que são responsáveis por executar os testes de dezenas de milhares de projetos open source.

Esse tipo de gerenciamento de servidores otimiza operações ao prevení-la de realizar a configuração manual dos servidores, o que leva a incosistência entre servidores com serviços semelhantes e previne a ocorrência do que Shafer chama de “Máquina Misteriosa” - um servidor que ninguém sabe o que executa e que todos tem medo de desligar. Outro aspecto importante desses sistemas é a idempotência - nesse contexto, a habilidade de aplicar o template² de configuração na mesma máquina várias vezes sem modificar o resultado final, que é a máquina configurada como descrito no template.

Outras ferramentas são igualmente úteis. Uma delas é o Vagrant³, que é uma ferramente que facilita a criação e configuração de ambientes virtualizados. Com o Vagrant você pode, por exemplo, criar uma máquina virtual com um ambiente o mais semelhante possível do ambiente de produção para ser distribuída no time. Esta é uma ferramenta realmente importante para fazer da frase “funciona no meu computador” uma desculpa do passado. O Vagrant também é usado como um sandbox para testar templates de sistemas de gerenciamento de configuração como Puppet ou Chef. Você também pode usar scripts shell para configurar o seu ambiente.

Os avanços das tecnologias de virtualização também possuem um papel importante para alcançar melhor qualidade e entrega de software. Aproveite a computação em nuvem quase ubíqua para rapidamente prover ambientes de desenvolvimento, teste, staging e produção tão semelhantes quanto possível para o seu time.

Mas, lembre-se, mais importante que as ferramentas é a criação da cultura. Crie um time com habilidades interfuncionais e envolva-o nas atividades de implantação. Faça da implantação uma atividade que tanto desenvolvedores e operações possam fazer facilmente e em qualquer hora. Como o código-fonte de seu projeto, faça da sua infraestrutura uma propriedade coletiva e encontre a sua maneira de fazer DevOps em passos de bebê⁴.

Silo-ização é um neologismo. O próprio termo usado por Stephen Nelson-Smith, siloisation parece ser um neologismo em inglês, já que existem poucas referências na web para a palavra (a grafia com z, siloization possui mais referências). Podemos definir como o resultado da separação de grupos de pessoas em diferentes silos, com pouca interação/colaboração entre os diferentes silos. ↩
Esta é apenas uma simplificação do que essas sistemas realmente provêem. Puppet possui Modules e Chef possui Cookbooks. Ambos (Puppet Templating, Chef Templates) usam templates como uma forma de substituir ou criar arquivos de configuração como descrito em um module ou cookbook. ↩
Como Puppet e Chef, Vagrant é escrito em Ruby. Python é outra linguagem de scripting que está sendo muito utilizada para escrever este tipo de ferramenta. Um conhecimento básico dessas linguagens pode ser muito útil, especialmente caso você planeje extender funcionalidade. ↩
Contexto e bom senso são sempre importantes. Eu realmente gosto da forma que o GitHub trabalha. Eles não usam nenhuma metodologia Ágil mas são extremamente bem sucedidos em sua Entrega Contínua. ↩