Ao longo deste artigo, o termo software será utilizado na sua forma mais ampla, ou seja, neste contexto poderá remeter a um aplicativo, a um sistema operacional, a uma ferramenta ERP, a um ativo de TI etc.

Olhando para o contexto comercial global, podemos afirmar que, com o avanço tecnológico, o software tem se mostrado parte fundamental dentro das organizações. Inúmeros softwares realizam tarefas de forma automatizada ou auxiliam os funcionários na realização destas; alguns são responsáveis, ainda, por apoiar a tomada de decisão de mais alto nível. Neste cenário, em que o software pode ser considerado um ativo de valor para a organização, mantê-lo atualizado e operante dentro das métricas definidas pelos níveis de qualidade é uma tarefa árdua. Os pilares primários de suporte estão sob responsabilidade das equipes de desenvolvimento e operação.

Porém, ao longo dos anos construiu-se uma “relação de ódio” entre equipes de desenvolvimento e operação. Quando algo não sai como esperado, a primeira reação é apontar o dedo na cara da outra equipe e proferir as palavras: “a culpa é de vocês”. Esse tipo de relação é extremamente desgastante, tanto para as equipes – que acabam por passar a maior parte do tempo discutindo de quem é a culpa em vez de se empenhar em cumprir metas – como para a organização, que tende a perder prazos e qualidade nas entregas.

Em 2009 (DEBOIS, 2009) surgiu uma nova tendência: DevOps (a interdependência entre Desenvolvimento de Software e Operação de TI). Podemos traduzir esse termo como uma nova forma de pensar, uma cultura e também uma filosofia que promete:

• permitir a integração entre as equipes de desenvolvimento e operação (infra);
• maior agilidade na entrega de aplicações e funcionalidades;
• automatização das etapas de implantação, teste, regressão, etc.;
• automação de infraestrutura, provisionamento, configuração, deploy etc.

Uma das características principais do DevOps é a automação. Por meio desse recurso é possível executar tarefas de forma rápida e ainda diminuir a incidência de erro humano. Os processos entregues de forma automática são mais confiáveis, fáceis de ser auditados e normalmente mais baratos, se comparados ao custo de manter toda uma equipe para desempenhar a mesma tarefa.

Para se otimizar a relação entre custo e beneficio, e para possibilitar uma entrega contínua e confiável (HUMBLE; FARLEY, 2010), faz-se necessária a capacidade de automatizar o processo de desenvolvimento e de implantação desses ativos.

Contextualizando o DevOps

Quando as organizações precisam entregar um serviço, seja uma aplicação, seja um ambiente de TI ou qualquer outro recurso, surge uma necessidade acentuada de maior colaboração entre as equipes de infraestrutura e desenvolvimento. Entretanto, infraestrutura e desenvolvimento tendem a não trabalhar no mesmo ritmo, ou a possuir visões conflitantes quanto à necessidade de recursos (capacidade e recurso tecnológico), prazos e alguns outros fatores.

Para resolver parte desse problema surgiram as metodologias ágeis. Seu objetivo é simples: viabilizar a entrega do software com rapidez e qualidade, proporcionando ainda um canal claro de comunicação e permitindo, dessa forma, que outras áreas consigam migrar o software para um ambiente produtivo.

Na visão do DevOps, um software pode ser entregue em pequenas “porções”, o que permite uma entrega contínua de valor ao cliente. Uma vez que esse ativo será migrado para produção pela primeira vez, é necessário provisionar máquinas, configurar o ambiente, implantar monitoração, fazer deploy, validar e garantir a escalabilidade. Agora imagine ter que repetir todos esses passos toda vez que um software tiver que ser entregue? Complicado, não é mesmo? Para evitar esse retrabalho, o DevOps prega fortemente a utilização de técnicas, ferramentas e processos de automação.

Sendo simplista, poderíamos fazer a seguinte reflexão: ao disponibilizar um software ou parte dele, os recursos são provisionados e configurados automaticamente; na sequência são feitos o deploy da aplicação, as validações/testes e a subida da monitoração; com tudo isso correndo bem é feita a “virada de chave” para a produção. Esse ambiente também terá garantia de escalabilidade conforme necessário. De forma geral, podemos dizer que este é o produto final do DevOps: um fluxo contínuo de entrega rápida com qualidade garantida.

Outros trabalhos como este você pode encontrar no meu endereço no LinkedIn: https://www.linkedin.com/in/fabiojanio

Obras de referência

DevOps: 10 dicas para quem quer se aventurar https://www.linkedin.com/pulse/devops-10-dicas-para-quem-quer-se-aventurar-mateus-dias-csm

DevOps explicado, parte 1: Os três princípios subjacentes https://www.ibm.com/developerworks/br/library/se-devops/part1/

DevOps: aproximando a área de desenvolvimento da operacional http://www.comp.ime.eb.br/graduacao/pfc/repositorio-pfc/2016/2016-Rocha.pdf

Bibliografia

Devopdays ghent. DevOpsDays. 2009. Disponível em: <https://legacy.devopsdays.org/events/2009-ghent/>. Acesso em: 12 abr. 2017.

HUMBLE, J.; FARLEY, D. Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation (Adobe Reader). [s.l.]: Pearson Education, 2010.