O DevOps tornou-se um padrão de ouro no mundo do desenvolvimento de software. Embora possa ser um fluxo de trabalho eficaz para aqueles que codificam e criam novos aplicativos, sua eficácia diminui quando se trata do processo de teste de garantia de qualidade. Embora existam problemas em todas as abordagens organizacionais, tende a haver uma ideia de que o DevOps é uma espécie de solução mágica que resolve todos os seus problemas de uma só vez. Na realidade, a menos que você tenha uma necessidade real de iteração constante, talvez não seja necessário adotar totalmente o DevOps. Mas aqui na iLAB, não queremos fazer afirmações infundadas. Aqui estão nossos motivos pelos quais a adoção do DevOps pode ser uma medida arriscada para sua empresa.
Adotar o DevOps é uma grande mudança
É perigoso minimizar a radicalidade da mudança que a adoção do DevOps representa para qualquer empresa de software. DevOps significa integração e entrega contínuas, o que forçará seus funcionários a se adaptarem a uma reformulação completa da forma como trabalham. A introdução de vários processos novos, como sprints de código e loops de feedback, pode representar desafios para a cultura de desenvolvimento de produtos que você já tem. Você também precisa de muito tempo quando se trata de uma transição de DevOps. Na iLAB, vimos grandes organizações passarem por esse processo e levarem até cinco anos. Será que sua empresa tem tanto tempo disponível? A resposta é provavelmente, definitivamente, não.
DevOps não significa necessariamente maior qualidade
Um grande argumento de venda de uma transição de DevOps é que ela melhorará a eficiência do processo de trabalho e a qualidade do produto. No entanto, o DevOps também tem a ver com velocidade e agilidade, com a entrega de produtos em uma velocidade quase constante e a implantação de atualizações a todo momento. Isso pode ser ideal para uma empresa menor, mas as grandes empresas têm ambientes de software enormes, com dezenas – se não centenas – de aplicativos e configurações vinculados. A introdução de uma estrutura de DevOps em um ecossistema complexo como esse simplesmente altera o modelo de risco para a organização, especialmente porque há uma chance maior de erros ou supervisão. O processo também tende a minimizar a importância de uma equipe independente de testes de garantia de qualidade, pois pede aos desenvolvedores que façam grande parte do trabalho de garantia de qualidade durante os sprints de código.
Mudanças para o bem ou para o mal?
É compreensível que você queira que sua empresa ou empreendimento esteja em dia com o tempo. As empresas adotam novas ferramentas e processos como uma tentativa de melhorar seu próprio trabalho e obter vantagem sobre seus concorrentes. No entanto, entrar na onda do DevOps e reiniciar completamente o seu fluxo de trabalho do zero pode ser colocar a proverbial carruagem na frente dos bois (ou, neste caso, da carroça). Lembre-se de que as pessoas realizam esses trabalhos há décadas sem grandes problemas. Nem tudo é um desastre, e nem tudo que é antigo ou confiável é ruim. Alguns produtos simplesmente não têm tanta necessidade de iteração constante, então por que arriscar mudar tudo sobre como você desenvolve software por uma recompensa tão pequena? Há uma enorme diferença entre manter algo atualizado e substituí-lo completamente. Pode até fazer mais sentido integrar elementos de DevOps antes de destruir todo o seu processo e adotar uma configuração totalmente nova. A garantia de qualidade é uma parte complexa e vital de qualquer fluxo de trabalho de desenvolvimento. Se você optar por manter a configuração atual ou implementar elementos de uma cadeia de produção DevOps, precisará de engenheiros de controle de qualidade confiáveis para garantir que seus aplicativos funcionem sem problemas. É aí que entra a iLAB. Somos líderes globais em testes de garantia de qualidade, independentemente da configuração que você tenha.
