Visão geral e plano de fundo

Este artigo descreve os desafios que surgem ao passar de uma implementação tradicional para uma usando os conceitos e técnicas emergentes de “DevOps” e as alterações necessárias para elas. O escopo deste artigo são as alterações necessárias na definição do artefato implementado, bem como as transformações organizacionais e culturais necessárias para aproveitar a abordagem DevOps.

O conceito geral do desenvolvimento agile é que uma organização deve entregar continuamente software funcional a um ritmo sustentável. Ao mesmo tempo, algumas novas ferramentas operacionais e componentes de infraestrutura ficaram disponíveis através dos movimentos relacionados de virtualização e computação em nuvem. Embora os métodos agile tenham sido prontamente adaptados por muitas equipes de desenvolvimento, os usuários geralmente não têm acesso aos softwares que eles produzem devido a processos de implementação cheios de lacunas, tarefas manuais suscetíveis a erros ou outros atrasos relacionados ao trabalho operacional.

Ao mesmo tempo, as pressões de um mercado cada vez mais competitivo estão fazendo com que líderes de negócios exijam um ciclo operacional menor para obter novos software e recursos nas mãos dos usuários e clientes. Esses três fatores – desenvolvimento agile, novas tecnologias operacionais e a exigência do mercado de responsividade nos negócios – estão fazendo com que as pessoas repensem como as organizações pensam sobre software de entrega.

O denominador comum entre as três tendências é que a velocidade da mudança diminuiu. Não é mais aceitável que novos recursos de software exigidos por usuários corporativos fiquem na prateleira por meses, esperando um grande evento de implementação. O software tem valor apenas quando está em uso, e obter esse valor rapidamente é mais crítico do que nunca no mercado de trabalho atual. Essa mudança está fazendo as pessoas questionarem as ideias sobre como organizações entregam software, e as respostas a esses desafios foram chamadas de movimento “DevOps”.

Para entender a entrega de software em geral, e a implementação em particular, sob uma abordagem DevOps, é importante entender duas outras coisas:

• Primeiro, é essencial entender, de forma clara e consistente, DevOps e por que ele é interessante para várias partes interessadas.
• Segundo, é importante entender como as suposições sobre implementação mudam ao tentar aplicar abordagens DevOps.

Quando entendemos esses itens, é possível olhar uma estrutura para executar implementações para apoiar uma abordagem DevOps.

Entendendo a abordagem DevOps e suas partes interessadas

O termo DevOps, derivado da combinação de desenvolvimento e operações de TI, geralmente refere-se a uma abordagem de unificar o trabalho em um sistema de software entre todas as disciplinas, para entregar mudanças ao sistema no ritmo de que os negócios precisam. Geralmente combina a abordagem agile de fazer mudanças rápidas e pequenas para garantir o foco no trabalho de maior valor, minimizar o risco de defeitos associados com mudanças grandes e minimizar a mudança de valor frequentemente associada com grandes lacunas entre um caso de negócios de software e a conclusão de um projeto. A visão de mundo de operações, por outro lado, é tratar a mudança como uma causa de instabilidade. A instabilidade pode, obviamente, levar a tempo de inatividade, que é a principal ocorrência negativa nas disciplinas de operações. Por isso, as organizações de operações geralmente resistem a mudanças.

No entanto, DevOps é geralmente visto como um movimento de mudança, pois, na maioria das organizações, desenvolvimento, operações e negócios têm uma série de comportamentos e recompensas em conflito, que levam a incontáveis problemas de comportamento. Os negócios recompensam o desenvolvimento por novos recursos e mudanças, mas penalizam operações pelo tempo de inatividade. Dessa forma, desenvolvimento empurra operações para mais implementações, e operações empurra desenvolvimento para mais estrutura e rigor nos artefatos entregues. Esses conflitos ficaram entranhados em muitas organizações e são acentuados por diferenças intrínsecas na maturidade das respectivas organizações. A abordagem DevOps procura eliminar essas barreiras, nivelar o campo de atuação entre os grupos concorrentes e fazer todos concentrarem-se em um objetivo em comum. Para fazer isso, é importante entender um pouco sobre a mentalidade de cada grupo.

