Automação de liberação de aplicativo e automação de infraestrutura

Automação de liberação de aplicativo e automação de infraestrutura

Noções Básicas sobre a proposta de valor de ambas

por Julian Fish, Diretor de Gerenciamento de Produtos, Serena Software (agora parte da Micro Focus)

White Paper

O que é a automação de infraestrutura? . . . 4

O que é a automação de liberação de aplicativos? . . . . 5

Qualidades em comum . . . . 7

Deployment Automation vs . Puppet para automação de infraestrutura . . . . 8

Deployment Automation vs . Puppet para automação de liberação de aplicativos . . . . 10

O valor dos pipelines . . . . 10

Implantações orientadas por modelo . . . . 12

Uma pequena questão de extensibilidade . . . . 13

O melhor possível . . . . 13

Resumo executivo

As organizações que iniciam a sua jornada de transformação de DevOps ou aquelas que estão simplesmente olhando para automatizar e configurar, olhando a configuração de seus ambientes, são, muitas vezes, confundidas quanto ao valor da automação de liberação de aplicativos em oposição às ferramentas de automação de infraestrutura . Há uma

infinidade de ferramentas disponíveis, com muitas desempenhando funções aparentemente sobrepostas . Este documento trata de duas ferramentas líderes de mercado: o Micro Focus Deployment Automation

¹

para automação de liberação de aplicativos e o Puppet

²

para automação de infraestrutura. As propostas de valor de cada ferramenta, a área de foco principal de cada uma delas e os benefícios que cada uma pode oferecer como parte de uma cadeia de ferramentas de DevOps integrada também são discutidos .

Por que automatizar

Muitas organizações estão procurando simplificar e reduzir a complexidade das implantações de aplicativos, mantendo a estabilidade operacional, aderindo a SLAs e garantindo que a receptividade do aplicativo seja atendida . Uma maior capacidade de resposta dos negócios e “mover-se rápido sem quebrar as coisas” é fundamental para a sobrevivência da empresa . Para apoiar essas metas concorrentes, a necessidade de automatizar a “pilha inteira do aplicativo” tem se tornado cada vez mais importante. Infelizmente, a definição de “pilha inteira” tende a variar dependendo da área da organização que a descreve .

Operações geralmente considera a “pilha inteira” como a infraestrutura necessária para hospedar os aplicativos e os sistemas de suporte, com o aplicativo visto como um pequeno componente da pilha; enquanto as organizações de Desenvolvimento tendem a ver a “pilha inteira” como todas as camadas do aplicativo funcionando de maneira bem-sucedida e em conjunto, uma com a outra, mostrando muito menos interesse na infraestrutura subjacente. A realidade, principalmente a partir de uma perspectiva de DevOps, é que todas as áreas precisam trabalhar em plena colaboração para garantir que aquilo que se tornou rapidamente os bens mais essenciais de uma organização sejam suportados . Ao longo da última década, a função da TI não é mais vista como um diferencial comercial importante;

simplesmente manter os sistemas corporativos em execução não é mais visto como um valor agregado. É considerado como um requisito obrigatório. Para as empresas, o aplicativo é o rei, e é a mudança do aplicativo que impulsiona a diferenciação corporativa e o valor da Este documento trata de

duas ferramentas líderes de mercado: o Micro Focus Deployment Automation para automação de liberação de aplicativos e o Puppet para automação de infraestrutura. As propostas de valor de cada ferramenta, a área de foco principal de cada uma delas e os benefícios que cada uma pode oferecer como parte de uma cadeia de ferramentas de DevOps integrada também são discutidos.

__________

1 O Deployment Automation (SDA) é uma ferramenta líder de mercado usada para a automação de aplicativos que pode integrar e iniciar ferramentas de aprovisionamento de infraestrutura. www.serena.

com/sda

2 O Puppet é uma ferramenta

Uma breve história sobre a automação

