Existe uma terceira maneira, como você mesmo disse. Eu acho que você está misturando desenvolvimento, teste e implantação. Proponho que todo o SDLC seja visto como um todo, primeiro, para entender o que você está tentando alcançar. Este é um tópico importante, mas farei o possível para resumir.
TL; DR;
Em resumo, você precisa separar:
- seu código, de
- a configuração do aplicativo, de
- a configuração do ambiente do sistema.
Cada um precisa ser independente um do outro e adequadamente:
- versão controlada
- testado
- implantável
Versão Longa
Primeiro, você tem um aplicativo composto de código e (conjuntos separados de) configuração. Isso precisa ser testado, tanto para as funções de compilação quanto para as intencionais - isso é chamado de integração contínua (IC). Existem muitos provedores desse serviço on-line e localmente - por exemplo, CircleCI para um provedor de nuvem que se vincula ao seu repositório e cria e testa sempre que você confirma. Se o seu repositório estiver no local e não puder usar um provedor de nuvem, algo como Jenkinsseria um equivalente. Se seu aplicativo for bastante padrão, provavelmente existe uma imagem do Docker existente que o serviço de IC pode usar. Caso contrário, você precisará criar um, ou um cluster, para que o código e a configuração do aplicativo possam ser implantados. Configurado corretamente, você terá várias estatísticas sobre a qualidade do código do seu aplicativo.
Em seguida, assim que estiver satisfeito com a funcionalidade e a correção do seu aplicativo, a base de código deve ser devidamente identificada para uma versão específica. Essa construção deve ser implantada em um ambiente de teste. Observe que o código será o mesmo que o testado no seu IC (provavelmente, se você fez isso corretamente), mas sua configuração pode ser diferente. Novamente, alguns provedores de IC podem oferecer esta etapa para que você possa testar sua implantação de um aplicativo em pacote e uma configuração discreta. Esse estágio normalmente inclui testes funcionais do usuário (para novas funcionalidades), bem como testes automatizados (para funcionalidades conhecidas). Se a liberação passar neste estágio, você terá um candidato à liberação para teste de integração. Você pode executar os testes de automação de outro contêiner do Docker,algumas métricas que afirmam que o esforço de teste é 1: 1 para o esforço de codificação (embora eu não tenha certeza disso).
Penultimamente, o próximo passo é onde você cria seu ambiente (sistema) como se fosse produção. Se você estiver usando o Docker em produção, é aqui que você pensará em proteção de segurança, otimização de rede e servidor etc. Suas imagens do Docker podem se basear nas que você usou no Development (idealmente), mas pode haver alterações no dimensionamento e na segurança , como eu disse. Até agora o teste funcional do aplicativo deve estar completo, você está mais preocupado com segurança e desempenho. De acordo com o teste funcional, seus testes aqui podem ser desenvolvidos, implantados e executados a partir de outras imagens do Docker. Essa etapa costumava ser terrivelmente cara e raramente era feita para você precisar de um hardware dedicado que reproduzisse a produção. Hoje, isso é completamente viável, pois você pode se levantar e derrubar todo o ambiente de praticamente qualquer escala sob demanda.
Por fim, você tem uma versão que deve estar pronta para produção com apenas um pequeno conjunto de deltas de configuração do teste de integração (endereços IP, URIs de banco de dados, senhas etc.). Sua base de código foi testada pelo menos em três ambientes diferentes neste momento. ponto e a maioria da configuração do sistema pelo menos uma vez.