As pessoas em empresas que criam sistemas e produtos de software frequentemente me perguntam “Como mudamos nossa organização nem realmente mudá-la?”. Claro, elas não usam essas palavras de fato (pelo menos não todas as vezes), mas é essa a implicação. Elas desejam minimizar o esforço e o risco envolvido no release de software, mas percebem que isso exige mudanças (culturais e técnicas) em toda a organização e que nem sempre elas têm o poder ou influência para afetar.

Um obstáculo cultural que elas normalmente encontram é que equipes de operações e desenvolvimento tradicionais tendem a trabalhar em silos, limitando a quantidade de comunicação entre as equipes até os momentos de release do software. (E tal comunicação frequentemente é confinada em uma série de chamados em um sistema de acompanhamento de problema.) As empresas de software em crescimento devem se tornar mais colaborativas, caso contrário deixarão de existir. O segmento de mercado de software está mudando nessa direção—muito mais rapidamente do que algumas pessoas previram—como resultado da computação em nuvem, que fazem com que os recursos de computação sejam menos escassos e da demanda de negócios. As empresas que se desenvolverem tirarão as que não se desenvolverem dos negócios.

Como enfatizado artigo introdutório dessa série , a colaboração além dos limites organizacionais é uma das âncoras do agile DevOps. Esse artigo discute como o estabelecimento de equipes multidisciplinares e a ampliação dos conjuntos de qualificações dos membros da equipe de entrega são formas de aumentar a colaboração e transpor as barreiras tradicionais que impedem que os softwares sejam entregues continuamente.

O crescimento das equipes multidisciplinares

O equipe multidisciplinar consiste em especialistas em todo o ciclo de fornecimento de software, como engenheiros de operações, administradores de banco de dado (DBAs), testadores e analistas. Todos em uma equipe multidisciplinar contribuem com código para um repositório de controle de versão. Por exemplo, o engenheiro de operações contribui com a configuração e infraestrutura como um código, o DBA contribui com Linguagem de Definição de Dados (DDL), Linguagem de Modelagem de Dados (DML) e conjuntos de dados como código, o desenvolvedor contribui com configuração e código de aplicativo e os testadores contribuem com códigos como código.

Todos os membros de uma equipe multidisciplinar são responsáveis pelo processo de entrega. Qualquer pessoa na equipe pode modificar qualquer parte do sistema de software. O antipadrão correspondente são as equipes isoladas, que no desenvolvimento, teste e operações têm seus próprios scripts e processos e não fazem parte da mesma equipe.

Então, as equipes multidisciplinares consistem em indivíduos de todas as disciplinas responsáveis pelo desenvolvimento e entrega de sistemas de software. Em vez de tratar cada disciplina como uma organização de serviço centralizada separada, a equipe de entrega se torna o constructo organizacional chave. As equipes trabalham em conjunto de uma forma dedicada para entregar o software de forma consistente, sem os impedimentos de tempo inerentes de quando as equipes se comunicam através da organização. Considere a composição de cada equipe por (pelo menos) analistas de negócios, representantes de serviços, DBAs, desenvolvedores, gerentes de projeto e controle de qualidade (QA) e engenheiros de liberação. Com uma equipe multidisciplinar, a síndrome do “não é meu trabalho” e outras “paredes” que reprimem a comunicação entre as equipes dentro e através de locais físicos são reduzidas.

A função dos especialistas

Para as novas equipes multidisciplinares compostas por pessoas acostumadas a trabalhar em organizações baseadas em serviços matriciadas, pode demorar um pouco para elas se familiarizarem com trabalhar em uma equipe multidisciplinar. Normalmente, os conjuntos de qualificações das pessoas na equipe são mais limitados e precisam ser expandidos. Nesse contexto, nos projetos piloto iniciais, os especialistas na organização (por exemplo, especialistas em segurança) devem ser trazidos para aconselhar os membros da equipe multidisciplinar. Os consultores não fazem parte da equipe multidisciplinar e eles não contribuem com testes ou códigos. Seu objetivo é expandir o conjunto de qualificações dos membros da equipe multidisciplinar. Conforme ele é expandido, a equipe irá recorrer menos aos consultores.

Todos fazendo tudo

Após um período, será possível perceber que os conjuntos de qualificação frequentemente mudam para engenheiros/analistas mais completos que começam a realizar mais do que apenas uma parte do processo de entrega de software. Por exemplo, um programa pode criar scripts de DDL e DML. Ou os analistas de negócios definem seus requisitos em scripts de aceitação de teste (como Cucumber) para que todas as mudanças sejam feitas através de testes automatizados baseados nos requisitos do cliente. Cada membro da equipe sabe que precisa escrever testes, scripts, versões (consulte “Agile DevOps: Version everything“), e fazer com que tudo o que é feito seja parte de um sistema contínuo (consulte “Agile DevOps: Continuous delivery platform“). Esse é o caso para todos os artefatos de origem: código do aplicativo, configuração, infraestrutura e dados. Quando os membros da equipe se tornam multiqualificados e os silos são desmanchados, a comunicação é melhorada e os gargalos são removidos das organizações de software do passado.

