É preciso mudar o modo como planejamos, desenvolvemos e entregamos software.

E essa necessidade não é só motivada pela velocidade de mudanças exigida atualmente no mundo dos negócios.

DevOps está se tornando cada vez mais realidade, pois além de melhorar a sua entrega, melhora todo o processo de engenharia, e claro que isso também melhora consequentemente a sua entrega, mas vai trazer benefícios de qualidade, segurança e até mesmo o humor da sua equipe vai melhorar!

DevOps é o termo cunhado para derrubar os silos existentes e fazer com que desenvolvimento e operação voltassem a trabalhar juntos abrange muito mais que apenas desenvolvedores e operadores (sysadmin).

Se isso lhe parece estranho, o que é estranho é o seu processo de desenvolvimento achar que apenas quem escreve código ou quem mantém a rede e máquinas é o que importa ao processo.

Imagine que em uma indústria automobilística apenas mecânicos e operadores das máquinas são considerados como o processo produtivo.

Tecelões (realmente não entendo desse processo, escolhi a palavra mais próxima a tecido do estofado) não participam da visão, contrução e entrega... como seria entregue o estofado do seu veículo? E se a pessoa de usabilidade não participa da construção do painel do motorista? E o químico em relação aos combustíveis?

E do seu processo de desenvolvimento de software, você deixa de fora pessoas de segurança? DBA's? Quem trabalha a usabilidade da aplicação? Ou mesmo... o PO? É melhor rever o que você entende de desenvolvimento de software.

Por esse motivo alguns profissionais ligados ao desenvolvimento de software, mas que normalmente não são nomeados como desenvolvedores ou "operadores", se manifestaram para incluir sua contribuição ao acrônimo, o que começou a gerar um desvio de foco (IMHO).

Pessoas ligadas a dados questionaram por que não chamar de DevDataOps, evidenciando também a necessidade de incluir analistas de dados, administradores de banco de dados.

Em DEV podemos ter modeladores de dados, analistas de segurança, em OPS podemos ter administradores de banco de dados e de segurança.

Se pensarmos que do lado de DEV temos pessoas empenhadas em alterar o comportamento dos sistemas e do lado de OPS em manter o sistema, podemos colocar qualquer papel. Mas o importente é que quem quer mudar e quem quer manter, trabalhem juntos para garantir que tanto o trabalho de um como o do outro vá funcionar!

Independente disso, é interessante aprofundar um pouco mais sobre alguns papéis:

Na TI é muito comum algo se tornar commodity com o tempo, foi assim com as máquinas, depois com servidores, depois com datacenters.

Tudo vai ficando mais fácil, assim como com os bancos de dados, mas foi falado que DBA's não seriam necessários, será que isso faz sentido?

Chamamos de "DBA" qualquer pessoa relacionada com dados ou banco de dados, mas existem vários papéis, e dentro de uma média ou grande organização esse papéis são executados por pessoas diferentes. Elas irão garantir não só a disponibilidade e garantia de backup dos dados, mas algo muito relevante:

Que os dados pertençam a organização e não somente a uma aplicação. E quem é o responsável por isso é o administrador de dados, que irá fazer uma modelagem dando sentido ao mesmos.

Por isso a importância de envolver as pessoas de "Data" desde o início do desenvolvimento de uma aplicação... para não precisar alterar depois! E por isso apesar do movimento DevDataOps, eles já devem pertencer ao Dev.

Escrever código já é complexo, os desenvolvedores atualmente precisam conhecer mais de uma linguagem, frameworks, etc... E ainda precisam garantir a segurança dessa aplicação!

Quando se fala em segurança em TI, relacionamos muito às pessoas que dão permissão de uso de um sistema, criação de usuários, ou seja Ops. Porém é cada vez mais frequente termos pessoas ligadas a questões de segurança desde o início do desenvolvimento, ou Dev!

"Leva-se 20 anos para construir uma reputação e alguns minutos de incidente cibernético para arruiná-la.", Stephane Nappo - https://twitter.com/CYSECNG/status/1186170823855562753

Todo sistema deveria ser escrito tendo em mente segurança em primeiro lugar.

E como seria possível garantir essa segurança? Desenvolvedores que desde a primeira linha de código pensem em possíveis brechas de segurança, e existem muitas, que são tão primárias que tutoriais simples na web mostram como se valer delas para invadir um sistema.

Não só desenvolvedores treinados em possíveis brechas de segurança, mas analistas de segurança em aplicação, em rede, deve ser envolvidos, e não somente no momento da operação, fechando portas em servidores, mas sim no momento do desenvolvimento habilitando protocolos seguros, por exemplo!

Por que não usar "https://" desde o ambiente de desenvolvimento e já validar como está a segurança no acesso do login? Fazer isso quando estiver homologando o sistema vai não só trazer o transtorno de retornar ao design, refazer código, como deixa os desenvolvedores confortáveis em não precisar pensar sobre segurança.

A ativação deste framework no ciclo de desenvolvimento de um software ou aplicação da sua empresa pressupõe o contato com especialistas em DevOps do seu time, ou parceiros estratégicos em Consultoria DevOps como a ESX.

Fale agora com a ESX e agende a sua consultoria

Apesar de tudo, o termo DevOps é muito usado para frisar a importância da segurança no desenvolvimento de software.

O link para a segunda parte da matéria é esta aqui.

Se neste momento não fizer sentido para você saber mais sobre o assunto, mande esse artigo para um colega que possa se beneficiar com esse tema ou ajude-nos com a divulgação compartilhando o post e ajude as aplicações serem mais seguras!