Observa-se nos últimos 15 anos um aumento da taxa de mudanças na indústria de software, que, como Glenn O’Donnell da Forrester comentou, está levando à “industrialização da TI”

³

. Inicialmente impulsionado por uma redução de gastos em TI após o bug do milênio e a falência de empresas pontocom, depois, estendido pela adoção em massa da Internet e por uma abordagem “sempre ligada” para as empresas, essas mudanças tiveram um impacto enorme sobre o mundo da TI corporativa e empresarial. As empresas que há 15 anos não tinham nenhuma chamada para um site corporativo, muito menos a noção de uma acessibilidade do cliente “sempre ligada”, 24 horas por dia, tiveram de se adaptar a uma maneira completamente nova de trabalhar. A redução de gastos com TI levou as organizações a fazerem mais com menos — reduzindo pessoal e aumentando as demandas de TI corporativa. A adoção da “Internet em todos os lugares” exige um nível de eficiência operacional, um tempo de atividade do sistema e uma capacidade de resposta nunca antes exigidos. O nível de complexidade inerente a muitos aplicativos corporativos significa que a entrega eficiente e repetível de mudanças de negócios não é mais uma tarefa simples.

Os riscos de expor aplicativos a terceiros que podem estar em busca de pontos fracos ou de acesso pela porta dos fundos a sistemas empresariais críticos de back-office significa que simplesmente aumentar a taxa de entrega não é suficiente — os aplicativos devem ser implantados rapidamente, mantendo um alto nível de qualidade e segurança e com o próximo grande recurso incluído . Basear-se em processos manuais para garantir

confiabilidade, rastreabilidade e repetibilidade não é mais viável. Ao continuar entregando aplicativos de forma manual, corre-se o risco de deixar uma organização muitos passos atrás da concorrência .

O progresso nem sempre é difícil

As equipes de desenvolvimento têm tradicionalmente aceitado mudanças, por exemplo, a transição de linguagens de programação “legadas” como COBOL e C para novas linguagens como Java e .Net. As equipes de desenvolvimento têm modificado seus aplicativos e processos para suportar mudanças, mesmo quando os benefícios iniciais podem ser compensados pelos custos de transição . A transição das disciplinas de gerenciamento de projetos Waterfall para as disciplinas Agile, a adoção de práticas LEAN e a prevalência da adoção de software de código-fonte aberto são excelentes exemplos da disposição das equipes de desenvolvimento em apoiar mudanças . A capacidade dessas organizações de desenvolvimento de se tornarem mais eficientes e de oferecerem recursos de negócios de forma mais eficiente e rápida tem aumentado a pressão sobre as equipes de Operações para entregarem de maneira efetiva e rápida esses novos recursos .

As empresas que há 15 anos não tinham nenhuma chamada para um site corporativo, muito menos a noção de uma acessibilidade do cliente “sempre ligada”, 24 horas por dia, tiveram de se adaptar a uma maneira completamente nova de trabalhar.

__________

3 O’Donnell, Glenn. 2010, TI é industrialização — O que isso significa para mim?, Blog do Glenn O’Donnell, visto em 24 de fevereiro de 2015, http://blogs.forrester.com/

glenn_odonnell/10-04-21-it_

industrializing_%E2%80%93_

what_does_mean_me

Historicamente, as equipes operacionais têm adotado uma abordagem de “risco zero”

para o gerenciamento de ambientes de produção ou de operação, como geralmente tem sido imposto por suas empresas . As empresas exigem estabilidade do sistema e tempo de atividade, o que torna esta abordagem completamente compreensível. A responsabilidade de manter um sistema comercial funcionando com êxito, um sistema de pedidos funcionando corretamente ou um sistema bancário que forneça informações precisas aos consumidores não é uma responsabilidade a ser assumida superficialmente. O investimento e a adoção de práticas, processos e procedimentos baseados em ITIL por muitas organizações mostram como os sistemas operacionais são mantidos de maneira séria. Garantir que todos concordem é fundamental para permitir que práticas e procedimentos comuns sejam seguidos .

