Sou um desenvolvedor web e trabalho com vários idiomas e projetos (quem não é?). Eu clonei muitos desses projetos / repositórios localmente em vários diretórios.
Agora, com dezenas de projetos clonados ao longo dos anos, sinto que estou em uma confusão, pois muitas vezes preciso passar algum tempo para descobrir onde eu clonei algo.
Em suma, eu preciso de um sistema para gerenciar repositórios de desenvolvimento local. O objetivo é:
Os repositórios são em sua maioria git , mas existem svn e até cvs repos.
Existe uma ferramenta que pode me ajudar com isso? Eu odiaria escrever uma solução personalizada (scripts) apenas para descobrir que estou reinventando a roda.
As ferramentas de gerenciamento de configuração (chef, fantoche, ansible) são adequadas para esse problema?
myrepos poderia ser apropriado aqui; Ele permite que você gerencie vários repositórios de código-fonte de diferentes tipos. Você pode descrever todos os seus repositórios em um único arquivo de configuração e gerenciá-los simultaneamente ou separadamente, conforme apropriado.
Eu não acho que uma ferramenta centralizada de gerenciamento de configuração como Chef ou Ansible seria um bom ajuste aqui ...
Mantenho todas as fontes de terceiros em /usr/local/src , sejam elas provenientes de um tarball ou de algum host SCM de terceiros.
(Por que lá? Como o prefixo de instalação padrão é /usr/local para a maioria dos pacotes, então por que não manter as fontes junto com os binários?)
Assim, para configurar isso em uma nova máquina de desenvolvimento, eu simplesmente digo
$ cd /usr/local/src
$ sudo chown $USER .
$ scp -r oldbox:/usr/local/src/* .
Quando você tem várias caixas de desenvolvimento ativas, isso significa que você tem que manter novas subárvores ao longo da última que você usou, mas não acho isso muito pesado.
Às vezes eu tenho várias versões de um determinado pacote, como as fontes descompactadas do último tarball de versão estável, além do checkout "head" atual do SCM. Nesse caso, a árvore se parece com
$ cd /usr/local/src
$ mkdir somepkg
$ cd somepkg
$ tar xvf ~/Downloads/somepkg-*tar*
$ mv somepkg-1.2.3 1.2.3
$ git pull http://someserver.example.com/somepkg.git
$ mv somepkg head
Ou seja, tenho somepkg/1.2.3 e somepkg/head árvores paralelas, para poder alternar entre elas conforme necessário. Ocasionalmente acabo com várias versões "estáveis" lado a lado, quando preciso usar várias versões estáveis por algum motivo.
Você pode pensar que seria bom armazenar tudo em um servidor de arquivos local, mas isso falha em vários níveis:
A maioria dos servidores de arquivos executam o SMB atualmente; você não pode sempre obter o que você deseja com o NFS ou outro sistema de arquivos de rede compatível com POSIX. Isso significa que as permissões são arruinadas, alguns nomes de arquivos POSIX legais não são permitidos, a insensibilidade a maiúsculas e minúsculas pode incomodar você, etc.
Se você costuma construir na árvore (por exemplo, ./configure && make ), você acaba com saídas autom4te.cache e binárias específicas para a plataforma, então você teria que make clean && ./configure cada vez que mudasse de caixa.
Você pode corrigir isso sempre construindo fora da árvore , mas nem todos os pacotes sabem como se construir dessa maneira.
A compilação de software em um NAS é lenta.
Manter cópias separadas em cada máquina de desenvolvimento evita esses problemas. Você ainda precisa dizer make clean ; ./configure depois de scp fazer as árvores de checkout passarem para uma nova caixa, mas, depois de fazer isso uma vez, você só precisa git pull ou svn up para fazer as alterações mais recentes do host SCM obter atualizações, em vez de repetidamente scp -ing as novas árvores para novas caixas.
Existem várias tentativas de criar gerenciadores de pacotes para a web, a fim de melhor resolver isso: Bower , Jam , npm , NuGet , etc. O problema com estes é que você provavelmente não encontrará todos os pacotes que você deseja usar em um único deles ainda. Você terá que gerenciar fontes extraídas de algum SCM de terceiros para o futuro previsível.
Tags utilities shell-script