Agile DevOps: O Achatamento do Processo de Release de Software

Como o DevOps está transformando a entrega de software

O que significa "achatar" o processo de release de software? Como isso afetará a sua estrutura organizacional? Na primeira parte da série Agile DevOps , Paul Duvall, especialista em DevOps, descreve como os desenvolvedores e as operações estão trabalhando juntos nas equipes de entrega de software para aperfeiçoar o processo de desenvolver e liberar software. Ele fala de tópicos nascentes, como infraestruturas acionadas por testes, ambientes temporários e o Chaos Monkey — e de como todas essas técnicas trabalham em conjunto para alcançar o objetivo de oferecer software aos usuários de forma mais rápida e frequente.

Paul Duvall, CTO, Stelligent

Paul DuvallPaul Duvall é CTO da Stelligent. Paul e conferencista em várias das principais conferências de software. Desempenhou praticamente todas as funções em projetos de software: desenvolvedor, gerente de projetos, arquiteto e testador. É o principal autor de Continuous Integration: Improving Software Quality and Reducing Risk (Addison-Wesley, 2007) e ganhador do plano Jolt de 2008. . Também é autor de Startup@Cloud e DevOps in the Cloud LiveLessons (Pearson Education, junho de 2012). Além disso, contribuiu em vários outros livros. Paul escreveu a série de 20 artigos Automation for the people do developerWorks. A sua paixão é oferecer software de alta qualidade para os usuários de forma mais rápida e frequente, por meio da entrega contínua e da nuvem. Leia o blog dele em Stelligent.com.



17/Set/2012

Sobre esta série

Os desenvolvedores podem aprender muito com as operações — e vice-versa. Essa série de artigos se destina a explorar os usos práticos da aplicação da mentalidade de operações ao desenvolvimento e vice-versa — e a considerar os produtos de software como entidades holísticas que podem ser entregues de forma mais ágil e frequente do que nunca.

Quando se trata de entregar software para os usuários, o desenvolvimento Agile ainda não cumpriu algumas de suas promessas em muitas organizações. Isso acontece por vários motivos, mas o problema central é o desalinhamento da estrutura organizacional. Muitas vezes, as equipes de desenvolvimento e operações das empresas estão em unidades corporativas separadas, tendo em comum apenas um executivo — o CEO, que geralmente confia que os executivos subordinados tomarão as decisões corretas. Os objetivos das duas equipes estão inerentemente em conflito. O desenvolvimento é medido pelo número de recursos que ele coloca à disposição da empresa, ao passo que as operações são medidas pelo tempo de atividade — sua estabilidade. Como essas empresas não têm uma visão coesa do sistema de software, nenhuma das equipes é incentivada adequadamente para alcançar o objetivo de entregar regularmente recursos de alta qualidade que executam em um ambiente estável.

O livro de Thomas Friedman publicado em 2005, The World is Flat afirma que fatores como globalização, software, a Internet e a abertura das fronteiras de certos países em desenvolvimento estão convergindo para "achatar" as barreiras tradicionais à participação na economia mundial. Agora o segmento de mercado de software está vivendo a sua própria tendência de "achatamento" dentro das empresas que buscam a vantagem competitiva: o achatamento dos releases de software e das estruturas organizacionais. Essa transformação — possibilitada por uma convergência de automação, ferramentas, colaboração e melhores práticas e padrões do segmento de mercado — está tornando a entrega de software nessas empresas mais rápida, melhor e mais barata.

Nesta série, mostrarei como os sistemas de software podem ser considerados de forma mais holística e as organizações de software devem ser achatadas para alcançar o objetivo da entrega regular de recursos estáveis. Este artigo apresenta muitos dos tópicos que serão abordados ao longo da série, como Agile, DevOps, padrões emergentes do segmento de mercado, ferramentas e colaboração. Tudo isso contribui para alcançar esse objetivo.

Participe

A comunidade Agile Transformation do developerWorks fornece notícias, discussões e treinamento para ajudar você e a sua organização a desenvolver uma base fundamentada em princípios agile.