À medida que as empresas se esforçam para oferecer a melhor experiência possível ao cliente, atraindo novas funcionalidades ou obtendo vantagem competitiva, a entrega de mais e mais aplicativos muda tão rapidamente e eficientemente quanto possível. A pergunta passa a ser como possibilitar esses dois requisitos aparentemente conflitantes? É possível fornecer a taxa de entrega de aplicativos exigida pelo Desenvolvimento e os níveis de estabilidade, rastreabilidade, controle e rigor exigidos pelas Operações, mantendo ao mesmo tempo quaisquer requisitos de conformidade regulatória, industrial ou corporativa?

_______________________________________________________________

À medida que as empresas se esforçam para oferecer a melhor experiência possível ao cliente, atraindo novas funcionalidades ou obtendo vantagem competitiva, a entrega de mais e mais aplicativos muda tão rapidamente e eficientemente quanto possível.

Fig. 1

Desenvolvimento vs. Desafios operacionais

_______________________________________________________________

A automação de

implantações de aplicativos, de instalação de aplicativos e de configurações de sistemas assegura que uma consistência seja alcançada em todo o ambiente;

que as implantações podem ser repetidas, conforme necessário;

e auditorias completas podem ser implementadas e monitoradas para ver exatamente qual versão de quais artefatos foram implantados, em que ambiente e em que dado momento.

Os avanços tecnológicos significam que agora é muito mais fácil automatizar a entrega de aplicativos e toda a infraestrutura de suporte . O movimento de DevOps que se esforça para abordar as pessoas, os processos e os desafios de comunicação prevalentes em duas unidades organizacionais distintas (Desenvolvimento e Operações) pode certamente se beneficiar do uso da Automação . Da mesma forma que as organizações descobriram que a recompilação de código em ambientes diferentes leva a saídas de build diferentes e a vários problemas em ambientes subsequentes, há uma percepção crescente de que a falta de consistência de implantação em diferentes ambientes também levará a grandes problemas e desafios. A automação de implantações de aplicativos, de instalação de aplicativos e de configurações de sistemas assegura que uma consistência seja alcançada em todo o ambiente; que as implantações podem ser repetidas, conforme necessário; e auditorias completas podem ser implementadas e monitoradas para ver exatamente qual versão de quais artefatos foram implantados, em que ambiente e em que dado momento. A automação geralmente também leva a uma redução no tempo gasto executando as implantações, a uma maior confiança na qualidade da entrega (as máquinas não cometem erros nem se esquecem de executar comandos) e à capacidade de provar exatamente que o que realmente estava planejado ocorreu

— garantindo que resultados importantes de conformidade de auditoria sejam atingidos .

A implantação de um aplicativo geralmente não é tão simples como apenas mover arquivos de um local para outro . Pode envolver a criação ou a extensão de infraestrutura para suportar novos recursos, maior capacidade de armazenamento ou implementar novos recursos do aplicativo, exigindo rotinas de instalação complexas. A automação de infraestruturas e de aplicativos são capacidades sutilmente diferentes que exigem uma definição adicional.

O que é a automação de infraestrutura?

A automação de infraestrutura é a criação e o gerenciamento de ambientes, incluindo a instalação de sistemas operacionais, a instalação e a configuração de servidores em instâncias físicas, virtuais ou de nuvem, e a configuração como as instâncias e o software se comunicam entre si. Também é comumente referido como aprovisionamento, infraestrutura com scripts, infraestrutura como código ou, de maneira confusa, gerenciamento de

configurações (um termo que tem muitos significados diferentes dependendo da parte do

ciclo de vida que está sendo discutida). O princípio é simples: definir uma configuração

de sistema via script ou via um conjunto de scripts para permitir aos usuários criarem ou

recriarem ambientes da maneira mais simples e rápida possível, garantindo menos erros e

rápidos tempos de retorno .

O que é a automação de liberação de aplicativos?