Desenvolvimento

Desenvolvimento é visto como tendo avançado mais em seus esforços para tornar-se mais responsivo às necessidades de negócios. O Manifesto Agile já tem mais de 10 anos. O próprio manifesto é, em parte, o resultado de abordagens e experimentos anteriores de programação extrema e programação de pares. Para ser justo, a parte de software do quebra-cabeça era vista como um objetivo fácil de atingir – facilmente alterado e, teoricamente, isolado dos problemas da infraestrutura e plataforma. E infraestrutura tem sido tratada, tradicionalmente, como um gasto enorme de capital, com longos ciclos de amortização, muito mais difícil de alterar. Infelizmente, software sofisticado depende muito da infraestrutura e exige que ela evolua no mesmo ritmo que o próprio software. Essa conexão é o motivo pelo qual DevOps foi chamado de “Operações Agile” no começo.

Seja qual for o nome, a noção de manter software e infraestrutura separados não é sustentável se a tecnologia tiver que manter o ritmo com as necessidades de negócios. Isso está forçando o desenvolvimento a engajar-se mais nas necessidades para sustentar infraestruturas de software complexas em produção.

Operações

Felizmente, algumas novas tecnologias e técnicas surgiram em operações para ajudá-la a tornar-se mais responsiva. A principal tecnologia inovadora no reino das operações é a ampla disponibilidade de virtualização barata em hardware de mercadoria. Isso deu origem a novas abordagens de gerenciamento de sistemas e, é claro, à computação em nuvem. Essa tecnologia obteve popularidade porque proporcionava valor imediato ao permitir que organizações consolidassem, rápida e facilmente, seus recursos de cálculo subutilizados. Os analistas da Gartner estimam que 50% de todos os aplicativos são executados agora em ambientes virtuais.

A consolidação simples, no entanto, é apenas uma medida de corte de custos, com um índice finito de captura de valor. A tecnologia de virtualização também permite um nível de mutabilidade na infraestrutura que permite que as operações avancem-na sem afetar a estabilidade, em níveis que antes não eram possíveis. As técnicas usadas para explorar esses recursos de virtualização geralmente aparecem dentro das disciplinas relacionadas à computação em nuvem. Essas técnicas emergentes deram às operações uma maneira de ser tão ágeis quanto o desenvolvimento e de atender aos requisitos de responsividade dos negócios.

Negócios

Os negócios, por sua parte, descobriram que entender e explorar tecnologia é mais crítico do que nunca para obter resultados. De acordo com a Pesquisa de Opinião de CEOs 2012 da IBM, que se baseou em entrevistas com mais de 1.700 executivos chefes em 64 países, “fatores de tecnologia” são o principal fator que afeta organizações. Isso tem subido desde 2004, quando ocupada apenas a sexta posição dentre os nove fatores listados.

Portanto, os líderes de negócios perceberam que a capacidade de responder às necessidades de seus clientes é uma vantagem competitiva. A consequência, obviamente, é que a execução tecnológica precária representa uma ameaça intrínseca aos negócios. Essa não é uma percepção súbita, mas atingiu um ponto de mudança. A mesma pesquisa discutiu como os respondentes deram um peso igual (sete de dez) para entender o que clientes individuais queriam e ser capaz de responder a eles com prazos de lançamento no mercado menores. Em última instância, essa é a pressão de negócios colidindo com as realidades processuais de como as disciplinas técnicas de desenvolvimento e operações operaram no passado e estimularam a discussão de como fazer melhor.

DevOps e implementação

Atingir os ideais de DevOps representa várias alterações fundamentais de abordagem e comportamento para todos os três grupos.