Agile + DevOps

Três dos 12 princípios do Agile Manifesto (consulte Recursos) enfatizam as práticas de entrega de software:

  • "Nossa prioridade mais alta é satisfazer o cliente por meio da entrega precoce e contínua de software de valor."
  • "Entregar software funcional com frequência, de duas semanas a dois meses, dando preferência à escala de tempo mais curta."
  • "O software funcional é a principal medida do progresso."

O Manifesto foi escrito há mais de dez anos, e muitas organizações ainda buscam seguir esses princípios. Entretanto, o interessante é que outras organizações estão excedendo esses princípios. Em algumas empresas, o software está sempre pronto para o release e não há paredes ou silos entre as equipes: elas têm uma equipe de entrega — formada por especialistas em desenvolvimento, QA, banco de dados, operações, etc. — que entrega software de valor continuamente aos usuários. Esse é o significado da agilidade.

Em seu cerne, a motivação que leva ao movimento DevOps é a frustração de liberar e manter sistemas de software com várias equipes. Em um projeto de software típico — em termos gerais — duas equipes são responsáveis por desenvolver e entregar software: desenvolvimento e operações. As duas equipes devem colaborar, mas frequentemente têm motivações conflitantes. Para o desenvolvimento, trata-se de entregar novos recursos. Para as operações, trata-se de garantir a estabilidade dos sistemas. Frequentemente, há problemas de comunicação entre as equipes, que levam a falhas em um momento posterior do processo de entrega de software.

Um dos objetivos do movimento DevOps é fazer com que os desenvolvedores e o pessoal de operações trabalhem juntos de forma mais colaborativa. Consequentemente, um novo tipo de engenheiros de DevOps está surgindo, para usar o melhor das duas disciplinas e combiná-las para entregar valor para os usuários. Isso também está se manifestando no surgimento de equipes multifuncionais com experiência em desenvolvimento, gerenciamento de configuração, bancos de dados, teste e infraestrutura.


Padrões

O padrão de software é a solução de um problema em um determinado contexto (o contexto é o segredo para distinguir os padrões das "melhores práticas"). Alguns dos padrões relacionados ao Agile DevOps são ambientes com script, infraestruturas acionadas por teste, Chaos Monkey, controle de versões de tudo, pipeline de entrega e painel do DevOps. Eu apresento esses padrões neste artigo, e você verá mais detalhes sobre isso à medida que a série progride.

Ambientes com script

Automatizando totalmente o fornecimento de ambiente, você reduz os riscos de erros de implementação em um ambiente que não ocorrem em outros ambientes. Ao utilizar scripts nos ambiente, você verifica a integridade de uma versão específica do software (ou seja, certifica-se de que nada tenha sido modificado) nos ambientes de destino. Ao seguir a política de que nada é modificado em um ambiente a menos que esteja em um script com versão, automatizado e faça parte de um caminho único para a produção, é possível determinar melhor a causa raiz dos erros de implementação. Os benefícios dos ambientes com script são:

  • Os ambientes sempre estão em um estado conhecido.
  • Permitem ambientes e implementações com autoatendimento.
  • Diminuem a possibilidade de que as implementações se comportem de forma diferente com base em tipos exclusivos de ambiente.
  • Os ambientes fazem parte de um único caminho (e versão) para a produção.
  • Diminuem a possibilidade de que o conhecimento fique bloqueado na cabeça dos membros da equipe.
  • As implementações são mais previsíveis e repetidas.

As ferramentas de automação da infraestrutura, sobre as quais você saberá mais nesta série, suportam esse padrão. O Puppet é uma ferramenta desse tipo. O fragmento de código da Listagem 1 exemplifica um programa básico do Puppet — conhecido como um manifesto:

Lista 1. Ambientes com script: fragmento de httpd do manifesto do Puppet
class httpd {
  package { 'httpd-devel':
    ensure => installed,
  }
  service { 'httpd':
    ensure => running,
    enable => true,
    subscribe => Package['httpd-devel'],
  }
}