A automação de liberação de aplicativos é o gerenciamento com scripts de aplicativos dentro de ambientes, incluindo instalação, configuração de aplicativos e implantação de aplicativos em ambientes físicos, virtuais ou de nuvem. Esses ambientes de destino podem, de fato, ter sido criados através do uso da automação de infraestrutura. A automação de liberação de aplicativos abrange a configuração de como os aplicativos são instalados, implantados e como diferentes camadas de um aplicativo interagem com uma outra em tempo de execução. Também é comumente referida como automação de aplicativos (AA), automação de implantação, implantação ágil ou até mesmo gerenciamento de lançamentos.

O termo “script” é comumente utilizado para cobrir ferramentas centradas em pacotes, A automação de liberação

de aplicativos abrange a configuração de como os aplicativos são instalados, implantados e como diferentes camadas de um aplicativo interagem com uma outra em tempo de execução.

Fig. 2

Automação de infraestrutura

_______________________________________________________________

declarativas, personalizadas e de processo, com ou sem recursos de definição de UI. O princípio é simples: definir um modelo via script ou via um conjunto de scripts para permitir aos usuários criarem ou recriarem aplicativos de implantação da maneira mais simples e rápida possível, garantindo menos erros e rápidos tempos de retorno.

_______________________________________________________________

A automação de liberação de aplicativos é também comumente referida como automação de aplicativos (AA), automação de implantação, implantação ágil ou até mesmo gerenciamento de lançamentos.

Fig. 3

Automação de liberação de aplicativos

_______________________________________________________________

A automação de

aplicativos e a automação de infraestrutura

podem ser vistas como complementares no mundo mais amplo de DevOps e no mundo de Entrega Contínua ou Implantação Contínua.

__________

4 A Entrega Contínua (CD) diz respeito a manter o seu aplicativo em um estado em que ele pode sempre ser implantado na produção. Martin Fowler, visto em 24 de fevereiro de 2015, http://martinfowler.

com/delivery.html 5 A implantação contínua está

implantando cada mudança na produção, todos os dias ou com mais frequência. Martin Fowler, visto em 24 de fevereiro de 2015, http://martinfowler.

com/delivery.html

Qualidades em comum

Tanto a automação de aplicativos quanto a automação de infraestrutura podem ser vistas como complementares no mundo mais amplo de DevOps (os processos e as práticas de alinhamento das equipes de Desenvolvimento e Operações) e no mundo de Entrega Contínua

⁴

ou Implantação Contínua

⁵

. A semelhança dos objetivos entre estes dois tipos de ferramentas, ou seja, maior capacidade de resposta, redução de erros, auditoria melhorada, responsabilidade e monitoramento, e a intenção de “escrever scripts” para tudo, leva a dois conjuntos de ferramentas normalmente vistos como concorrentes diretos ou como potenciais substitutos um do outro . A realidade é que os dois conjuntos de ferramentas têm um objetivo bem definido e um “ponto ideal”. Embora seja certamente possível usar um para executar certas funções do outro, é preferível escolher a ferramenta certa para o trabalho.

_______________________________________________________________

Automação de liberação de

aplicativos Automação de infraestrutura

Implantações centradas em processo

● ●

Implantação de aplicativos

● ●

Instalação de aplicativos

● ●

Suporte de pipeline

● ●

Gerenciamento do ambiente

● ●

Aprovisionamento de infraestrutura

● ●

Modificação de infraestrutura

● ●

Aprovisionamento bare-metal

● ●

Automação de pilha inteira (baseada na

cadeia de ferramentas)

● ●

Fig. 4

Automação de liberação de aplicativos versus automação de infraestrutura

_______________________________________________________________

Deployment Automation vs. Puppet para automação de infraestrutura

