Agile DevOps

Quebrando os silos

Saiba como equipes multidisciplinares são essenciais para DevOps bem-sucedidos

Comments

Conteúdos da série:

Esse conteúdo é a parte # de # na série: Agile DevOps

Fique ligado em conteúdos adicionais dessa série.

Esse conteúdo é parte da série:Agile DevOps

Fique ligado em conteúdos adicionais dessa série.

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.

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.

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.)

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ãoDescription
Grandes painéis visíveisAs 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çãoAs equipes estão fisicamente próximas para aprimorar a comunicação.
Integração contínuaO software é desenvolvido (ambientes, aplicativos, etc.) com cada mudança.
Equipes multidisciplinaresEquipes de entrega de software compostas por especialistas de várias disciplinas, incluindo programadores, testadores, analistas e operações.
Especialistas com várias qualificaçõesReduz os silos de especialistas ao expandir os conjuntos de qualificações nas equipes multidisciplinares.
Implementações com scriptA implementação do software nos ambientes é completamente definida por scripts para que possa ser executada com um único comando.
Ambientes com scriptA 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 linhaTodos podem e devem parar o sistema de integração contínua quando necessário.
Todos os itens orientados por testeEscreva 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.

A morte do desenvolvimento de software do passado

Nesse artigo, você aprendeu que um dos segredos para o DevOps ser efetivo é a quebra dos silos e a criação de equipes multidisciplinares que podem implementar seu software na produção. Organizações que têm longos ciclos de intermediação e entrega irão se desenvolver ou se retirar dos negócios. Em grandes organizações, o desenvolvimento pode ser demorado e requer uma mudança na cultura organizacional.

No artigo final dessa série , você aprenderá como criar um painel do DevOps—uma visualização abrangente do estado do sistema de software para as equipes de desenvolvimento e operações monitorarem em tempo real.


Recursos para download


Temas relacionados


Comentários

Acesse ou registre-se para adicionar e acompanhar os comentários.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Rational, Software livre
ArticleID=936329
ArticleTitle=Agile DevOps: Quebrando os silos
publish-date=07082013