O processo

Tudo o que compõe o sistema de software completo é um script (isto é, um programa) ou um teste automatizado. Todos esses componentes do sistema de software são identificados com a versão e tudo é incorporado em um pipeline de entrega contínua. Dessa forma, quando qualquer material com que qualquer membro contribuir for verificado no repositório de controle de versão, é criado o sistema de software completo,—incluindo ambientes, banco(s) de dado(s) e o serviço/aplicativo de software usando a configuração com versão. Todos os componentes do sistema são identificados com versão, sem exceção. Os membros da equipe multidisciplinar são 100% dedicados ao projeto e não são afiliados a nenhum outro projeto. Essa abordagem aumenta a comunicação e reduz quaisquer gargalos do processo.

Como funciona?

Realizar a mudança cultural em uma organização é o elemento mais essencial da implementação do DevOps. Nada significativo irá acontecer a menos que isso seja realizado. Essa seção discute uma abordagem de alto nível da execução da transição para —e funcionando efetivamente com—equipes multidisciplinares.

Projetos piloto

As tentativas de mudar uma grande organização de uma só vez quase sempre tem a garantia de falharem. A abordagem preferencial é começar com um pequeno projeto piloto que forneça algo de valor de negócios para a produção em um período de tempo relativamente curto—de maneira ideal, não mais de 90 dias. O projeto piloto deve ser algo estratégico—não um aplicativo que raramente é atualizado e proporciona um valor de negócios mínimo. Essa nova equipe será uma equipe multidisciplinar e todos os membros estarão completamente dedicados ao projeto. (Eles não trabalharão em outros projetos.) Todas as funções necessárias para o desenvolvimento do sistema de software (operações desenvolvedores de aplicativos, bancos de dados, testadores, etc.) serão uma parte dessa equipe multidisciplinar.

Após ter comprovado o sucesso com um projeto, é possível escalar para mais alguns. Esses outros projetos terão membros de equipe do primeiro projeto piloto que irão compartilhar seu conhecimento e cada um será um membro integral da nova equipe. Após esses projetos serem bem sucedidos, as equipes piloto subsequentes serão duplicadas ou triplicadas até todos os projetos estratégicos estarem operando no novo modelo.

Arquiteturas orientadas a serviços

Para trabalhar em pequenas equipes que se comunicam efetivamente, é necessário desmontar as arquiteturas monolíticas. Arquiteturas que têm muitos outros sistemas dependentes fortemente acoplados são sensíveis e fazem com que a mudança seja extremamente difícil. Isso não significa que não estão sendo desenvolvidos grandes sistemas, significa que esses sistemas são fracamente acoplados como serviços que se comunicam através de um protocolo simples.

Responsabilidades centralizadas

Em virtude de todas as equipes de serviço serem pequenas (no máximo 10 pessoas) e independentes, pode-se imaginar quais funções organizacionais são centralizadas. Embora cada organização seja diferente, com equipes que utilizam o DevOps e os princípios de entrega contínua, as funções centralizadas são aquelas desenvolvem os serviços de plataforma usados pelo restante da equipe de entrega de software ou aquelas que realizam o monitoramento do sistema (aplicativo, rede, segurança, etc.). Pode haver coordenadores de release, governança e gerenciamento também, mas nenhuma dessas equipes centralizadas deve realizar atividades que somem ao tempo de espera das equipes multidisciplinares (em outras palavras, os serviços que as equipes centralizadas fornecem são completamente de autoatendimento). Frequentemente, nessas organizações, as equipes de entrega de serviço (de programadores, operações, banco de dados, testadores, etc.) estão de plantão (normalmente isso alterna entre os membros da equipe) e são responsáveis por corrigir problemas de produção.

Sistemas de autoatendimento

Uma das principais características do DevOps é que um membro da equipe nunca deve precisar de outro membro fora de sua equipe multidisciplinar para executar uma atividade como parte do processo de entrega. Tudo deve ser nos moles de autoatendimento. Qualquer membro da equipe deve poder entregar software para a produção (consulte a barra lateral “Você desenvolve, você executa! “). Quando os membros da equipe estão projetando qualquer recurso em um sistema de entrega de software, eles precisam considerar como desenvolver isso de forma que possa ser usado sem os tempos de espera de pipeline de entrega envolvendo o envio de chamados, envio de email ou o uso de quaisquer outros mecanismos de comunicação. (Essas ferramentas frequentemente ainda são usadas com equipes que adotam o DevOps e a Entrega Contínua. Mas no contexto do pipeline de entrega, elas são automatizadas.)

Você desenvolve, você executa!

Quando os sistemas de entrega de software são desenvolvidos de forma que apenas as mudanças automatizadas executam a entrega do software, qualquer pessoa na equipe (de no máximo de 8 a 10 membros) pode implementar as mudanças na produção (ou em qualquer outro ambiente). Como um desenvolvedor (ou código de infraestrutura, código do aplicativo, scripts de analista ou qualquer outra coisa) o cliente final é o usuário real—não uma equipe de operações tradicional—o que encoraja loops de feedback muito rápidos.