O Deployment Automation pode ser usado para executar um subconjunto de tarefas de automação de infraestrutura através de scripts ou plug-ins existentes para ferramentas de terceiros; em determinadas circunstâncias, isto pode ser tudo o que é necessário para a automatização da infraestrutura . Exemplos de tais atividades podem ser o aprovisionamento virtual ou baseado em nuvem, onde uma imagem predefinida e configurada existente é usada para fornecer capacidade adicional virtual ou de nuvem . A prática de criação de infraestrutura com base em uma imagem predefinida e configurada é comumente referida como aprovisionamento de “Imagem de Ouro’, pois pouca configuração adicional é

necessária uma vez que a nova infraestrutura já foi criada . Esse modelo de aprovisionamento de infraestrutura é adequado quando as organizações desejam dimensionar sua

infraestrutura de aplicativos existente horizontal ou verticalmente para fornecer capacidades ou recursos adicionais. Nesse caso, o aprovisionamento de infraestrutura virtual seria executado usando plug-ins de VMware ESX, ESXi ou Workstation, com novas imagens virtuais provisionadas. Após a instanciação, as novas imagens atualizarão as configurações de propriedade do agente, permitindo que os novos agentes se registem automaticamente nos grupos de pool de agentes corretos no servidor do Deployment Automation . O aprovisionamento de infraestrutura em nuvem seria executado usando plug-ins Amazon, Azure ou vCloud, com novas imagens de nuvem provisionadas. Após a instanciação, as novas imagens atualizarão as configurações de propriedade do agente, permitindo que os novos agentes se registem automaticamente nos grupos de pool de agentes corretos no servidor do Deployment Automation .

A automação de infraestrutura no nível de máquina “bare-metal” ou físico exige muito mais recursos aprofundados e, como uma ferramenta de automação de aplicativos, esse não é o objetivo do Deployment Automation. Nestas circunstâncias, recomenda-se a utilização de uma ferramenta de terceiros, como o Puppet, com o processo de aprovisionamento de infraestrutura controlado pela ferramenta de automação de implementação . Usar uma ferramenta de aprovisionamento de infraestrutura, como o Puppet, exige um conjunto específico de habilidades. Embora existam uma série de manifestos e módulos predefinidos na comunidade de desenvolvimento, as habilidades necessárias para criar, modificar e atualizar esses manifestos são comumente encontradas em pessoas com experiência em operações. Saber que parâmetros de kernel, memória, sistema e configuração configurar no momento da instanciação, como implantar um sistema operacional corretamente com parâmetros de segurança e de rede, e entender os requisitos de E/S de disco dos conjuntos de armazenamento de dados anexados ao instanciar nova infraestrutura no contexto de um data center muito maior é essencial para fornecer infraestrutura de base adequada para implantar junto aos aplicativos .

Usar uma ferramenta de aprovisionamento de infraestrutura, como o Puppet, exige um conjunto específico de habilidades.

Embora existam uma série

de manifestos e módulos

predefinidos na comunidade

de desenvolvimento, as

habilidades necessárias para

criar, modificar e atualizar

esses manifestos são

comumente encontradas em

pessoas com experiência

em operações.

Receitas, Cookbooks e outros scripts de definição geralmente são escritos em uma Linguagem de domínio específica, sendo necessário certo conhecimento sobre scripts para definir e configurar implantações de infraestrutura. A implantação de aplicativos nesta “pilha” predefinida ou personalizada criada é a extensão lógica do aprovisionamento de infraestrutura — você está implantando todo esse novo e apropriado hardware por um motivo. O objetivo final é ser capaz de definir o processo de implantação para o

aprovisionamento de infraestrutura, chamar os manifestos e os módulos corretos para criar a nova infraestrutura física, implantar nova infraestrutura virtual, implantar aplicativos e garantir que todos os aplicativos em toda a pilha recém-criada estão configurados corretamente . Através do uso de plug-ins para ferramentas de aprovisionamento como o Puppet, as organizações obtêm as vantagens de uma ferramenta de excelência para criar a infraestrutura, os recursos de processo para a ferramenta de automação mais a capacidade de implantar perfeitamente os aplicativos no ambiente recém-criado utilizando um processo definido graficamente fácil de usar com auditoria e rastreabilidade completas .