Maior frequência

Um dos aspectos mais óbvios de atingir esses ideais é a suposição de que colocar novos recursos de software nas mãos dos usuários é o que torna as alterações de software valiosas. Essa suposição implica que entregar os novos recursos mais cedo é melhor, pois significa que o valor dos novos recursos é obtido mais cedo. A maioria das organizações, no entanto, têm historicamente sido orientadas para entregar grandes implementações em intervalos muito irregulares.

É a suposição de um intervalo curto, ou alta frequência de entrega, que está na raiz da transformação na definição de implementação. DevOps livra-se da noção de que processos de implementação são coisas usadas algumas vezes no ano para mover releases enormes e a substitui com a noção de um sistema de entrega que está sempre ativo e é bom em implementar um grande número de pequenas coisas consistentemente. O segredo é substituir ‘. Sistemas tradicionais orientados a grandes implementações são geralmente pesados demais para mover rápido o suficiente para suportar um ambiente DevOps. Tentativas de “fazer do jeito antigo, porém mais rápido” geralmente fracassam, pois as suposições que foram usadas para criar o jeito antigo nunca se destinaram a apoiar uma alta frequência de atividade. Isso não é “bom” ou “mau”. É apenas uma realidade da engenharia com a qual precisamos lidar.

Dado que esse novo processo de entrega tornar-se uma parte intrínseca para obter valor do investimento na alteração de software, ele torna-se uma parte estendida do sistema geral. Torna-se a rota principal para o valor do investimento em desenvolvimento. Isso traz a suposição de que gerenciar a eficiência e eficácia do processo de entrega tem valor de negócios direto e quantificável associado ao sistema como um todo. Está implícito nessa suposição o fato de que não é aceitável ignorar o custo de sustentar o recurso de entrega em si.

Perspectiva do sistema inteiro

Outro marco da implementação DevOps é o foco no sistema completo, em vez de simplesmente nas alterações de código que entregam a funcionalidade. DevOps deliberadamente reconhece que o código de aplicativo depende de uma infraestrutura de servidores, redes e bancos de dados para entregar valor. Portanto, uma implementação DevOps trata todas as mudanças em todos os componentes do sistema por igual e rastreia todas dessa forma. Algumas mudanças de infraestrutura, como o upgrade deliberado de um comutador ou a inclusão de armazenamento, podem ser considerados aprimoramentos – nova funcionalidade para o sistema – mesmo que sejam menos visíveis. Da mesma forma, correções em um servidor da web ou firmware SAN podem ser consideradas como correção de erros ou defeitos. Independente da forma como uma organização individual classifica as coisas, o ponto fundamental é que outras peças sejam tratadas com rigidez igual para garantir a estabilidade consistente do sistema.

Aplicar a perspectiva do sistema inteiro a um modelo de nível superior gera quatro categorias de mudanças a serem entregues em um ambiente DevOps:

• Aplicativo – O aplicativo é o recurso que está efetivamente produzindo código no sistema. É a funcionalidade de alta visibilidade, que conduz os processos de negócios principais que são o motivo para o sistema. Sua visibilidade rendeu-lhe um grande foco ao longo do tempo, mas esse foco raramente levou a uma consideração proativa do valor do ambiente que o suporta;
• Serviços de SO – A categoria de serviços de SO é uma categoria genérica para as máquinas (virtuais ou não, serviços e bibliotecas do sistema operacional e middleware que permitem a execução do aplicativo. A consistência de configuração entre todos os ambientes, do teste à produção, representa um motivador importante para a estabilidade e qualidade do aplicativo;
• Serviços de rede – Os serviços de rede incorporam todos os dispositivos de rede e configurações em torno do aplicativo. Essas configurações obviamente afetam o desempenho e a disponibilidade, mas também podem afetar o comportamento do aplicativo e a arquitetura à medida que o aplicativo sofrer ajuste de escala. Por exemplo, o aplicativo e o balanceador de carga têm que chegar a um acordo sobre a manipulação de sessão, entre outras coisas;
• Banco de dados – O banco de dados subjacente ao aplicativo contém os dados críticos que o aplicativo usa e produz. O banco de dados e o aplicativo devem permanecer perfeitamente sincronizados com relação à estrutura do esquema de dados em todos os momentos do ciclo de vida.

Propriedades de um sistema de implementação DevOps

As implementações no estilo DevOps exigem uma abordagem altamente disciplinada para entregar as mudanças nos sistemas de software que eles suportam. Quanto mais exceções, variações ou casos especiais o sistema precisa tolerar, mais caro será criá-lo e, mais importante, mantê-lo. Controlar a complexidade do processo de entrega significa entender e controlar o que está sendo entregue tanto como a maneira como está sendo entregue. Isso significa que a organização deve chegar a um acordo sobre um conjunto de pacotes definidos que formam cada unidade de entrega e em um sistema para colocá-los consistentemente no ambiente desejado.

Pacotes definidos

Um sistema de entrega efetivo requer que os itens sendo entregues tenham um nível razoável de normatização. No mundo físico, um bom exemplo são os contêineres de transporte. Um contêiner padrão pode ser transportado por equipamento padrão através de uma rede logística incrivelmente complexa, consistindo em diferentes meios de transporte, como trens, navios e caminhões. Com os guindastes e rastreamento de suporte, é possível transportar quase qualquer coisa para qualquer lugar, desde que caiba em um contêiner. O ato de normatizar esses contêineres revolucionou a maneira como todo o mundo transportava mercadorias e realizada o comércio.

A boa notícia é que não é necessário definir um padrão internacional para enviar alterações em um sistema de software. Isso pode geralmente ser feito através de uma extensão pragmática de atividades que muitas equipes já seguem. Muitas organizações já estão produzindo construções em um ritmo fixo, através de integração contínua ou de outro evento planejado. Esses desenvolvimentos têm, ou deveriam ter, algum tipo de identificador exclusivo que permite às pessoas que as usam, como os testadores, saber o que esperar delas.

Essa abordagem é uma linha de base para que as organizações comecem a entender os agrupamentos de mudanças nos outros três componentes. Se cada um dos quatro componentes puder ter uma maneira padrão de identificar suas mudanças, fica relativamente simples rastrear combinações dos quatro componentes através de seus designadores de mudança exclusivos. Essa combinação de número de desenvolvimento do aplicativo, servidores de número de configuração, versão de esquema do banco de dados e assim por diante pode ser rastreada e implementada em qualquer ambiente, para qualquer tipo de teste ou uso em produção.

Sistema de entrega

Ao contrário dos contêineres, o ecossistema dos pacotes implementáveis não envolve, necessariamente, equipamento hidráulico e óleo diesel. Em vez disso, envolve um grupo de ferramentas e processos que permitem que a organização manipule seus ambientes de desenvolvimento, teste e produção basicamente da mesma forma e coloque o pacote em qualquer um desses ambientes a qualquer momento. Essas ferramentas e processos lidam com diversas funções em um ambiente. Essas funções cruzam domínios de conhecimento e são aplicadas diferentemente, dependendo de qual dos quatro componentes de entrega está em questão. Dada a complexidade, é útil aplicar uma estrutura para visualizar e categorizar as funções em um conjunto de recursos que devem existir em um nível ou outro para ter sucesso.

Para DevOps, uma taxonomia de recursos envolve seis categorias, cada uma com um conjunto de subcategorias. Essa estrutura não prescreve ferramentas para as categorias, nem manda que todos os componentes tenham todos os recursos. No entanto, ela é uma ferramenta útil para entender e priorizar lacunas no processo de obter um sistema de entrega DevOps funcional.

Essas definições resumem as seis categorias:

• Gerenciamento de mudança – O conjunto de atividades para garantir que melhorias no sistema sejam rastreadas corretamente;
• Orquestração – Lida com a necessidade de coordenar atividades em um sistema distribuído de maneira sincronizada;
• Implementação – Abrange as atividades relacionadas a gerenciar o ciclo de vida de artefatos de todos os tipos sendo executados na infraestrutura;
• Monitoramento – Oferece a instrumentação para manter o ambiente funcional e fornecer feedback sobre o comportamento do sistema a todas as partes interessadas;
• Registro do sistema – Fornece um archive centralizado de todas as informações de infraestrutura compartilhadas que o sistema inteiro precisa para operar;
• Fornecimento – Garante que o ambiente de infraestrutura fornece números suficientes dos componentes corretos para executar o sistema.

Aplicando a taxonomia

O valor de uma taxonomia é que ela é uma ferramenta para entender um ambiente, identificar prioridades nele e avaliar soluções. Permite que uma organização crie rapidamente um entendimento estruturado de suas necessidades e dos pontos fortes de sua oferta. Também pode ser usado para avaliar o desempenho de uma organização ou solução em uma área particular ao longo do tempo. Esse tipo de taxonomia estrutura também permite que uma avaliação seja mais ou menos detalhada, dependendo da situação.

Por exemplo, em agosto de 2012, a IBM lançou uma versão beta de uma estrutura de implementação contínua chamada SmartCloud™ Continuous Delivery. O propósito dessa estrutura é entregar ferramentas e integrações que ajudam as organizações a adotar métodos de entrega DevOps.

Ao aplicar apenas os níveis superiores da taxonomia a essa oferta, podemos ver como está sendo estabelecida uma estrutura muito ampla para cobrir todas as seis áreas de recursos:

• Primeiro, o beta de SmartCloud Continuous Delivery usa IBM® Rational Team Concert™ e Rational® Asset Manager para oferecer recursos de gerenciamento de mudança, orquestração e implementação;
• Em segundo, há também integrações que usam a linha da IBM de ferramentas de infraestrutura de sistema no estilo de nuvem, como IBM Workload Deployer, IBM® SmartCloud ™ Provisioning, e IBM ® PureSystems™, para oferecer recursos de registro do sistema e fornecimento;
• Em terceiro lugar, há algum recurso de monitoramento na forma da instrumentação do processo através da criação de relatórios;
• Por fim, há integrações com ferramentas como Rational Automation Framework e Rational Build Forge® que preenchem o restante dos recursos de Implementação e Orquestração.

Mesmo um exame breve usando a abordagem estrutura mostra que SmartCloud Continuous Delivery tem certa cobertura em cada uma das seis áreas de recursos, mas há diferentes níveis de profundidade em cada uma. É de se esperar que haja diferentes níveis de capacidade em diferentes áreas, pois os provedores de ferramentas enfatizam abordagens diferentes, fazem integração com produtos ou portfólios de produtos diferentes e porque elas são, de outras formas, otimizadas para as necessidades dos usuários. Ter uma maneira consistente de avaliar essas soluções é o segredo para que organizações clientes garantam que estão recebendo o que realmente precisam.

Operando o sistema

Qualquer que seja a estrutura usada para entendê-lo, um sistema de entrega DevOps torna-se o agente central de todas as mudanças em um sistema de aplicativo. Essa centralidade aplica-se a todos os ambientes nos quais o aplicativo é executado, incluindo ambientes de produção e pré-produção. Isso garante que o aplicativo está sempre sendo executado em um estado conhecido em um ambiente com uma configuração conhecida. Chegar nesse estado exige mais do que um entendimento claro dos princípios e uma estrutura na qual desenvolver recursos. Requer aplicação efetiva dos princípios, e as organizações devem respeitar alguns fatores para fazerem isso eficazmente.

Gerenciamento de ambiente

Há quase sempre mais de um ambiente no qual um dado sistema de software é executado. Há produção, obviamente, mas há também qualquer número de ambientes de controle de qualidade ou de teste. É nesses ambientes de controle de qualidade que a organização verifica se uma dada mudança teve o impacto desejado. Esses ambientes são frequentemente tratados como secundários à produção, mas a verdade é que falsas informações de um ambiente de teste podem levar a indisponibilidade de produção. Essa dependência significa quer a organização deve levar isso a sério. O êxito da realização de uma entrega no estilo DevOps depende disso.

A primeira etapa para levar os ambientes a sério é garantir que todos os ambientes sejam realmente representativos. Esse é um exercício de engenharia para validar que uma configuração suposta em um ambiente de qualificação é um bom proxy para o ambiente de produção. Após essa linha de base ser estabelecida, manter esse estado fica mais simples.

A segunda etapa é garantir que todas as mudanças sejam promovidas através dos ambientes para a produção. Como o sistema de aplicativo é tratado como um todo, não deve haver qualquer tipo de configuração de mudança em qualquer aspecto do ambiente de produção que não seja executado através do processo de garantia de qualidade. Isso requer uma mudança na perspectiva de que algumas mudanças são fáceis ou diferentes de outras. Além dos benefícios óbvios de reduzir risco e melhorar a confiabilidade, isso também reduz o custo da manutenção e sincronização de ambiente. Essa abordagem significa que os ambientes estão sempre em um estado conhecido e, como todas as mudanças são aplicadas usando a mesma infraestrutura, a duplicação de esforços para gerenciar a configuração de diversos ambientes é reduzida.

Manipulação de exceção

Mesmo com uma abordagem de gerenciamento de ambiente unificada, emergências acontecem. Uma exceção deve ser um evento muito raro no ambiente. Um evento crítico com motivação externa é o cenário usual. Bons exemplos são erros do fornecedor em uma plataforma ou correção de segurança de emergência. Não devem ser mudanças de recursos com motivação interna.

O processo para lidar com a exceção deve ser tratar a exceção como um evento realmente importante e deve incluir atividades corretivas e autópsia. As atividades corretivas devem ser voltadas para a ressincronização dos ambientes. Por exemplo, caso o sistema padrão de entrega de mudanças não tenha sido usado para a mudança para o ambiente de emergência, a mudança deve ser incluída nesse sistema. Independente de como a mudança foi aplicada, deve haver também um processo de autópsia, para explicar como a emergência aconteceu e, mais importante, como reduzir a possibilidade de que a emergência aconteça novamente.

Medição e melhoria contínua

Usar métodos DevOps para entregar alterações de software oferece ampla oportunidade para medir e melhorar o processo. Além da consistência de um sistema padrão, a alta frequência de uma abordagem DevOps oferece mais pontos de dados. Várias métricas para coisas como ciclos operacionais, lacunas de empacotamento ou falhas de processo são coisas óbvias para medir. Essas não são métricas operacionais típicas, como disponibilidade ou tempo de atividade. Em vez disso, são voltadas para o processo que garante coisas como tempo de atividade e disponibilidade como resultado. Outras coisas boas para rastrear são métricas sobre a eficácia e eficiência do processo. Exemplos são o número de pessoas/hora necessárias para apoiar o sistema de aplicativo, o número necessário para manter a infraestrutura DevOps ou o tempo de espera para entrega em um dado ambiente.

Um método de entrega DevOps também permite grande instrumentação para o sistema de aplicativo. Essas métricas são muito específicas para cada aplicativo, mas revelam desempenho, responsividade sentida pelo usuário e assim por diante. Portanto, essas métricas informam decisões sobre a comparação dos ambientes operacionais, identificam gargalos em um sistema de aplicativo ou gerenciam requisitos de capacidade proativamente.

Loose coupling

As ferramentas na entrega DevOps devem ser “fracamente acopladas” ao ambiente no qual são implementadas. Isso significa que as equipes devem poder substituir ferramentas individuais sem uma grande interrupção no sistema geral.

Em termos de arquitetura, há vários modelos para isso. Por exemplo, concentrar-se em ferramentas que usam APIs de serviços da web como seu mecanismo de integração principal é uma doutrina popular para organizar ferramentas DevOps. Independente da abordagem técnica, as equipes devem perceber que alterar uma das ferramentas tem um certo impacto na capacidade geral da organização de implementar mudanças. Quando uma equipe quer substituir uma de suas ferramentas em uma categoria de recursos em particular, precisa analisar deliberadamente o impacto e pesá-lo em relação ao tempo e benefício que a substituição da ferramenta proporciona.

Resumo

DevOps exige uma mudança fundamental na abordagem das organizações para entrega de software em ambientes operacionais. O resultado disso, no entanto, é software de melhor qualidade sendo entregue com maior frequência. Uma abordagem estrutura para o problema, que trata o sistema de aplicativo como um todo unificado, pode ajudar as organizações a colaborar nesse esforço. Essa colaboração pode ser apoiada por uma abordagem sistemática para a entrega e melhoria de recursos, que entrega todo o sistema de aplicativo de forma cada vez mais eficiente. A abordagem DevOps favorece a abordagem agile de melhoria contínua e incremental em vários ciclos, e fornece às organizações a estrutura e insight para entregar, de forma consistente, software de valor aos usuários quando necessário. Esse é afinal o motivo para implementar software.

***

O IBM® Rational® Team Concert, baseado na plataforma Jazz, agora suporta qualquer plano, qualquer processo, qualquer plataforma! Novos modelos de planejamento formal suportam fases de projetos tradicionais, enquanto que novos recursos de gerenciamento de risco podem ser usados por qualquer equipe tradicional, agile ou híbrida.

Recursos

Aprender

• Explore a área do software Rational no developerWorks para recursos técnicos, melhores práticas e informações sobre soluções Rational colaborativas e integradas para entrega de software e de sistemas.
• Assine a newsletter semanal por email do developerWorkse escolha os assuntos que irá seguir.
• Fique atualizado com os eventos técnicos e webcasts do developerWorks com ênfase em uma variedade de produtos IBM e assuntos do segmento de mercado de TI.
• Participe de um resumo de instruções gratuito no briefing do developerWorks Live! para se informar sobre os produtos e ferramentas IBM, além das tendências do mercado de TI.
• Acompanhe as demos on demand do developerWorks, que abrangem desde a instalação e a configuração dos produtos para iniciantes até as funcionalidades avançadas para desenvolvedores experientes.

Obter produtos e tecnologias

• Faça download de uma versão gratuita de teste do software Rational.
• Avalie outros softwares IBM da forma que melhor lhe convier: faça o download da versão de avaliação, experimente-a online, use-a em um ambiente de nuvem ou passe algumas horas na Sandbox da SOA para saber como implementar arquitetura orientada a serviço de maneira eficiente.

Discutir

• Faça parte dos fóruns do software Rational para tirar dúvidas e participar das discussões.
• Faça e responda a perguntas, e aumente seus conhecimentos participando dos fóruns, cafés e wikis Rational.
• Faça parte da comunidade Rational para compartilhar seu conhecimento sobre o software Rational e ficar conectado aos seus parceiros.
• Avalie ou revise um software Rational. É rápido e fácil.

***

Sobre o autor: Dan Zentgraf é Arquiteto de Domínio na Ascendant Technology, onde sua missão é ajudar os clientes a adotar DevOps e práticas agile. Ele tem 12 anos de experiência no segmento de mercado de software como consultor e gerente de produto, trabalhando com empresas e líderes de engenharia.

***

O artigo original está disponível em: http://www.ibm.com/developerworks/br/rational/library/defining-deployment-deliverable-devops/index.html