Maneira eficaz de manter projetos passados ​​com seu ambiente de desenvolvimento de trabalho?

Acho que sempre que eu quiser executar um projeto passado, levará muito tempo para que eu possa encontrá-lo e antes que eu tenha tudo configurado novamente para poder executar.

Por exemplo, tenho projetos python que criei no Linux, e isso depende de pacotes de software que são facilmente instalados no Linux, mas não tenho mais a VM do Linux que estava usando. E alguns dos meus outros projetos dependem de outras variáveis, como configuração do servidor Web, variáveis ​​PATH, sdk, IDE, versão do SO, dispositivo, etc.

Alguém tem uma maneira eficaz de lidar com esse problema? A partir de agora, eu me preocupei apenas em manter o backup do código fonte, mas é difícil restabelecer o ambiente de desenvolvimento de trabalho e também é difícil manter o ambiente de desenvolvimento de trabalho também .

O que fiz no passado é converter a máquina de desenvolvimento físico em uma VM ou, se ela já for uma VM, retê-la para uso futuro. Não é tão eficiente quanto eu gostaria para o uso do espaço em disco, mas o espaço é barato. Além disso, esse processo é muito mais barato em termos de tempo do que tentar reconfigurar um ambiente no futuro, se necessário.

Minha metodologia favorita atual é manter um script que instale TODAS as dependências necessárias para um projeto, faça o download da fonte e conecte tudo. Alguns scripts têm dois modos - um para produção, que geralmente é um subconjunto do outro modo: desenvolvimento.

Alguns ambientes levam apenas 5 minutos para serem instalados com um script - nesse caso, eu mantenho uma VM local com uma nova instalação do SO de destino no qual implanto o script do projeto quando chego ao trabalho pela manhã - e depois faço toda a codificação trabalho relacionado nessa instância da VM. Antes de sair, transfiro todas as alterações via git para minha máquina física ou nosso repositório central e encerro a VM.

Se o ambiente demorar mais para ser configurado (instalações demoradas, arquivos grandes para download, algo assim), eu faço o procedimento acima uma vez por semana.

O benefício é que é muito fácil implantar em uma nova máquina e / ou servidor de produção, tudo está documentado no script e o script é verificado com muita frequência.

O conceito que você está descrevendo é gerenciamento de configuração. É o que parece, uma maneira de identificar, gravar, versão / faixa e relatar um ambiente. Geralmente, é uma tarefa fortemente relacionada ao controle de versão e gerenciamento de compilação, mas é suficientemente distinta que requer uma estratégia separada, mesmo que use alguns dos mesmos conceitos e os mesmos mecanismos de processamento e armazenamento.

O gerenciamento de configuração, além de ajudar a manter um ambiente de trabalho sob controle, também ajuda a estabelecer um registro dos diferentes ambientes de trabalho nos quais o software é usado (desenvolvimento conforme mencionado, mais testes / controle de qualidade, implantação em clientes de rotina, implantação em clientes que exigem consideração especial ou configuração especial ou construir propriedades e assim por diante).

Como eu disse, muitas vezes essa é uma tarefa que coincide com o controle de versão de origem, e geralmente os dados de gerenciamento de configuração residem próximos à fonte na documentação e no repositório de origem. Não precisa ser, mas geralmente é uma questão de conveniência.

A automação de alguns aspectos do gerenciamento de configurações melhorou bastante nos últimos anos. Algumas respostas e comentários sugeriram scripts como uma maneira de promover o gerenciamento de configuração, e os scripts são uma boa resposta para ajudar a obter resultados reproduzíveis, mas muitas vezes os scripts criados manualmente são inconsistentes e incompletos. Uma maneira de melhorar isso é através do provisionamento automático. Sistemas como fantoche ou chefajude a especificar componentes e sistemas de software para um usuário ou máquina específico ou para um perfil de tarefa específico e forneça 'receitas' que permitam uma abordagem prática para configurar uma máquina ou ambiente completo. Basicamente, ele pega o conceito de um repositório de distribuição de software e o estende e generaliza, fornecendo não apenas os pacotes de software necessários para um sistema, mas também perfis de configuração específicos para cada pacote, para que ele esteja pronto para uso da maneira apropriada para o seu sistema. situação.

O Vagrant leva isso em uma direção um pouco diferente e fornece uma maneira de girar rapidamente as definições de máquinas virtuais, de modo que uma VM possa ter seu software e hardware virtual provisionados automaticamente e pode provar ser uma maneira conveniente de reproduzir uma representação específica de um hardware ambiente usado pelo usuário do seu software.

Cada sistema (e variações) demora um pouco para ser configurado, mas possui um valor claro se você achar que a tarefa de recarregar e reconfigurar é uma tarefa comum.

Docker seria uma boa opção. Você pode usar um arquivo docker para atuar como um manifesto para a VM que você deseja. Você não precisa armazenar nenhuma imagem, ela fará o download da necessária. Além disso, ele pode usar suas próprias imagens, para que você possa criar sua própria imagem de base e adicionar os componentes exigidos pelo ambiente.

O uso da janela de encaixe também pode melhorar outras partes do seu fluxo de trabalho:

• O ambiente criado pode ser colocado no mesmo CVS que o seu projeto, oferecendo um ambiente com versão (legal!)
• A janela de encaixe pode ser usada para provisionar o ambiente ativo, reduzindo as dores de cabeça ao iniciar seus projetos em produção.
• Se outras pessoas começarem a trabalhar com você, tudo o que precisam é do dockerfile para carregar a enorme configuração do ambiente.

Portanto, as idéias aqui sobre o uso de uma VM são apenas parcialmente corretas, eu sei que os HDs estão ficando cada vez maiores, mas não é uma razão para usar todo o espaço que você tem. Além disso, quando um ambiente de VM precisa de mais espaço no disco rígido internamente, isso pode ser um pouco complicado e é provável que você precise reconstruir um. Embora o tamanho do arquivo possa não ser um problema, a velocidade da Internet ainda se torna um gargalo quando você precisa enviar mais de 5Go em uma conexão DSL normal.

A maioria dos sistemas (idiomas, tempos de execução ou sistemas operacionais) possui uma maneira padronizada de instalar software e configurações; portanto, tente usá-los. Tal como:

• Maven ou Gradle para Java
• CPAN para Perl
• rpm para RedHat / Fedora
• dpkg / apt-get para Linux
• Pacotes MSI para Windows

Em seguida, faça as instruções de instalação explicando exatamente o que precisa ser instalado / quais etapas são necessárias:

• Forneça instruções curtas sobre o que você supõe estar instalado (SO básico, tempo de execução base como Java / Perl / Python ...)
• Escreva um script curto que execute as instalações necessárias (idealmente, apenas uma invocação de uma ferramenta como o Maven)
• Teste isso em uma instalação nova (como em uma VM)

Então você poderá recriar o ambiente, e outros também poderão fazê-lo (o que pode ser importante se não for um projeto solo).

Pode ser necessário armazenar os pacotes de instalação necessários em algum lugar ou incluir apenas instruções de download (a menos que o sistema acompanhe esses, como apt-get ou Maven). Isso depende de quanto você confia nos provedores dos pacotes - provavelmente não há necessidade de armazenar os principais pacotes Debian, mas com um pequeno projeto de software livre, pode ser uma boa idéia.

A solução da VM também funcionará e provavelmente é menos trabalhosa no curto prazo (apenas mantenha a VM). No entanto, sinto que esta solução oferece mais flexibilidade, por exemplo, ao mudar o ambiente.