Ao escrevermos sobre PaaS devemos ter o conceito que estamos trabalhando com um modelo de plataforma direcionado à aplicações e alguns de seus objetivos específicos – razões de sua existência – são a simplificação, flexibilização, em função da utilização de estrutura como serviço, que proporcionarão maior agilidade do processo de provisionamento de aplicações.
Quando mencionamos PaaS, desprenda-se da ideia de que seu negócio será deslocado para o datacenterde um fornecedor externo, nem pense em uma caixa preta, pois é possível trabalhamos com PaaS em seu datacenter local, de forma híbrida com integração externa ou somente em um fornecedor externo.
Devemos estar atentos às demandas da organização, identificar necessidades de acordo com critérios claros de aplicabilidade de uma solução e urgência da mesma. A soma da consistência e acerto de seus critérios resultará na aderência e sucesso do projeto.
Existe razão de utilizarmos como modelo de plataforma o PaaS em busca de flexibilização e agilidade se o processo de desenvolvimento das aplicações na organização alvo utiliza métodos que não demandam tal agilidade? Respondendo a este questionamento, podemos relacionar a aplicabilidade do PaaS com a Entrega Contínua (CD – Continuous Delivery)?
Antes de responder a questão, resumiremos aqui Entrega Contínua. Entrega Contínua consiste em uma abordagem de desenvolvimento, gestão, e ou automação que permita entregar valores de forma ágil ainda que trabalhe com ciclos que garantam a confiabilidade do valor entregue.
Não esqueçamos de responder a pergunta anterior. Na humilde opinião de quem vos escreve, sim, grande parte da justificativa do uso do PaaS se aplica a Entrega Contínua como abordagem de desenvolvimento de aplicação. Não desacreditando que Entrega Contínua não possa ser feita em outros modelos tal qual o IaaS (Infrastructure as a Service), mas como o fator observado é o motivo e valia, sim, o uso do PaaS agrega muito na agilidade do processo de entrega da aplicação.
Para esta publicação nos propusemos apenas que idealize uma solução simples de entrega contínua, ou seja, absorva o conceito do ciclo que envolve, desde um ambiente integrado para desenvolvimento de software (IDE) até a publicação no ambiente de desenvolvimento da plataforma apresentada, PaaS.
Você é o desenvolvedor, que em conjunto com uma equipe, trabalhou dias no desenvolvimento de um micro serviço que tem como função integrar, consumindo informações de um sistema legado e que disponibilizará para um novo módulo de uma aplicação web que está em desenvolvimento por outra equipe da sua organização. Tal integrador foi desenvolvido na linguagem Python, e utiliza recursos auxiliares, peculiares e conflitantes com aplicações existentes.
Veja que ao utilizarmos o PaaS como modelo de plataforma este não seria um evento impactante no projeto, uma vez que pode-se entregar como serviço uma plataforma exclusiva que atende os requisitos da aplicação alvo sem que reflita ou conflite com as demais aplicações ou ativos da organização.
Uma vez criada a plataforma para a aplicação em questão chega a hora de dar agilidade no processo de publicação da aplicação, não esquecendo o ciclo de promoção dos ambientes.
Em um início de tarde, você utilizando sua IDE, realiza o *commit em seu repositório local de GIT. Avalia então necessidades de *merge. Passados os procedimentos de controle de versão seu trabalho, assim como os de outros, estão na *branch master do repositório GIT da equipe. Através de um *hookconfigurado que dispara um job em uma ferramenta de automação para geração do artefato.
Com o artefato gerado após passar por testes de cobertura, unitários, funcionais e de performance integrados na ferramenta de automação. Tal artefato é publicado no ambiente de desenvolvimento do PaaS sem interação humana. E quando o build for finalizado com sucesso, você, assim como sua equipe, poderá comemorar o resultado de dias de trabalho.
Agora restará avaliar a janela de publicação, aprovação e demais processos que sua organização realiza para promover o build para os ambientes de teste, homologação e produção.
Surgirão questionamentos tais como:
- Quais soluções utilizar?
- Quais as vantagens obtidas?
Continua!
commit: confirmar alterações/adições em um repositório
merge: mesclar alterações/adições em um repositório
branch master: nome do branch padrão no Git
hook: disparar scripts quando certas ações ocorrerem
build: versão "compilada" de um software ou parte dele
Agradecimentos aos amigos e colegas César Mesquita, Lincolm Aguiar e Milton Duarte, pela paciência, orientação е incentivo qυе tornaram possível а conclusão desta postagem.
Publicação também disponível em: http://ilegra.com/beyonddata/
Nenhum comentário:
Postar um comentário