_______________________________________________________________

Através do uso de plug- ins para ferramentas de aprovisionamento como o Puppet, as organizações obtêm as vantagens de uma ferramenta de excelência para criar a infraestrutura, os recursos de processo para a ferramenta de automação mais a capacidade de implantar perfeitamente os aplicativos no ambiente recém-criado utilizando um processo definido graficamente fácil de usar com auditoria e rastreabilidade completas.

Fig. 5

Aprovisionamento de pilha inteira

Deployment Automation vs. Puppet para automação de liberação de aplicativos

Como vimos ao falar sobre a automação de infraestrutura, as áreas conjuntas de automação fornecem os recursos necessários para implementar os princípios de DevOps dentro de uma organização. No entanto, como vimos com a automação de infraestrutura, há algumas áreas importantes e específicas que você pretenderia direcionar com a automação de aplicativos.

Se a implantação do seu aplicativo for tão simples quanto a execução de um script de lote ou shell para copiar arquivos para o local correto, as ferramentas de automação de infraestrutura podem fornecer a você os recursos (se não a rastreabilidade) necessários . Infelizmente, tais implantações de aplicativos simples são incrivelmente raras no mundo dos softwares empresariais. Geralmente, a abordagem da simples cópia de um arquivo e a execução de um script não é suficiente para implantar um aplicativo de n camadas, que pode conter dependências entre diferentes áreas de componentes do aplicativo, ter sistemas operacionais diferentes em ambientes diferentes e exigir etapas manuais complementando os scripts . Onde múltiplos componentes de um aplicativo ou vários aplicativos de eventos devem ser implantados em série ou em paralelo, os recursos das ferramentas de automação de infraestrutura se tornam estendidos e você acabará usando scripts encadeados

incrivelmente complicados, o que dificultará o gerenciamento e a compreensão. Até mesmo simples implantações de aplicativos para servidores de aplicativos comumente usados, como Tomcat, exigem scripts detalhados e complexos; por exemplo, uma simples implantação de arquivo war no Tomcat usando o Puppet exige mais de 800 linhas de código. Manter esses scripts atualizados ou modificá-los de acordo com os requisitos da organização pode se tornar uma responsabilidade de tempo integral para um recurso bem pago e altamente qualificado. Em comparação, a simples implantação de um arquivo war em um servidor de aplicativos Tomcat usando o Deployment Automation é uma etapa de processo única, exibida graficamente para o usuário final. Quaisquer personalizações ou mudanças de configuração entre ambientes são passadas como parâmetros para esta etapa, garantindo a repetibilidade total do processo desde os ambientes de desenvolvimento até a produção .

O valor dos pipelines

Um dos princípios centrais de qualquer tipo de automação é que o estado final é conhecido e pode ser alcançado de uma forma repetível . A consistência entre os ambientes é fundamental para evitar erros durante as implantações. Não é raro que os gerentes de lançamento, os engenheiros de qualidade e os engenheiros de operações tenham dificuldades de

Geralmente, a abordagem

da simples cópia de um

arquivo e a execução de

um script não é suficiente

para implantar um aplicativo

de n camadas, que pode

conter dependências

entre diferentes áreas de

componentes do aplicativo,

ter sistemas operacionais

diferentes em ambientes

diferentes e exigir etapas

manuais complementando

os scripts.