Tipicamente, vários manifestos foram o script de uma infraestrutura. Esses scripts são armazenados em um repositório de controle de versão, da mesma forma que o código do aplicativo.

Infraestruturas acionadas por teste

Uma premissa simples do DevOps é a aplicação de melhores práticas e padrões do desenvolvimento para as operações e vice-versa. A abordagem acionada por testes adotada para escrever testes juntamente com o código tem as suas origens no desenvolvimento de software. À medida que as ferramentas de automação da infraestrutura se tornam mais comuns nas organizações, os engenheiros estão aplicando práticas acionadas por testes à infraestrutura; a infraestrutura é descrita em um script (como você viu na Listagem 1), e esses scripts têm testes. Estes são alguns dos muitos benefícios das infraestruturas acionadas por testes:

  • Os problemas se manifestam antes, porque as mudanças na infraestrutura são integradas ao restante do sistema de software por meio de um sistema de integração contínua.
  • Os testes — e a infraestrutura com script — se tornam a documentação.
  • Dessa forma, é possível isolar melhor as mudanças destrutivas, já que tudo é um script e está descrito em testes.

A Listagem 2 ilustra um cenário simples para se certificar de que um servidor da web esteja funcionando. O cenário usa uma ferramenta de desenvolvimento acionado pelo comportamento (também conhecido como desenvolvimento acionado por teste de aceitação) chamada Cucumber, na qual os testes são descritos como cenários.

Lista 2. Teste de infraestrutura no Cucumber
Scenario: Is the proper version of Apache installed?
When I run "/usr/sbin/httpd -v"
Then I should see "2.2"

Você verá mais exemplos de infraestrutura acionada por teste em artigos futuros desta série.

Chaos Monkey

Há dois anos, a equipe técnica da Netflix desenvolveu uma ferramenta de teste contínuo chamada Chaos Monkey. A ferramenta finaliza instâncias na infraestrutura de produção da Netflix de forma intencional e aleatória, mas regular, para garantir que os sistemas continuem operando em caso de falha. Essa ferramenta foi liberada recentemente como software livre (consulte Recursos).

O princípio que a Netflix segue é que "tudo falha o tempo todo" (um mantra criado por Werner Vogels, CTO da Amazon.com). Como a Netflix diz, "a tarefa do Chaos Monkey é derrubar instâncias e serviços aleatoriamente dentro da nossa arquitetura. Se não testamos constantemente a nossa capacidade de ser bem-sucedidos apesar das falhas, é provável que as coisas não funcionem nos momentos mais importantes — no caso de uma indisponibilidade inesperada" (consulte Recursos). Mais adiante nesta série, explorarei o Chaos Monkey e a sua função em um ambiente DevOps que funciona bem.

Ambientes temporários

A regra geral de um ambiente temporário é que os ambientes de autoatendimento proporcionados por membros da equipe de DevOps tem a duração mais curta possível, que varia de algumas horas a alguns dias — basicamente, só o tempo suficiente para executar os testes. Um dos problemas mais significativos dos projetos de desenvolvimento de software é o fato de as equipes terem instâncias corrigidas nas quais ninguém mais pode mexer, porque a sua configuração exigiu dias, semanas ou meses de trabalho de vários membros da equipe. Frequentemente, isso é o resultado de ambientes sem script, que transformam os ambientes em recursos escassos. As pessoas tendem a se apegar ao que é escasso e protegê-lo.

Quando você conta com ambientes com script, os ambientes não são escassos. Tudo é definido em um modelo e passa por um sistema de controle de versão. É possível finalizar os ambientes baseados nos scripts tantas vezes quantas forem necessárias. Esse padrão oferece duas vantagens: coloca os recursos à disposição de outras pessoas e reforça o conceito de que tudo deve ser automatizado — e não alimentado e cultivado manualmente por semanas e meses. Com esta série, você saberá mais sobre ambientes temporários.

Controle a versão de tudo

