Fazendo a mudança para o controle de origem

Question

A nossa empresa é relativamente pequena (3-4 programadores e 3-4 designers de sites) que desenvolve uma aplicação web PHP de propósito único que fornece a funcionalidade para mais de 100 sites. Operamos por alguns anos em um ambiente separado de desenvolvimento e produção que funcionou razoavelmente bem. Sempre existiram recursos separados suficientes para serem desenvolvidos e que os programadores nunca se chocam e era mais conveniente trabalhar sem o controle de origem; mesmo que tivesse risco de perda de dados e nós tivemos nosso quinhão de arquivos desaparecendo em um movimento inadvertido.

A outra consideração é que nossos designers não são especialistas em tecnologia (eu os apresentei a html marcação, em vez de usar WYSIWYGs). Esta tem sido uma das razões para hesitar em fazer a mudança para o controle de versão.

No entanto, agora que alcançamos mais de cem sites e a equipe de desenvolvimento está crescendo, estou tentando padronizar nossos procedimentos e controle de origem Parece um passo lógico na medida em que os programadores vão. Espero que isso também acelere nossas implantações de patches.

Infelizmente, tenho uma experiência muito limitada com a configuração de um sistema de controle de origem. O que eu estou curioso para ouvir de pessoas com uma configuração semelhante ou experimentar a mudança:

1) Você faz uma versão de tudo (sites, css, modelos de html e código de aplicativo) e, assim, força os designers a aprender sobre versões? Ou são apenas os desenvolvedores que trabalham no código do aplicativo?

2) Quais são algumas das armadilhas a serem observadas ao configurar inicialmente o controle de origem?

3) Implantação de dev = > dicas de produção para controle de origem.

Obrigado por todos os insights.

Editar 1: Dang. Todo mundo até agora está recomendando controlar tudo. Isso vai me fazer perder meu cabelo cedo. Provavelmente vai desencadear uma nova questão no futuro próximo. Obrigado pelo conselho até agora, continue!

Edite 2: Muitas boas respostas, e estaremos analisando os vários sistemas de controle de versão. Obrigado pelas respostas a todos!

    

Answer 1

É útil ter tudo com versão, mesmo para designers. E se for bem implementado com um bom treinamento, acho que eles acharão mais útil do que oneroso.

Se você está apenas começando, sugiro usar um sistema de controle de versão distribuído como git ou mercurial . Essa é a tendência geral no mundo, e há muitas vantagens. É fácil trabalhar em um modo desconectado, sem dependência de rede e a capacidade de executar trabalhos privados e não polidos ainda sob controle de versão, verificando tudo centralmente quando estiver pronto.

E não recorrer a apelos à autoridade nem nada, mas confira o que Joel Spolsky tem a dizer sobre o assunto. tópico . (Citação da escolha: "Subversion = sanguessugas. Mercurial e Git = Antibióticos.") Entre outras coisas, ele aponta que esses novos sistemas usam um novo modelo mental, diferente do controle de versão tradicional - é por isso que entrar nesse tipo de abordagem desde o início é uma vitória.

    

Answer 2

Eu diria colocar tudo sob controle de versão. Uma vez que tudo funcione, você pode copiá-lo para uma tag que, para a maioria dos sistemas SCM, não requer muito espaço em disco no servidor.

No que diz respeito a armadilhas iniciais, você não deveria ter que se preocupar muito; confirme tudo para o servidor e, se não estiver correto, você pode alterá-lo aleatoriamente e excluir as coisas extras posteriormente. A única coisa que eu não iria cometer é artefatos que são construídos a partir da fonte, ou seja, arquivos de código java pertencem ao controle de versão, mas não as classes compiladas ou ISOs / DVDs inteiros de binários "construídos a partir da origem".

O desenvolvimento para a produção é fácil, em todos os principais marcos, crie um ramo. O layout do diretório no sistema de controle de versão geralmente se parece com algo como:

/ trunk / project / branches / project / version1 / branches / project / version2 / branches / project / version3

Então, digamos que você encontre um bug na versão 2 do produto, navegue para essa ramificação, corrija-a e libere a versão 2.1. Enquanto isso, você está trabalhando na pasta / trunk / project para a nova versão 4 e cabe a você quais recursos são mesclados para trás e para frente.