implantar aplicativos nos ambientes escolhidos, apenas para encontrar o menosprezo de suas contrapartes de engenharia que simplesmente afirmam “Bem, isso funcionou no meu ambiente”. Sem um objetivo consistente ou um estado final pretendido, a automação se torna um exercício trivial e não fornece qualquer valor viável. Naturalmente, o estado final pretendido para qualquer iniciativa de DevOps ou de Entrega Contínua é entregar aplicativos a um ambiente de produção, em qualquer momento, de uma maneira simples, repetitiva, auditável e automatizada. No entanto, da mesma forma que as atividades de planejamento iniciais irão garantir a conclusão bem-sucedida e oportuna, é fundamental conhecer os mecanismos, os estágios e os níveis de validação necessários para entregar os aplicativos para a produção. Simplesmente esperar que o código produzido nos ambientes de desenvolvimento funcione perfeitamente em um ambiente de produção com diferentes configurações, parâmetros de tempo de execução, configuração de infraestrutura e conjuntos de dados torna-se cada vez menos realista, principalmente à medida que a complexidade do aplicativo e das dependências entre os aplicativos são encontradas durante as implantações . Para muitos clientes corporativos, simplesmente definir as dependências entre os aplicativos e conhecer o impacto da mudança de um aplicativo para outro é uma atividade altamente complexa e demorada. Apenas garantir a implantação bem-sucedida no momento certo, no ambiente correto é o objetivo final de muitas organizações de entrega de aplicativos.

Para ajudar a garantir que esse objetivo seja alcançado, a noção de um pipeline de

implantação ou de um caminho para a produção é fundamental . Os pipelines de implantação têm existido em muitos aspectos ao longo dos anos, desde o SDLC tradicional, em que o desenvolvimento é seguido pelo teste, seguido pela produção, até caminhos visualmente definidos e dinâmicos para a produção, que podem variar dependendo do aplicativo e do risco potencial de implantar o referido aplicativo .

Uma das muitas perguntas que os clientes fazem ao definir um pipeline ou pipelines é

“Todos os meus aplicativos requerem o mesmo pipeline”? Uma resposta simples é olhar para os aplicativos em questão e definir os requisitos de conformidade e auditoria de cada um.

Um site de Intranet exige o mesmo nível de rigor e validação do que um cliente diante de um banco online ou de um sistema comercial? Para a maioria das organizações, a resposta é um retumbante “não”, é necessário ter rigor e controle para aplicativos bastante usados e de alta visibilidade pelo consumidor; aplicar as mesmas abordagens em aplicativos de teste Simplesmente esperar

que o código produzido nos ambientes de desenvolvimento funcione perfeitamente em um ambiente de produção com diferentes configurações, parâmetros de tempo de execução, configuração de infraestrutura e conjuntos de dados torna-se cada vez menos realista,

principalmente à medida que

a complexidade do aplicativo

e das dependências entre os

aplicativos são encontradas

durante as implantações.

Os pipelines são o componente crítico ao definir a repetibilidade de implantações em vários ambientes, provando conformidade e adesão aos padrões. Implantar os mesmos aplicativos, usando os mesmos processos para vários ambientes, pode ser facilmente alcançado

definindo e impondo um pipeline. Os pipelines também permitem que as discrepâncias entre os ambientes sejam identificadas.

O Deployment Automation fornece um recurso de pipeline gráfico completo, com a opção de exigir o uso de pipeline e até mesmo promover automaticamente aplicativos de um ambiente para outro (assumindo que a implantação anterior foi concluída com êxito) . O Puppet não tem nenhum conceito de pipelines . Embora os trabalhos de automação possam ser vinculados através do uso de scripts encadeados . A recomendação neste cenário seria conduzir graficamente os trabalhos do Puppet através de um processo gráfico no SDA e seguir o processo gráfico que é definido para o pipeline de implantação .

Implantações orientadas por modelo