Padrões

Com o princípio universal sendo mover todos os serviços internos para os modelos de autoatendimento , determinados padrões específicos que se aplicam são abordados de uma forma ou de outra nessa série até o momento. Os padrões mais essenciais entre eles são descritos na Tabela 1.

Tabela 1. Padrões principais que suportam o trabalho do DevOps 

Padrão	Descrição
Grandes painéis visíveis	As equipes em toda a organização obtêm informações em tempo real sobre o estado do sistema de software, incluindo status de desenvolvimento, métricas do cliente e disponibilidade.
Colocação	As equipes estão fisicamente próximas para aprimorar a comunicação.
Integração contínua	O software é desenvolvido (ambientes, aplicativos, etc.) com cada mudança.
Equipes multidisciplinares	Equipes de entrega de software compostas por especialistas de várias disciplinas, incluindo programadores, testadores, analistas e operações.
Especialistas com várias qualificações	Reduz os silos de especialistas ao expandir os conjuntos de qualificações nas equipes multidisciplinares.
Implementações com script	A implementação do software nos ambientes é completamente definida por scripts para que possa ser executada com um único comando.
Ambientes com script	A criação de ambientes é completamente definida por scripts para que possa ser executada com um único comando.
Releases de autoatendimento (“Você desenvolve, você executa.”)	Qualquer pessoa autorizada na equipe pode e executa implementações para a produção.
Parar a linha	Todos podem e devem parar o sistema de integração contínua quando necessário.
Todos os itens orientados por teste	Escreva testes automatizados para tudo: aplicativos, infraestrutura, tudo. Isso deve incluir escrita da unidade, a aceitação, o carregamento e os testes de desempenho.
Indicação de versão de todos os itens	Indicação versão de todos os artefatos: infraestrutura, configuração, código do aplicativo e dados.

 

Aprender

 

• “How Netflix gets out of the way of innovation” (Adrian Cockcroft’s Blog, dezembro de 2011): Cockcroft discute como a cultura da Netflix afeta a inovação.
• “There’s No Such Thing as a ‘Devops Team’” (Jez Humble, continuousdelivery.com, outubro de 2012): Humble explica porque os silos funcionais e a segregação de funções são problemáticos.
• Andon: Saiba como um cabo andon é usado na manufatura lean. As equipes de software podem aplicar o mesmo conceito em “parar a linha”.
• “Continuous Delivery: Patterns and Antipatterns in the Software Lifecycle” (Paul Duvall, DZone, junho de 2011): Conheça mais de 40 padrões e antipadrões para a entrega contínua.
• “Amazon’s CTO: ‘Amazon is a technology company. We just happen to do retail’“: (Brad McCarty, The Next Web, outubro de 2011): Em um vídeo de apresentação integrado nesse artigo, o CTO da Amazon, Werner Vogels, discute a abordagem dos sistemas de software “Você desenvolve, você executa” de sua empresa.
• Fique por dentro dos developerWorks com ênfase em uma série de produtos IBM e tópicos do segmento de mercado de TI.
• Participe de um briefing ao vivo e gratuito do developerWorks Live! para se atualizar rapidamente sobre produtos e ferramentas IBM e tendências do segmento de mercado de TI.
• Siga o O developerWorks no Twitter.
• Acompanhe as Demos on demand do developerWorks que abrangem desde demos de instalação e configuração de produtos para iniciantes até funcionalidades avançadas para desenvolvedores experientes.

 

Obter produtos e tecnologias

 

• Avalie os produtos IBM da maneira que for melhor para você: faça download da versão de teste de um produto, avalie um produto on-line, use-o em um ambiente de nuvem ou passe algumas horas na Sandbox SOA aprendendo a implementar Arquitetura Orientada a Serviços de modo eficiente.

 

Discutir

 

• Participe da comunidade do developerWorks. Entre em contato com outros usuários do developerWorks, enquanto explora os blogs, fóruns, grupos e wikis orientados ao desenvolvedor.
• A comunidade Agile Transformation do developerWorks fornece notícias, discussões e treinamento para ajudar você e sua organização a desenvolverem uma base fundamentada em princípios de desenvolvimento agile.

Sobre o Autor

Paul Duvall é CTO do Stelligent. Palestrante presente em muitas das principais conferências de software, desempenhou praticamente todas as funções em projetos de software: desenvolvedor, gerente de projeto, arquiteto e testador. É o principal autor de Continuous Integration: Improving Software Quality and Reducing Risk(Addison-Wesley, 2007) e Vencedor do Jolt Award de 2008. Ele também é autor de Startup@Cloud e DevOps in the Cloud LiveLessons (Pearson Education, junho de 2012). Ele contribuiu em diversos outros livros também. Paul é autor da série de 20 artigos Automation for the people no developerWorks. Sua paixão é oferecer software de alta qualidade para os usuários mais rápido e com maior frequência através da entrega contínua e de nuvem. Leia seu blog em Stelligent.com.