Entrar no ar é uma etapa crítica em qualquer processo. Uma boa compreensão da diferença entre ambientes de desenvolvimento e produção é fundamental para ajudar todos a avaliar os riscos e como enfrentá-los.
A equipe de desenvolvimento reuniu os requisitos. Durante semanas, eles trabalharam sem parar, ajustando o código, testando unidades, fazendo controle de qualidade e se preparando para o momento em que o projeto fosse lançado. Eles levaram em conta todas as eventualidades, então, o que poderia dar errado?
Todo desenvolvedor de software que já entrou em operação conhece a ansiedade que surge ao entrar em produção. Não importa quanta preparação e testes você tenha feito antes, há aquela sensação terrível de que você perdeu alguma coisa ou de que algo vai dar errado.
Pode ser algo tão bobo quanto esquecer de atualizar o caminho do arquivo estático ou pode ser algo tão misterioso quanto não ter a mesma versão de uma biblioteca no servidor ativo (sim, as pessoas ainda implantam seus projetos sem usar contêineres).
Quando um projeto ainda está em desenvolvimento, os engenheiros de software têm flexibilidade para alterar o código ou refatorá-lo conforme necessário. Quando o projeto está no ar, os desenvolvedores ficam restritos, alguns bugs podem ser corrigidos a quente, enquanto outros exigirão a desativação do projeto para manutenção.
A questão é: o que tudo isso significa para o cliente? Como seu relacionamento com o projeto mudará quando você entrar em produção? O que você deve estar atento? O que você pode fazer para garantir que o processo corra bem?
Como é feito o software?
O ciclo de vida de desenvolvimento de software (SDLC para abreviar) é o nome de um conjunto de práticas padrão que visam facilitar a criação de software. Dependendo de para quem você pergunta, esse processo é dividido em 6 a 8 etapas: Planejamento, Requisitos, Design, Construção, Documentação, Teste, Implantação, Manutenção.
Nas primeiras etapas, a equipe de desenvolvimento reúne informações sobre o produto. Os engenheiros tentam resolver as seguintes questões: O que isso está tentando resolver? Com que tipo de dados ele trabalhará? Ele precisa interagir com outros sistemas ou será independente? Será hospedado na nuvem ou o cliente usará servidores pessoais?
Este processo estabelece as bases para o que virá depois. Compreender a natureza do projeto e a necessidade do cliente desde o início significa que a equipe terá uma ideia melhor de como abordar o processo de design.
Do estágio de design/protótipo em diante, os desenvolvedores precisam configurar um ambiente. Um ambiente é, por falta de termo melhor, um espaço virtual onde a aplicação está sendo desenvolvida.
Por exemplo, se eu construir um sofá na minha sala, o espaço físico que estou utilizando, as ferramentas com as quais estou trabalhando e os materiais são os ambiente. No caso do desenvolvimento de software, o ambiente são as ferramentas de hardware e software que estão sendo utilizadas no processo de desenvolvimento, geralmente chamado de ambiente de desenvolvimento de software (SDE).
Tradicionalmente, você tem três ambientes diferentes no próprio SDE: o ambiente de desenvolvimento, o ambiente de estágio e o ambiente de produção.
O ambiente de desenvolvimento
Imagine por um segundo que um chef está tentando criar um novo prato. Eles fariam isso quando o restaurante estivesse cheio e tivessem que cozinhar para os clientes? Ou faria mais sentido ser criativo quando o restaurante estivesse fechado e eles tivessem tempo suficiente para pensar e experimentar novas combinações?
O ambiente de desenvolvimento é apenas isso – um espaço controlado onde os desenvolvedores podem começar a projetar, prototipar e moldar o projeto. Na maioria dos casos, o ambiente de desenvolvimento é configurado em hardware local e facilitado por meio de um repositório Git. Nesta fase, o projeto está em sua infância, apresenta bugs, carece de recursos críticos e mal funciona – se é que funciona.
Existem diferentes paradigmas sobre como configurar um ambiente de desenvolvimento, mas a maioria dos desenvolvedores gosta que esse ambiente seja o mais isolado possível. Dessa forma, evitam-se bugs devido a software e hardware desconhecidos.
Como um exemplo rápido, a maioria Desenvolvedores Python configure um ambiente virtual com uma nova cópia do Python ao iniciar um novo projeto. Dessa forma, eles podem manter um controle rígido sobre quais bibliotecas estão sendo usadas.
Do design à documentação, o cliente pode ver trechos do projeto: capturas de tela, apresentações guiadas ou até mesmo um protótipo funcional de alguns dos módulos. Neste ponto, os desenvolvedores estão buscando feedback sobre como o projeto está se alinhando aos objetivos do cliente, os testes virão posteriormente.
Ambiente de produção
Colocar o projeto no ambiente de produção é o que as pessoas normalmente chamam de “entrada no ar”. O projeto está pronto para ser utilizado, mas o processo ainda está longe de terminar. Em termos de SDLC, o projeto é movido para o ambiente de produção no final do estágio de teste e entra em operação quando a implantação é alcançada.
Existe um ambiente intermediário denominado ambiente de teste que atua como uma ponte entre o desenvolvimento e a produção. O ambiente de teste é o mais próximo que alguém pode chegar da produção sem realmente entrar no ar.
Em outras palavras, o projeto é transferido para os servidores e configurado como se fosse ser implantado. Nesta etapa, os preparativos finais são feitos, os bancos de dados necessários são migrados e uma série final, mas muito importante, de testes é realizada.
Pense desta forma: até agora o projeto existiu em um laboratório especialmente projetado para preservar sua integridade, mas uma vez transferido para outro local as coisas podem dar errado. Existem ferramentas como Docker que auxiliam no processo de migração, criando um ambiente de produção o mais próximo possível do ambiente de desenvolvimento.
Mas mesmo assim, um conjunto completo de testes é executado para garantir que o projeto funcione conforme o esperado e que não haja conflitos.
Nesta fase, os desenvolvedores podem compartilhar o acesso com o cliente. Assim, você pode ver isso como uma “demonstração” onde o cliente experimenta o projeto na íntegra. A ideia aqui é obter uma rodada final de feedback e, se tudo estiver funcionando de acordo com suas expectativas, é dado o OK para entrar no ar.
A produção é o ambiente onde pequenas coisas podem e irão dar errado, mas também é o estágio onde o projeto deve cumprir seus objetivos. Este é o ponto em que qualquer erro crítico custará tempo e dinheiro ao cliente. Como tal, é imperativo que, mesmo que sejam encontrados bugs, o projeto possa continuar enquanto as correções são implementadas.
A forma como as atualizações são tratadas depende da natureza do projeto e da metodologia da equipe. Por exemplo, as equipes ágeis se esforçam para fazer alterações o mais rápido possível, mas correções críticas podem exigir tempo de inatividade que deve ser agendado durante períodos de baixa carga de trabalho.
Neste ponto, o cliente é um usuário e um testador beta. À medida que bugs são encontrados, a TI monitora os tickets e as soluções são implementadas o mais rápido possível. Uma vez resolvidos os problemas, o projeto passa para a fase de manutenção e todos podem suspirar de alívio quando a parte mais crítica do projeto já passou.
Passar do desenvolvimento à produção é um processo muito delicado que exige dedicação e uso de ferramentas como o já citado Docker para facilitar o processo. É uma daquelas áreas onde um especialista em DevOps pode brilhar e ajudar a impulsionar o projeto.
A passagem do desenvolvimento para a produção pode ser tensa, mas uma forte comunicação entre cliente e desenvolvedores, bem como uma boa estratégia de planejamento/teste podem ajudar o processo e levá-lo à sua conclusão.