Entender como efetivamente implantar aplicativos de destino é um fator fundamental na adoção de qualquer ferramenta de automação . É impossível automatizar implantações de aplicativos se houver falta de conhecimento das etapas necessárias para executar essa implantação. Com implantações baseadas em modelos, como as usadas pelo Deployment Automation, é possível que os usuários finais definam graficamente todo o processo de implantação de aplicativos, incluindo as dependências do aplicativo e interações sistema a sistema . A capacidade de modelar os processos de implantação e os pipelines de implantação de uma maneira gráfica fornece uma vantagem significativa em relação aos aplicativos de tipo declarativo, em que o conhecimento e o entendimento do processo são provenientes de uma compreensão implícita do código usado para executar quaisquer implantações . Considere um caso de usuário simples, por exemplo, implantar um aplicativo em um servidor de aplicativos, como o Tomcat. Com um sistema baseado em modelo, a definição da atividade a ser realizada é desenhada graficamente em uma tela, indicando a etapa e o processo a serem executados. Em um sistema declarativo, essa mesma atividade exigirá a modificação do código; neste caso, um artefato contendo cerca de 1.000 linhas de código deve ser alterado. Naturalmente, é muito mais fácil para novos usuários entender uma definição de processo gráfica do que ter que entender uma nova linguagem de programação com muitas centenas de linhas de código. Futuras modificações são também simplificadas, pois todas as personalizações podem ser facilmente visualizadas no processo de implantação, ao contrário de ter que rever as complexas bases do código .

É impossível automatizar implantações de aplicativos se houver falta de

conhecimento das etapas

necessárias para executar

essa implantação.

Uma pequena questão de extensibilidade

As empresas são ambientes complexos . Nunca é um simples caso de ser capaz de executar as mais recentes e melhores versões de software sobre a mais recente e melhor infraestrutura . Na maioria das organizações empresariais de longa permanência, os aplicativos legados devem coexistir com os novos aplicativos, várias versões de linguagens de programação, componentes de tempo de execução e camadas de abstração. Para muitas organizações, a migração para versões de aplicativos mais recentes também envolve a migração de infraestrutura, desktops de usuários finais e atualização de interfaces de dados existentes.

A variação nas versões de aplicativos que precisam ser atualizados no momento da

implantação significa que ter uma interface complexa e difícil de atualizar entre a tecnologia de automação e o sistema de terceiros coloca você em uma grande desvantagem . O

Deployment Automation fornece um grande número de integrações prontas para muitos sistemas de terceiros comuns — banco de dados, middleware, servidores de aplicativos e até mesmo ferramentas de teste . O modelo de plug-in extensível usado pelo aplicativo permite a rápida criação de novos plug-ins para sistemas de terceiros, aumentando a capacidade da plataforma de automação para se estender a todas as áreas da empresa . Os manifestos do Puppet são uma ótima maneira de definir a sua infraestrutura como um código e de conduzir a criação, a atualização e a destruição de infraestrutura como parte de um processo predefinido de aprovisionamento e implantação de “pilha inteira” .

O melhor possível

Conforme já discutido, o aprovisionamento de “pilha inteira” pode envolver toda a pilha de aplicativos e de infraestrutura. As implantações de aplicativos, o aprovisionamento de infraestrutura e os processos para manter todos os itens acima em sincronia são componentes importantes para organizações que buscam adotar os benefícios da Entrega Contínua e a tecnologia de transição, bem como as pessoas e processos voltados para DevOps . As ferramentas de aprovisionamento de infraestrutura desempenham uma função extremamente importante na garantia de que a infraestrutura de base esteja instalada para implantações de aplicativos subsequentes . O uso de processos consistentes para implantações de infraestrutura e de aplicativos garante que a conformidade, a auditoria, a repetibilidade e a percepção das implantações sejam obtidas ao mesmo tempo em que se reduz o tempo de implantação e que se remove os riscos de implantações manuais . As implantações

de aplicativos, o aprovisionamento de infraestrutura e os processos para manter todos os itens acima em sincronia são componentes importantes para

organizações que buscam

adotar os benefícios da

Entrega Contínua e a

tecnologia de transição,

bem como as pessoas e

processos voltados para

DevOps.

www.microfocus.com +57 1 622 2766 México

+52 55 5284 2700 Venezuela +58 212 267 6568 Micro Focus Sede da empresa Reino Unido

+44 (0) 1635 565200

www.microfocus.com