Quais são os motivos para usar a janela de encaixe no seu processo de desenvolvimento de software, se você não a estiver usando na produção?

O Docker tem muito potencial para resolver problemas no meu local de trabalho em uma grande equipe (100) de desenvolvedores de software e é usado para resolver problemas no meu local de trabalho. Isso inclui:

Ter um cluster de hosts do Docker nos quais você pode executar tarefas
Fazer com que os agentes de IC sejam executados como imagens de janela de encaixe para que você possa ampliar horizontalmente conforme necessário (e garantindo que todas as construções sejam completamente limpas e consistentes)
Especializando Diferentes Agentes para Construções Android, JS e Java
Executando testes JUnit em paralelo, espalhados por vários contêineres
Ter ferramentas de desenvolvimento como Sonar e NPMJS em execução no docker (em hosts dedicados) para que você possa atualizá-las facilmente em um pipeline de CI com um check-in de controle de versão

O feedback voltou para mim:

É ótimo que você tenha esse trabalho, mas entender o ecossistema docker é um salto mental para algumas pessoas . Já está estabelecido que não executaremos docker na produção; portanto, não acreditamos que haja um motivo para investir em capacitar nosso pessoal nessas ferramentas.

Minha pergunta é: Quais são os motivos para usar a janela de encaixe no seu processo de desenvolvimento de software, se você não a estiver usando na produção?

production docker culture

— Hawkeye
fonte

Só porque você não vai usá-lo na produção não significa que não é uma ferramenta útil para fins de desenvolvimento, então o argumento "nós não vamos usá-lo na produção, então não queremos vê-lo em tudo "soa inválido para mim. Você já tem uma lista de coisas que mostram como isso pode ser útil. Eu o uso para executar bancos de dados para desenvolvimento e teste na minha máquina de desenvolvimento.

— Jesper

Apenas uma observação rápida: para mim, você aumenta a escala (máquina mais potente) ou horizontalmente (adiciona mais máquinas). Aumentar horizontalmente parece estranho para mim.

— Machado

Faça um favor a si mesmo e dedique uma máquina para replicar as condições de produção, se você decidir seguir o caminho de usar o Docker, para poder testar o programa em um ambiente o mais semelhante possível à produção. Além disso, enlouqueça o Docker, divirta-se.

— 315 Neil

Outra dica rápida: servidores de controle de origem, servidores de compilação e servidores de CI SÃO SERVIDORES DE PRODUÇÃO para seus desenvolvedores. Sua organização pode estar usando a TI como meio para um objetivo final (o que significa que você não está no negócio de tecnologia), mas se você tiver desenvolvedores, eles esperam ter um ambiente em que possam confiar para realizar algum trabalho. Isso significa que todos os servidores acima devem ser tratados tão críticos quanto todo o resto em sua infra-estrutura, ou então você terá uma equipe sem recursos para trabalhar e entregar. Mesmo que a TI seja o lado de suporte da sua operação, você não quer que eles permaneçam na espera dos servidores para voltarem a estar online.

— Machado

O problema com o feedback que você recebeu é: ele é traduzido para »Desapareça com o docker. Não queremos isso. «É claro que havia muitas razões para se usar o docker, mas neste caso, parece que o feedback é apenas uma desculpa educada.

— 21417 Thomas Junk

Aqui estão algumas razões pelas quais usamos o docker como parte de nosso processo de desenvolvimento de software (ainda não o usamos na produção):

Ambiente de implantação local consistente e controlado por versão - verificamos nossa construção do docker no controle de versão e podemos colaborar na pilha. Podemos obter um ambiente completamente limpo, parando e iniciando uma pilha.
Facilidade de distribuição de ambientes para colegas de equipe - recentemente tivemos uma pilha de software completamente nova que tivemos que começar a manter. Só tivemos que produzir a pilha uma vez no Docker e distribuí-la entre a equipe, em vez de documentar as ferramentas e o processo para instalar a grande quantidade de software. Os documentos geralmente são esquecidos e testados apenas quando um novo membro se junta à equipe - geralmente as instruções não funcionam mais.
Usado na criação de CI e testes automatizados - As mesmas imagens que estamos usando para implantar e testar o software localmente são usadas pelo CI para criar e testar o software. Isso reduz a probabilidade de erros específicos para as peculiaridades no ambiente local de alguém.
Mais fácil do que as máquinas virtuais para gerenciar, alterar, criar e distribuir.
Oferece a capacidade de estender imagens existentes para que não tenhamos que criar imagens do zero. Geralmente, existem imagens de código aberto disponíveis para pacotes de software populares.

— Samuel
fonte