Esse padrão é simples e aparentemente óbvio: controle a versão de tudo. Sim, de tudo: infraestrutura, configuração, código do aplicativo e scripts de banco de dados. Embora isso seja simples de entender, em minha experiência, é raro encontrar equipes que controlem a versão de todos os artefatos necessários para criar o sistema de software.

O propósito de controlar a versão de tudo é estabelecer uma fonte única da verdade (também conhecida como versão canônica ou sistema de registro) para o sistema de software; o software é tratado como uma unidade holística. Quando se controla a versão de tudo, os membros da equipe não ficam continuamente sem entender as coisas claramente ou navegando em várias versões do sistema de software. Na série, também abordarei a prática emergente de controlar a versão de partes da própria configuração do sistema de entrega de software.

Há uma forma simples de saber se a versão de tudo está sendo controlada: um novo integrante da equipe que obtém uma nova máquina e realiza o check-out com um único comando a partir do controle da versão deve ser capaz de obter um sistema de software funcional completo a partir desse check-out.

Pipeline de entrega

Com um servidor de integração contínua como o Jenkins, também é possível configurar um pipeline de entrega. Basicamente, o pipeline de entrega é um processo no qual diversos tipos de tarefas são executadas com base no sucesso da tarefa anterior. Nesse pipeline, é possível configurar vários estágios, inclusive um estágio de confirmação, um estágio de aceitação, e assim sucessivamente. Cada estágio se baseia no sucesso do anterior. Essa abordagem garante a redução do risco do candidato ao release em cada estágio sucessivo até que o sistema de software seja liberado para a produção. Um exemplo de pipeline de entrega — da forma que é representado no Jenkins — é mostrado na Figura 1:

Figura 1. Pipeline de entrega tal como é representada no servidor de integração contínua Jenkins
Pipeline de entrega tal como é representada no servidor de integração contínua Jenkins

Painel do DevOps

Depois que a equipe multifuncional está focada na entrega de recursos e estabilidade, é muito importante que todos estejam por dentro dos assuntos — literal e figuradamente. O painel do DevOps mostra como cada mudança afeta o sistema inteiro em todos os estágios da progressão até a implementação na produção. Mais adiante na série, eu descreverei em detalhes um painel de software livre que fornece informações em tempo real sobre o sistema de software em desenvolvimento.


Colaboração

A colaboração é um dos pilares do DevOps. As equipes tradicionais de desenvolvimento e operações tendem a trabalhar em silos e limitar a comunicação entre equipes até o momento do release do software. Assegurar a propriedade coletiva, estabelecer equipes multifuncionais e ampliar os conjuntos de habilidades dos engenheiros são três formas de aumentar a colaboração e superar as barreiras tradicionais que impedem a entrega regular de software.

Propriedade coletiva

A propriedade coletiva é uma prática que remonta ao estabelecimento da programação radical (XP) e, de modo geral, às metodologias Agile. No entanto, no contexto da entrega contínua, enfatiza-se a garantia de que todos os tipos de arquivo de origem que formam um sistema de software estejam disponíveis para serem modificados por todos os membros autorizados da equipe . Isso inclui o código do aplicativo, a configuração, os dados e até mesmo a infraestrutura. Tudo tem um script e tudo pode ser modificado.

Equipes multifuncionais

Em uma equipe multifuncional, todos os membros são responsáveis pelo processo de entrega. Qualquer pessoa da equipe pode modificar qualquer parte do sistema de software. As equipes isoladas em silos constituem o antipadrão correspondente: o desenvolvimento, o teste e as operações têm seus próprios scripts e processos e não fazem parte da mesma equipe.

As equipes multifuncionais são formadas por representantes de todas as disciplinas necessárias. Em vez de tratar cada disciplina como uma organização de serviços centralizada separada, a equipe de entrega se torna a principal construção organizacional. As equipes trabalham juntas de forma dedicada para entregar software consistentemente, sem as dificuldades que ocorrem quando as equipes se comunicam ao longo da organização. Considere a hipótese de formar cada equipe com (pelo menos) analistas de negócios, representantes do cliente, DBAs, desenvolvedores, gerentes de projetos e engenheiros de QA e release. Com uma equipe multifuncional, você reduz a síndrome do "isso não faz parte do meu trabalho" que prejudica a comunicação e os vários "muros" que impedem a comunicação, erguidos entre as equipes dentro de locais físicos e entre eles.