Não deixe que os bebedores de kool-aid do SCM enganem você, há muito poucas diferenças funcionais entre os sistemas populares de controle de versões, como o Subversion e o Git. A coisa mais importante para sua equipe será como esses servidores se integram às suas ferramentas existentes. Eu também não gosto de WYSIWYGs, mas certamente é bom ter eclipse-php ou outros IDEs compatíveis com o servidor.

    

Answer 3

Sou desenvolvedor e já trabalhei como administrador de TI antes.

Para responder às suas perguntas específicas:

1) Sim, versão tudo.

2) Sugiro que você configure um repositório de controle de versão fictício e um projeto simulado para as pessoas aprenderem.

3) Marque as versões que são colocadas em produção. até os julgamentos. Então você sempre pode verificar uma versão específica que alguém está executando.

Vejo que você marcou a pergunta CVS.

Minha sugestão é dar uma olhada séria no subversion, combinado com o TortoiseSVN, o que o torna muito fácil de usar. Há também um TortoiseCVS também.

Sugiro que você execute um tutorial interno sobre controle de versão. Ficarei surpreso se seus desenvolvedores / designers não tiverem encontrado isso antes. Tartaruga apenas torna muito amigável.

Também pode ser benéfico instalar uma das interfaces da Web em cvs ou subversão.

O motivo pelo qual sugiro subversão sobre o CVS é que, embora o CVS seja muito bom, ele apresenta alguns problemas sérios de design e implementação. Os biggies para mim foram: 1) Você não pode diretórios de versão 2) A manipulação de arquivos binários não é muito boa, pois muitas coisas são padronizadas como texto. 3) Nenhuma confirmação atômica. 4) Lembro-me de muitas vezes bagunçar e deixar arquivos de bloqueio ao redor que eu tinha que remover manualmente do armazenamento de código. Havia espaço para corrupção em fazer isso desde os seus arquivos de bloqueio. 5) Suporte SSL e gerenciamento de usuários / senhas

Subversion basicamente corrige todos esses problemas são provavelmente muitos outros. Ele também tem muitos recursos avançados, como externos (que eu realmente uso). E é possível vincular os usuários / grupos ao diretório ativo que você pode achar útil. Na época, usei o CVS que não estava disponível. Pode ser agora, eu não verifiquei.

Provavelmente a maior diferença para entender o svn em usá-lo é que você não cria tags. Em vez disso, você cria o que parece ser cópias em que o diretório do projeto é copiado para a pasta Tags e recebe um nome. Dê uma olhada na documentação e você verá o que quero dizer. Eu sei que parece estranho, mas você se acostuma.

Este site pode ser de algum benefício (embora eu não possa garantir isso): Configurando um repositório svn modular para sites php link

    

Answer 4

Com grande respeito a grande parte da sabedoria que aparece acima - e é sábia - o lançamento do controle de versão é como o lançamento de sistemas de monitoramento. Meus clientes dizem "o que devo monitorar", e a resposta óbvia é "monitorar tudo". Mas essa não é uma novidade bem-vinda: eles têm 350 sistemas, cada um com 20 a 30 variáveis de sistema, além de um monte de variáveis específicas de uso, e todas poderiam ser monitoradas de maneira útil; mas há apenas um de mim, e eles gostariam de ver alguns resultados dentro de uma quinzena.

Portanto, embora eu concorde que a melhor prática é controlar a versão de tudo, se isso não for prático em primeira instância, comece controlando as coisas cuja falta de controle causou a maioria dos problemas até então. >.

Se a maioria das interrupções for causada pelo código do aplicativo, comece controlando-o; se a maioria for por patches CSS não planejados, controle isso; e assim por diante.

Isso não só lhe dará o melhor retorno para o investimento de tempo, como também dará motivos sólidos para estender o uso do controle de versão no futuro: "Como adicionamos controle de versão ao código do aplicativo, interrupções não planejadas mais de 30 minutos caíram de 11 por mês para 2. Esses dois foram causados por alterações HTML estáticas, então pretendemos controlar a versão em seguida. ".

