Como é Feito um Sistema Completo? Do Desenvolvimento ao Deploy (Backend, Frontend, DevOps, QA, UX/UI, Cliente)

Fala, Dev! Você já se perguntou como seria o processo de desenvolvimento de software completo, até esse sistema chegar nas mãos do usuário final, seja no seu celular, notebook, tablet? Hoje, vou te explicar como isso acontece.

Por isso, pense nesse cenário: Um cliente tem uma ideia de sistema e decide que vai contratar uma empresa de software. Logo, ele entra em contato com a empresa, fala do que precisa e então, vamos começar o processo de desenvolvimento.

A primeira etapa é a entrevista inicial, que acabamos de falar, que na cabeça de um gestor de projetos vira tarefas para delegar ao times. Mas, que times são esses:

1. Time de Desenvolvimento
2. Time de Produção

No time de desenvolvimento, temos os famosos:

• Backend
• Frontend
• QA
• UX/UI

No time de produção, temos o famoso:

• DevOps

Mas, nesse papo, estou sendo bem objetivo e didático. Afinal, para esse primeiro contato, essa visão vai expandir a sua mente. Voltando... O time de desenvolvimento segue uma metodologia, um padrão, tal como, agile, scrum, kaban.

Cada um faz o seu código, de acordo com a demanda que recebeu e manda para o github, ou seja, o backend e frontend, ux/ui faz suas contribuições, manda para o github, e o QA, começa a testar as primeiras partes, as funcionalidades.

Tudo correto, a equipe de infraestrutura é notificada, e começa a preparar a infraestrutura para o deploy. Cria-se a build do projeto, integrando frontend com backend. Depois, cria-se um container com os serviços que serão executados, e então, é enviado para um orquestrador de containers, que trabalha em cima de um serviço na nuvem, tal como, aws, google cloud.

Mas, isso precisa ser feito de forma automatizada, para que esse processo de deploy seja rápido, objetivo, com testes, fácil de escalar, derrubar e gerenciar. Logo, o DevOps, cuida de toda essa infraestrutura como código, mantendo a agilidade do processo de produção.

Logo, pode-se utilizar uma ferramenta de integração contínua, que busca aproveitar o desenvolvimento contínuo, ou seja, o famoso ci/cd, que pode ser feito através de um gitlab.

Assim, se por algum acaso, surgiu uma nova demanda, com a infra automatizada, o processo de deploy é rápido, e podemos facilmente ver isso, de forma simples, e totalmente abstraída, em uma plataforma como serviço, tal como, o heroku.

Entretanto, o heroku não te dá tanta liberdade para gerenciar e criar processos ali dentro, como uma aws, ou google cloud. Logo, as grandes empresas querem algo mais gerenciável, escalável, e que dê para controlar os custos. Devido a essa gestão, facilidade, produtividade e recursos disponibilizados, os serviços na nuvem estão em alta, principalmente, esses dois que acabei de citar.

Além disso, deve-se haver os testes de produção, que acontecem neste meio tempo, que acabei de citar, através dos stages e pipelines, que são criadas nas fases de integração contínua (ci).

Mas, isso tudo pode parecer na sua mente, que é uma única aplicação, geral, monolítica. Mas, hoje em dia, não é bem assim. Hoje, temos os microserviços, que nada mais é do que dividir um sistema grande, em partes menores, separadas, gerenciáveis, que se comunicam entre si, para que a equipe de desenvolvimento foque na produção do serviço, e a equipe do DevOps foque na gestão, escalabilidade e alocação de recursos gerenciáveis.

Por isso, um sistema completo de um hospital, pode virar uns 20 a 30 microserviços. Sendo um para o login, outro para realizar o cadastro, outro para realizar o atendimento, um para controlar a dispensação de medicamentos, outro para gerenciar o rh, outro para controlar o almoxarifado, mais um para a pediatria, outro para a urgência e emergência.

E assim, se por algum acaso, começar a ter um surto de pacientes infectados, gerando uma alta demanda na frente do hospital, é possível alocar mais recursos, tal como, memória ram e processamento, apenas para a parte do sistema que cuida do registro de pacientes, para que assim, o sistema não trave.

Mas, esse cenário ficaria melhor visível, se você fosse comprar um ingresso para um evento do Lolla Palooza, no dia do lançamento, com gente do mundo todo se cadastrando no site e acessando o sistema de pagamento. Neste exemplo, tendo o sistema de venda de ingressos no ar, na nuvem, gerenciado por uma equipe de DevOps, que fez uma boa infraestrutura como código, deixando tudo automatizado, o próprio serviço na nuvem percebe que o site está tendo muitas requisições rápidas, e isso pode causar derrubar o sistema por multiplos acessos.

Para evitar isso, o sistema já tem permissão de alocar mais recursos, criando um novo container, balanceado a carga de acessos, e assim, deixando a tudo operante, para que todos os ingressos sejam vendidos, sem que o usuário sinta lentidão.

No final, quando sistema perceber que o número de acessos caiu, ele percebe que não precisa mais desses novos containers criados, apenas para este momento de pico, e ele mesmo derruba-os, fazendo com que os custos por alugar mais memória ram e cpu, através desses containers, sejam cortados, de forma automatizada.

Legal, né?! Logo, o desenvolvimento Full Stack com conhecimentos de DevOps torna-se uma habilidade cara, que é muito bem remunerada, requisitada, e que precisa de muito conhecimento técnico e experiência.

Empresas grandes sabem que é problema manter tudo na mão de uma única pessoal, afinal, é um cenário muito grande para gerenciar, mesmo que o Dev GOD tenha essas habilidades e experiência.

Logo, surge a necessidade das equipes de desenvolvimento e produção. Entretanto, no cenário atual, brasileiro de vagas, temos que as empresas requisitam que Devs Backend tenham conhecimentos de DevOps, assim como, Devs Frontend, tenham conhecimentos básicos de backend e DevOps.

Elas ainda insistem em querer um Full Stack God, por ainda não terem bem definidas as equipes de desenvolvimento e produção, e pelo custo por manter uma equipe assim ser alto, mesmo gerando tanto valor, o que abre mais um tema, que é...

A modalidade de contração PJ. Neste caso, você é contratado para projeto, e não mais como vinculo duradouro. O salário recebido pode subir, pois é o vinculo é temporário, e você emite nota por serviço realizado. Isso tem seus prós e contras, mas estende o tema do artigo.

A visão que gostaria de deixar era essa, onde você pode visualizar o processo de desenvolvimento e deploy, mesmo com muitas abstrações e tecnologias não citadas, afinal, este conteúdo daria uma aula de umas 4 horas de vídeo, se fosse desmembrar e apresentar tudo de forma visual.

Mas, acredito que a visão já deu para ter noção do cenário macro, enquanto, estamos aprendendo os pormenores e montando as nossas stacks, para concorrer no mercado de trabalho.

Espero que tenham gostado da visão, e vamos lá.

Até breve.