Engenheiros com várias qualificações

O engenheiro com várias qualificações é um membro da equipe qualificado em todas as áreas do processo de entrega de software. Os desenvolvedores devem saber alterar o banco de dados. Os administradores de banco de dados devem saber escrever testes funcionais. Os gerentes de projetos devem saber como incluir cenários em testes automatizados. Em geral, os membros da equipe continuam desempenhando funções condizentes com os seus cargos. (Por exemplo: de modo geral, os DBAs continuam focando os bancos de dados.) Entretanto, o compartilhamento do conhecimento reduz bastante as barreiras de comunicação introduzidas em organizações grandes e dispersas geograficamente. Também diminui a dependência em algumas pessoas-chave para liberar o software para os usuários.


Ferramentas

As ferramentas são um componente importante do Agile DevOps. As ferramentas que você escolhe para o projeto dependem dos seus requisitos específicos, mas é essencial que executem a partir da linha de comando. Isso é essencial porque convém que o pipeline execute no modo sem interface com o usuário com apenas um clique. (Se você tem uma ferramenta legada que não oferece a opção de linha de comando, é possível tentar raspar a tela para executar no modo sem interface com o usuário, mas essa não é a situação ideal e frequentemente requer manutenção regular.) A Tabela 1 apresenta uma lista de alguns tipos de ferramentas em um conjunto de ferramentas típicas do DevOps; concentre-se mais nos tipos de ferramentas que em seus nomes:

Tablela 1. Ferramentas que suportam o trabalho de DevOps
Tipo de ferramentaFerramentas
Automação da infraestruturaBcfg2, CFEngine, Chef, CloudFormation, IBM Tivoli, Puppet
Automação da implementaçãoCapistrano, ControlTier, Func, Glu, RunDeck
Infraestrutura como serviçoAmazon Web Services, CloudStack, IBM SmartCloud, OpenStack, Rackspace
Automação do desenvolvimentoAnt, Maven, Rake, Gradle
Automação dos testesJUnit, Selenium, Cucumber, easyb
Controle de versãoSubversion, Git, IBM Rational ClearCase
Integração contínuaJenkins, CruiseControl, IBM Rational BuildForge

Lembre-se de que a lista da Tabela 1 é ilustrativa, e não completa (consulte Recursos para ver uma lista mais detalhada de ferramentas).


Caminhos mais suaves para a entrega de software no futuro

O achatamento de releases de software e das organizações torna-se possível por meio do Agile DevOps. Neste artigo, descrevi o estado do Agile, o que é o DevOps e como os desenvolvedores e as operações podem trabalhar de forma mais colaborativa para entregar recursos em ambientes estáveis com maior frequência. Apresentei alguns padrões emergentes do DevOps, que serão descritos mais detalhadamente em artigos futuros da série. Finalmente, forneci uma lista de algumas ferramentas que suportam a entrega de software no estilo Agile DevOps.

No próximo artigo, você saberá mais sobre as ferramentas de automação da infraestrutura que suportam o padrão de ambientes com script. Eu irei abordar as principais ferramentas de software livre para automação da infraestrutura: Chef e Puppet.

Recursos

Aprender

Obter produtos e tecnologias

  • Chaos Monkey: o Chaos Monkey é o primeiro release de software do "Exército Símio" da Netflix.
  • 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 online, use-o em um ambiente de nuvem ou passe algumas horas na SOA Sandbox 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 a sua organização a desenvolver uma base fundamentada em princípios agile.

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Tecnologia Java
ArticleID=834837
ArticleTitle=Agile DevOps: O Achatamento do Processo de Release de Software
publish-date=09172012