Um lançamento gradual também oferece usuários habilidosos dentro da organização. Sim, você teve que ensinar aos seis desenvolvedores de aplicativos como usar o sistema, mas eles aprenderam e estão bem com isso; Agora que chegou a hora de transferir o sistema para a equipe de CSS, você tem mais seis especialistas internos do que você fez há três meses. Você pode até ter convertidos a essa hora; um desenvolvedor que teve sua bunda salva pela capacidade de retroceder prontamente uma alteração prejudicial pode muito bem ser seu melhor evangelista para a equipe de CSS.

Editar 1: se você decidir seguir esse caminho, um backstop barato como chip é adicionar tripwire no topo, pelo menos em uma caixa de produção. Dessa forma, se o Things Break, mas o VCS, disser que não é responsável por ele, será possível identificar rapidamente o que foi alterado, o que acelera a correção e sugere seu próximo candidato ao controle de versão.

    

Answer 5

Controle de versão de tudo. Não faz sentido ter arquivos HTML sob controle de versão e ter um site completamente danificado por causa de uma alteração no CSS que não está sendo controlada e, portanto, não pode ser facilmente revertida.

Armadilhas: eu pessoalmente não encontrei nenhuma durante meu uso razoavelmente limitado de controle de versão.

Implantação: atualmente, uso o subversion hospedado em caixas do Windows, tanto no trabalho quanto em casa. Windows apenas porque é isso que está disponível. Caso contrário, poderia facilmente ter sido outro sistema operacional. A chave para os usuários não técnicos é dar-lhes uma ferramenta simples baseada em GUI para lidar com importações, exportações, commits, diffs, etc. Qual ferramenta usar dependerá um pouco do sistema OS e VCS usado.

Uso: Quando estou fazendo alterações de código, eu testo e faço commits com frequência. Isso me permite voltar o quanto for necessário quando eu estragar tudo. Além disso, ao comparar várias revisões e copiar partes do código, não preciso perder todas as alterações apenas porque preciso reverter para uma versão anterior para corrigir alguns problemas em outra parte do código.

Benefício adicional: você pode conceder acesso ao repositório de origem por meio de uma VPN ou conexão segura, permitindo que os usuários trabalhem em casa ou em outro lugar. por exemplo. Eu poderia ter uma idéia em casa e editar meu código de trabalho, antes de perder o pensamento.

    

Answer 6

Versão de tudo.

A implantação depende de quanto você precisa "personalizar" para cada um desses sites. Se eles forem idênticos, exceto por um arquivo de configuração ou dois, você pode simplesmente dar uma cópia do código para eles e fazer pequenas alterações. Conforme necessário, execute o comando de atualização do seu controle de versão para cada um dos clientes.

Se você escolher o modelo de distribuição "check-out diretamente no site do cliente", será necessário garantir que o servidor exclua o acesso aos diretórios de controle de versão para que as pessoas não consigam navegar para link e espie seus internos. Além disso, eu definitivamente tenho um host virtual de teste e produção para cada cliente, a fim de garantir que a atualização do site não fique descontrolada. Especialmente se você estiver fazendo alterações personalizadas nos arquivos de clientes individuais, precisará lidar com os conflitos antes que as alterações sejam ativadas. Nesse caso, você verificaria / atualizaria o host virtual de teste e, quando tudo funcionasse corretamente, você copiaria o host virtual de teste para o host virtual de produção.

    

Answer 7

Tudo o que as pessoas estão dizendo sobre o que fazer com a versão é bom.

Se você decidir usar o subversion, recomendo testar a pilha do Bitnami Trac; link

Ele simplifica a configuração do subversion para você, vem com um sistema de tickets (que você pode optar por usar neste estágio ou não) para acompanhar as alterações & bugs, e um wiki que você pode usar para documentar como você quer que seus desenvolvedores usem o sistema.

Conceda a todos os seus desenvolvedores do Windows o TortoiseSVN. Ensine a todos alguns conceitos básicos de linha de comando svn.

No final do dia, a ferramenta é menos importante do que a mentalidade que você precisa inserir em seus desenvolvedores. Espero que em breve eles vejam que o controle de versão é Uma Coisa Boa, porque os impede de perder o trabalho e permite que eles retornem de becos sem saída que os estão levando de volta a estados bons conhecidos. Os benefícios superam a sobrecarga (leve).