Co-fundador da Alura. Com mais de 20 anos de ensino de tecnologia, criou mais de 100 cursos. Possui formação em engenharia de software, viés matemático e criativo, além de ser medalhista de ouro em competições nacionais de computação, tendo representado o Brasil nos mundiais. Participante de comunidades open source e de educação em tecnologia, tendo escrito 7 livros. Faz mágica e fala coreano no tempo livre.
Inscreva-se em nossa Newsletter
Fique por dentro de conteúdos, insights e oportunidades do universo tech. Receba novidades e lançamentos direto no seu e-mail.
Ao término do primeiro sprint, sua aplicação está andando muito bem e tem todas as histórias aprovadas enquanto no ambiente de testes. Passaremos então para a primeira tentativa de colocá-lo em produção/homologação, e logo descobre-se que o sistema não funciona corretamente nesse novo ambiente, e é gasto muita energia para adaptar diversos detalhes que já eram considerados "prontos".
Em sistemas que não implementam testes end to end, mesmo que smoke tests e que não se planejam para deploys desde o começo do projeto, é comum encontrar um grande número de bugs no primeiro deploy de homologação, além de uma extrema dificuldade para realizar essa implantação inicial.
A equipe passa então a trabalhar para corrigir essa onda de bugs, fica incapaz de adicionar novas funcionalidades em um ritmo adequado e desanima rapidamente.
Enquanto o processo de deploy não for automatizado, cada nova tentativa de implantação é seguida por uma enchurrada de bugs novos, sempre com as mesmas consequências negativas.
A solução aqui é automatizar todo o processo de deploy desde o primeiro sprint, e para isso você precisa estruturar muito bem seu ambiente, de forma que ele seja perfeitamente replicável entre as máquinas de desenvolvimento, homologação e produção. Isso é bastante planfletado pelo movimento Devops.
Graças aos ciclos mais curtos de deploy, o cliente testa o seu software mais cedo e recebemos feedback mais rápido quanto a bugs existentes, portanto o número de bugs novos sai do zero muito mais cedo, diminuindo um possível susto.
Tudo isso minimiza o acúmulo de bugs, resultando em um ritmo constante, mas menor, de aparição de problemas, inerentes a qualquer processo.
Com o deploy contínuo através de técnicas como a citada pelo Akita, cada commit terá não só suas baterias de testes rodados, mas entra em homologação. Os bugs aparecem mais cedo durante o desenvolvimento do projeto e o processo de deploy pode ser efetuado mais frequentemente.
Indo além, com um sistema blue-green, seu processo de deploy atinge um nível maior ainda de maturidade, com a possibilidade de um rollback robusto a qualquer instante.